Comments 8
Docker не docker, a cgroup ограничивает ресурсы.
Для FW узкое место перекладывание трафика с сетевого интерфейса? Что-то не верится.
Разработать средство ограничения числа используемых ядер процессора при обработке сетевого трафика.
То есть, вы полезли ковырять ядра, а почему не сетевой стек ядра линукс?
Не очень понял. Чтобы замедлить трафик, ограничили ресурсы для обработки, при этом целиком выделяет ядра, просто меньше чем нужно. В итоге какие-то потоки будут быстро обрабатываться, а какие-то нет. Но разве не смысл в том, чтобы все обрабатывались медленно?
Смысл был в том, чтобы можно было выбрать точное количество ядер ЦПУ которые будут участвовать в обработке трафика (не в программе число потоков создавать, а на уровне железа). Для этого каждое из ядер подключается каждый к своей очереди пакетов. Чем больше задано очередей, тем больше DMA может переложить пакетов из сетевой карты по разным очередям (размер каждой очереди ограничен и может переполняться). Когда у тебя задана одна очередь, она будет обслуживаться одним ядром, соответственно эта очередь будет быстрее переполняться, тем самым будет увеличиваться число отброшенных пакетов (что можно видеть по снятым показателям). Увеличивая число очередей, ты увеличиваешь объем памяти куда могут записываться пакеты из карты, а так же число ядер которые параллельно из этих очередей будут вычитывать.
Высокоуровневый путь, по которому проходит пакет от прибытия до приёмного буфера сокета выглядит так:
Драйвер загружается и инициализируется.
Пакет прибывает из сети в сетевую карту.
Пакет копируется (посредством DMA) в кольцевой буфер памяти ядра.
Генерируется аппаратное прерывание, чтобы система узнала о появлении пакета в памяти.
Драйвер вызывает NAPI, чтобы начать цикл опроса (poll loop), если он ещё не начат.
На каждом CPU системы работают процессы ksoftirqd. Они регистрируются во время загрузки. Эти процессы вытаскивают пакеты из кольцевого буфера с помощью вызова NAPI-функции poll, зарегистрированной драйвером устройства во время инициализации.
Очищаются (unmapped) те области памяти в кольцевом буфере, в которые были записаны сетевые данные.
Данные, отправленные напрямую в память (DMA), передаются для дальнейшей обработки на сетевой уровень в виде ‘skb’.
Если включено управление пакетами, или если в сетевой карте есть несколько очередей приёма, то фреймы входящих сетевых данных распределяются по нескольким CPU системы.
Фреймы сетевых данных передаются из очереди на уровни протоколов.
Уровни протоколов обрабатывают данные.
Данные добавляются в буферы приёма, прикреплённые к сокетам уровнями протоколов.
Хорошая статья! Приятно, когда компании не стесняются говорить о какой-то внутренней кухне в своих решениях, всегда интересно почитать такое.
Подскажите пожалуйста, какая у вас конфигурация trex и команда его запуска для этого тестирования, могли бы поделиться?
Второй вопрос у меня более каверзный, Positive Technologies для реализации NGFW решили отказаться от IP стека ядра, потому что он достаточно медленный и реализовали его внутри userspace, при этом взяв стек от FreeBSD и переписав его под себя. Вы рассматриваете такое решение вашей задачи?
Управление ядрами ЦПУ при обработке сетевого трафика