DPDK: правильное планирование обработки пакетов в пользовательском пространстве

Основной принцип DPDK и правильная классификация

DPDK представляет собой фреймворк для приложений, которым необходимо обрабатывать сетевые пакеты с минимальными накладными расходами в пользовательском пространстве. Вместо использования обычного пути через сетевой стек ядра, сокеты и соответствующие структуры пакетов, приложение может напрямую задействовать выбранные сетевые карты для своего собственного канала передачи данных. Это направлено, прежде всего, на обеспечение высокой скорости передачи пакетов, низкой задержки и хорошо прогнозируемой обработки большого количества мелких пакетов.

Формулировка „без ограничений ядра“ является упрощенной. Ядро Linux по-прежнему отвечает за работу операционной системы, управление памятью, процессы, безопасность и множество административных задач. DPDK также не заменяет ограничения сетевой карты, а также ограничения по пропускной способности PCIe, памяти или ЦП. В первую очередь, для привязанных интерфейсов он обходит обычный путь передачи данных ядра и переносит обработку пакетов в специализированное приложение.

В стандартном сетевом пути Linux взаимодействуют сетевые драйверы, NAPI, система управления пакетами и уровень сокетов. Этот путь не является исключительно прерывательно-ориентированным. DPDK-Драйвер режима опроса запрашивает очереди приёма непосредственно из пользовательского пространства. Приложение принимает пакеты группами, проверяет или изменяет их, а затем передаёт в очередь отправки или на следующий этап обработки.

Это не является общей настройкой ядра и, как правило, не является первоочередной мерой для обычного веб-приложения с небольшим количеством TCP-соединений. Только в том случае, если сам путь прохождения пакетов данных явно ограничен, например, при распределении нагрузки на уровне L4, фильтрации или конечных точках туннелей, возможный выигрыш оправдывает дополнительные эксплуатационные затраты. Характеристики, зависящие от версии, необходимо сверять с документацией по конкретному используемому релиз-тегу; при этом кандидат в релиз не следует приравнивать к релизу, используемому в производственной среде.

Как работает путь к пакетам в пользовательском пространстве

На входе приложение настраивает одну или несколько очередей Rx сетевой карты. Выделенное ядро выполнения циклически опрашивает очередь и получает пакеты, доступные в виде пакета. Эти Пакетная обработка сокращает количество вызовов функций и административную нагрузку на каждый пакет. После классификации, перенаправления или изменения приложение помещает пакеты в единую очередь Tx.

Опрос позволяет избежать большого количества переключений прерываний в сильно загруженном канале передачи данных и делает работу ядра более предсказуемой. Цена этого подхода — постоянная активность ЦП: даже при пустой очереди lcore продолжает проверять наличие новых пакетов. Поэтому эта модель больше подходит для условий постоянной высокой нагрузки, чем для интерфейсов с редким или сильно колеблющимся трафиком.

Данные пакетов и метаданные находятся в rte_mbuf-объектов. Они берутся из заранее созданного пула памяти и содержат, например, длину пакета, входной порт, информацию об оффлоаде и, при необходимости, хеш RSS. Заранее зарезервированные пулы, фиксированное сопоставление очередей и ядра, а также короткие пути обработки способствуют Локальность кэша и избегаем ненужных общих структур данных.

Однако «Zero Copy» не является автоматической функцией DPDK. То, копируются ли данные и где именно, зависит от сетевой карты, драйвера, механизмов разгрузки и логики приложения. Крупные или сегментированные фреймы могут состоять из нескольких связанных между собой mbuf; это актуально, например, для джамбо-фреймов. При преобразовании, объединении или передаче данных пакетов между несовместимыми буферами необходимо учитывать возможные перемещения данных в собственном конвейере.

Архитектура, ресурсы и жесткие ограничения

Уровень абстракции окружающей среды, сокращённо EAL, инициализирует DPDK и, в частности, обеспечивает резервирование памяти, доступ к устройствам, таймеры, а также распределение логических ядер. На этой основе приложение настраивает очереди Ethernet, пулы памяти и их обработку. При этом lcore представляет собой логическое ядро, запланированное для DPDK, а не просто произвольно перемещающийся поток приложения. Эти основные свойства EAL подтверждаются документацией по DPDK 25.07; детали, зависящие от версии, необходимо дополнительно проверить для используемого релиз-тега.

Для обеспечения прямолинейного пути данных один ядро часто обрабатывает пакет полностью: от приёма до принятия решения и отправки. Эта модель «Run-to-completion» позволяет избежать передачи данных между ядрами. В отличие от этого, конвейер, например, разделяет синтаксический анализ, поиск потока и перенаправление на отдельные этапы. Он позволяет упорядочить обязанности, но при этом добавляет циклы, синхронизацию и потенциально ухудшает локальность памяти между этапами.

При планировании также необходимо учитывать NUMA. Очереди, lcore и пулы пакетов по возможности должны располагаться на одном NUMA-узле, чтобы путь передачи данных не обращался регулярно к памяти другого процессорного сокеля. Кроме того, достижимая производительность зависит от функций сетевой карты (NIC), подключения PCIe, пропускной способности памяти, тактовой частоты процессора, размера пакетов и сложности каждого решения по обработке пакетов.

Балансировщик нагрузки уровня L4 может с помощью информации о IP-адресах и портах, предоставляемой DPDK, быстро анализировать данные, сопоставлять потоки и перенаправлять пакеты. Однако это не приводит к автоматическому ускорению терминации TLS, обработки сложных состояний NAT, ведения журналов, проверки работоспособности или работы медленных бэкендов. Кроме того, контрольная плоскость требует доступного процессорного времени для настройки, телеметрии и обработки ошибок. Таким образом, DPDK ускоряет четко очерченный путь передачи данных, но не обязательно всю службу в целом.

Размер и срок службы буферов пакетов также являются частью архитектуры. Mempools ограничивают количество буферов, доступных одновременно, в то время как приложение должно корректно управлять сменой владельца. Слишком малые пулы могут исчерпаться под нагрузкой; чрезмерно большие резервирования занимают память. Оптимальный размер определяется очередями, размерами всплесков трафика, маршрутом пакетов и ожидаемыми пиками нагрузки, а не каким-либо универсальным стандартом.

Проверить условия перед использованием DPDK

DPDK можно планировать только в том случае, если аппаратное обеспечение, память и распределение ресурсов ЦП согласованы между собой. Сама по себе установка не обеспечивает высокопроизводительный канал передачи данных: PMD должен поддерживать конкретную модель сетевой карты, а ресурсы должны быть доступны для резервирования приложением. Приведенная ниже проверка позволяет отделить минимальные технические требования от допущений, которые применимы только к фактически используемому устройству.

Использование Hugepages является стандартным подходом для обширных пулов пакетов, но не является обязательным условием для всех приложений DPDK. EAL также поддерживает параметр –no-huge. Этот специальный режим не является равнозначной стандартной рекомендацией: перед началом пилотной эксплуатации необходимо проверить его пригодность, управление памятью и ограничения драйверов. Основы системы и EAL, используемые здесь, описаны в документации DPDK 25.07; дополнительно сверьте эти параметры с фактически установленным выпуском.

Особенно критичной является Привязка устройства. Многие PMD требуют, чтобы соответствующая сетевая карта была отсоединена от стандартного драйвера ядра и, например, подключена к vfio-pci привязывается. После этого интерфейс больше не будет доступен стандартному сетевому стеку Linux. Однако конкретный порядок действий должен соответствовать PMD и не может применяться в общем виде ко всем поддерживаемым сетевым картам.

Важным исключением являются разветвленные PMD. В документации к драйверу указано, что такие PMD не должны отсоединяться соответствующим драйвером ядра. При этом драйвер ядра может оставаться привязанным, пока конвейер данных пользовательского пространства использует определённые ресурсы. Ссылка ведёт на документацию без указания версии, отражающую состояние разработки на 26.11.0-rc1, и не является инструкцией, привязанной к версии 26.07. Проверьте поддержку устройств и доступные инструменты ядра в руководстве по конкретному используемому PMD.

Перед каждым изменением следующий запрос состояния предоставляет перечень устройств PCI и их текущих связей с драйверами. Сам по себе он не изменяет никаких связей. Запустите его на целевой системе, указав путь, соответствующий установленной исходной структуре DPDK или структуре инструментов.

./usertools/dpdk-devbind.py --status

Доступ к системе управления Plane и путь к производственным данным должны быть разделены, даже если выбранный PMD не заменяет драйвер ядра. Доступность по SSH или консоли не должна зависеть от интерфейса, привязка или распределение трафика которого изменяются в пилотном режиме. Отдельный интерфейс управления, внеполосный доступ или заранее проверенный локальный путь аварийного доступа снижают риск неправильной настройки.

Сравнение DPDK, AF_XDP и Kernelstack

Выбор пути передачи данных — это не рейтинг, а операционное решение. Стек ядра Linux, AF_XDP и DPDK по-разному влияют на нагрузку, доступ к устройствам и потребление ресурсов ЦП. Выбор подходящего варианта зависит от того, что на самом деле ограничивает пропускную способность: скорость передачи пакетов или задержка в сетевом пути — либо же узким местом являются приложение, шифрование и бэкэнды.

AF_XDP — это промежуточный вариант для команд, которые хотят обрабатывать пакеты на раннем этапе, но при этом оставаться близкими к сетевой модели Linux. Ядро описывает режим копирования, а также режим Zero Copy, который требует поддержки со стороны драйвера. Если явно запрашивается режим Zero Copy, создание сокета может завершиться сбоем, если драйвер не поддерживает эту возможность. Для понимания структуры уровня XDP полезна статья XDP и eXpress Data Path.

DPDK, напротив, использует драйверы в режиме опроса (Poll Mode Drivers) и обрабатывает очереди непосредственно из приложения. Это позволяет обойти сокетные и прерывательные компоненты в конвейере данных DPDK, но требует управления памятью, очередями и распределением ядер. Zero Copy Это не является ни общим обещанием производительности, ни автоматическим свойством любого пути DPDK; количество копий зависит от приложения, операций выгрузки и передачи данных в память.

Выберите стек ядра, если маршрутизация, брандмауэр, наблюдаемость и простота эксплуатации важнее, чем специализированный путь прохождения пакетов. Рассмотрите использование AF_XDP в случае целенаправленного ускорения с подключением к ядру. DPDK оправдывает себя только при наличии реальной потребности в высокой скорости обработки пакетов или стабильной задержке, поддержке сетевых карт и команде, способной на постоянной основе брать на себя дополнительную ответственность за эксплуатацию.

Грамотное планирование очередей, привязки процессоров и NUMA

Надежная Присвоение очереди Начинается с близости между сетевой картой (NIC), процессором (CPU) и памятью. EAL поддерживает выбор логических ядер, резервирование памяти и распределение ресурсов по устройствам. Для простого пути передачи данных обычно целесообразно жестко привязать очередь Rx к lcore, создать соответствующий mempool на локальном узле NUMA, а затем передать обработку в подходящую очередь Tx. Эти основные сведения об EAL подтверждаются документацией DPDK 25.07 и должны проверяться на соответствие используемому релиз-тегу в случае опций, зависящих от версии.

Примером хоста с двумя узлами NUMA, не связанным с конкретным продуктом, может служить следующая ситуация: сетевая карта на узле 0 получает две очереди приема (Rx); каждый ядро lcore на узле 0 полностью обрабатывает одну из этих очередей. Буферы пакетов также находятся на узле 0. Ещё одно ядро, не участвующее в опросе, остаётся свободным для выполнения административных задач, в то время как узел 1 предназначен для других служб или чётко разделённых путей передачи данных.

• Путь к данным: для каждой очереди — фиксированно назначенный lcore, локальные пулы памяти и четко обозначенные пары Rx/Tx.
• Администрирование: необходимо обеспечить свободные ресурсы процессора для телеметрии, управляющей логики, событий и служб операционной системы.
• Резерв: следует предусмотреть резервную мощность на случай пиковых нагрузок, устранения неисправностей и запланированных расширений, а не загружать все ядра постоянно.

Не следует разделять очередь Rx между несколькими lcores. В руководстве PMD не рекомендуется разделять очереди Rx и Tx, поскольку необходимые для этого глобальные блокировки могут значительно снизить производительность. Одновременный доступ нескольких lcores к очереди Tx допускается только в качестве задокументированного исключения, если драйвер поддерживает возможность RTE_ETH_TX_OFFLOAD_MT_LOCKFREE сообщает. Проверьте эту возможность для конкретной комбинации сетевой карты и PMD; не делайте выводов ни на основе скорости порта, ни на основе общего переключателя разгрузки.

Конвейер с разделенными этапами разбора, классификации и отправки позволяет более четко распределить обязанности. В документированном подходе с использованием конвейера пакеты передаются по кольцам другим ядрам; это приводит к дополнительным обращениям к памяти и передачам. Для простых фильтров или L4-перенаправления часто проще планировать режим «Run-to-completion» для каждой очереди. Несколько этапов следует использовать только в том случае, если распределение задач оправдывает дополнительные затраты в конкретном профиле нагрузки.

Также Аппаратная разгрузка не следует учитывать при планировании. Наличие функций контрольной суммы, сегментации, RSS или потоков зависит от возможностей конкретного устройства Ethernet и его PMD. Проверьте их перед началом проектирования и рассматривайте отсутствие функции разгрузки как обычный случай при планировании, а не как исключение.

Безопасный мониторинг работы DPDK

Для работы канала передачи данных DPDK требуются метрики, учитывающие как обработку пакетов, так и использование ресурсов. Необходимо отслеживать, как минимум, количество обработанных, отброшенных и поврежденных пакетов, а также собственные для приложения показатели скорости обработки, резервы mempool и Распределение латентности а не только одного среднего значения. Наличие дополнительных счетчиков портов, очередей или драйверов зависит от конкретного PMD, сетевой карты и приложения и должно проверяться для используемой комбинации.

Опрос — это сознательный конфликт целей. Lcore постоянно опрашивает свою очередь Rx, чтобы пакеты могли обрабатываться без использования стандартного пути прерываний. При небольшом трафике или его отсутствии цикл опроса тем не менее остается активным. Поэтому помимо lcore-ядер, отвечающих за трафик, следует заложить ресурсы ЦП для управляющей логики, телеметрии и операционной системы. Дополнительная документация EAL относится к версии DPDK 25.07; функции, зависящие от версии, необходимо проверять в установленной версии.

Для анализа причин важна временная корреляция. Если потеря пакетов происходит одновременно с увеличением счетчиков ошибок, сокращением резервов mempool или перегрузкой канала передачи данных lcore, это, в первую очередь, является проверяемыми признаками, но ещё не является однозначным доказательством причины. Колебания времени отклика могут быть связаны, в частности, с памятью, удалённой от NUMA, конкурирующими задачами или передачами в конвейере. Сравнивайте такие гипотезы с распределением ядер, распределением очередей и измеренными значениями за тот же временной интервал.

Быстрая регистрация данных на интерфейсе не означает полной и постоянной записи пакетов без потерь. Для статистики потоков или анализа заголовков может быть достаточно небольшого объёма метаданных. Если же требуется сохранять каждый пакет, то дополнительными ограничивающими факторами становятся пропускная способность памяти, объём буфера, скорость записи и выбранный носитель. При этом требования к защите данных и правилам хранения являются независимыми факторами, которые не могут быть решены за счёт пропускной способности сети.

Планируйте виртуальные машины и контейнеры в качестве отдельной задачи интеграции. Уточните для конкретной платформы, как обеспечиваются доступ к устройствам, хранение данных, распределение ресурсов ЦП и необходимые права. Проверьте эту комбинацию с помощью используемого PMD, вместо того чтобы без разбора принимать примерные параметры. Указанное руководство по Linux в настоящее время соответствует версии 26.11.0-rc1; для развертывания в производственной среде определяющим является документация к фактически установленному выпуску.

Систематическая проверка типичных неисправностей

При поиске неисправностей сначала следует отделить наблюдаемые симптомы от возможных причин. Не изменяйте одновременно привязку драйвера, номер очереди и параметры памяти, так как в этом случае будет невозможно определить, что именно вызвало проблему. Недеструктивные счетчики, данные о конфигурации и сравнение затронутой и незатронутой очереди, как правило, дают более достоверные указания перед тем, как приступать к вмешательству.

При обнаружении аномального поведения очереди проверь владельца очереди и NUMA-узел mempool. В модели «Run-to-completion» назначенное ядро lcore обрабатывает приём, обработку и отправку; конвейер передаёт пакеты другим ядрам. Тем не менее, не следует разделять очередь Rx между ядрами lcore. Одновременный доступ к очереди Tx возможен только при заявленном RTE_ETH_TX_OFFLOAD_MT_LOCKFREE-Эта возможность предусмотрена в качестве исключения. Самостоятельно установленное ограничение не делает совместное использование очередей рекомендуемой стратегией масштабирования.

При отсутствии аппаратной разгрузки правильный вопрос заключается не только в том, какой флаг установлен, но и в том, какие возможности фактически предоставляют устройство и PMD. Приложение может запланировать нужную функцию, даже если она недоступна для данной модели. Перед тем как сделать тракт передачи данных зависимым от данной разгрузки, сравните поддержку конкретной сетевой карты с возможностями, сообщаемыми во время выполнения.

Результаты testpmd следует рассматривать как базовые показатели или проверку работоспособности, а не как подтверждение производительности при последующем использовании. В режиме io-Forwarding пакеты пересылаются без изменений, без анализа их содержимого для специализированной обработки. Этот режим не поддерживает парсеры, таблицы потоков, NAT, шифрование и состояние протоколов. Документация по ссылке относится к версии 26.11.0-rc1; проверьте поведение в руководстве по установленному выпуску. Запишите режим пересылки, размер пакета, количество очередей приёма/передачи и количество ядер пересылки, а затем повторите сравнение с реальной логикой обработки.

Внедрение, сопровождение версий и принятие решения о вводе в эксплуатацию

Начните с изолированного теста и задокументированного профиль нагрузки: размеры пакетов, пиковая нагрузка, количество потоков и необходимые этапы обработки. Проверьте конкретную сетевую карту (NIC) вместе с подходящим драйвером в режиме опроса (Poll Mode) и необходимыми функциями, используя официальный обзор оборудования и матрицу драйверов. Само по себе наличие производителя в списке не подтверждает ни совместимость с каждой картой, ни поддержку всех функций разгрузки. Затем проведите тестирование с использованием реальной логики приложения, а не только с помощью примера перенаправления.

Записывайте версию DPDK, прошивку, драйверы, ядро и настройки для каждого теста. Перед обновлением ознакомьтесь с примечаниями к выпуску именно того релиз-тега, который планируется использовать, и зафиксируйте, какие изменения имеют отношение к вашему конфигурационному пути. Примечания к выпуску других версий не заменяют этого сопоставления, поскольку функции и ограничения могут меняться от релиза к релизу.

Одним из конкретных моментов, отмеченных в примечаниях к выпуску DPDK 26.07, является изменение алгоритма очистки и пополнения кэша Mempool: с тех пор его эффективный размер соответствует настроенному размеру; ранее он был на 50 процентов больше. Только в том случае, если каждый lcore из Mempool исключительно извлекает объекты или исключительно возвращает их, в примечаниях к выпуску рекомендуется удвоить настроенный размер кэша, чтобы избежать возможного удвоения частоты промахов кэша. Это касается, например, конвейеров с отдельными lcore Rx и Tx, но не всех конвейеров, работающих в режиме «Run-to-completion». Изменение касается версии 26.07; ссылка на страницу с историей выпусков теперь находится в документации к версии 26.11.0-rc1.

Начните с ограниченного пилотного проекта и четко определенных критериев прекращения. Сравните пропускную способность, высокие процентили задержки, потери пакетов и загрузку ЦП в одинаковых условиях с показателями прежней эксплуатации. Проверьте механизмы мониторинга, перезапуски и возврат к предыдущей конфигурации. Учтите эксплуатационные затраты; на их основе нельзя сделать вывод об общей гарантии пропускной способности.

Решение о внедрении DPDK оправдывается прежде всего в том случае, если измеряемая выгода оправдывает дополнительные затраты на обслуживание. Для определения места DPDK в окружающей системной платформе в данной статье приводится следующая информация: Ядро Linux в хостинговой среде Планирование. При тестировании обычных хостинг-сервисов сохраните существующий сетевой путь в качестве базы для сравнения.