Принципы проектирования

• Привязывайте стек протоколов к независимым ЦПУ и очередям сетевых адаптеров, используя режим опроса для приема пакетов, чтобы избежать перебора прерываний и планирования.
• Используйте отдельные пулы памяти и ресурсы потока для стека протоколов (например, локальные переменные потока, таблицы ARP/UDP/TCP) для минимизации конфликтов блокировки и пропусков кэша, обеспечивая линейную масштабируемость.
• Распределяйте запросы между аппаратной частью сетевых адаптеров (RSS/flow director) или программной (таблица хешей) для балансировки нагрузки, направляя трафик в различные стеки протоколов.
• Предоставьте стандартный POSIX API без необходимости каких-либо модификаций для приложений.

Модели потоков

1. Отдельная модель потока

• Подходит для сценариев с большим количеством бизнес-потоков, поддерживающих использование FD между потоками (общий случай использования).
• Разделите потоки стека протоколов от бизнес-потоков: аналогично реализации мягких прерываний в ядре Linux, стек протоколов пробуждает бизнес-потоки после получения запросов.
• Высокоскоростной блок-бесплатный чтение/запись: бизнес-потоки recv/send данных через блок-бесплатные очереди, избегая конфликта блокировки со стеком протоколов. Другие запросы сокета управления отправляются в потоки стека протоколов через RPC.### 2. Общая модель потока

• Подходит для сценариев, где количество бизнес-сетевых потоков невелико, а число потоков фиксировано. FD не используются между потоками.
• Стек протоколов и бизнес-потоки используют одинаковый контекст: бизнес и стек протоколов выполняют работу в одном контексте, выполняя опрос пакетов внутри poll/epoll.
• Наивысшая производительность: эксклюзивное использование ЦПУ без необходимости планирования пробуждения, но длительная обработка бизнеса может привести к потере пакетов в стеке протоколов.
• Каждый бизнес-поток может прослушивать разные порты или иметь меньше очередей сетевых адаптеров, чем потоков, требуются балансировка и маршрутизация трафика.

Многопроцессный режим

1. Процесс эксклюзивного сетевого адаптера

* Виртуализация сетевого адаптера SR-IOV — широко используемая технология, которая позволяет одному PF сетевого адаптера виртуализировать несколько VF сетевых адаптеров, делиться полосой пропускания сетевого адаптера.

• Виртуализация PF/VF основана на аппаратном свитче для перенаправления второго уровня, с копированием DMA между сетевыми адаптерами. Таким образом, каждый сетевой адаптер может быть привязан отдельно к драйверам пространства ядра и пространства пользователя.
• Совместима с протоколами стека ядра, что позволяет обрабатывать недоступные или неконфигурируемые протоколы с минимальной потерей производительности.

2. Общий процессорный сетевой адаптер (NIC)* Подходит для сценариев, где количество сетевых адаптеров ограничено, а несколько процессов должны использовать один NIC. Однако изоляция процессов может быть недостаточной.

• Каждый бизнес-процесс/поток может прослушивать различные порты или иметь меньше очередей NIC, чем потоков, что требует балансировки и пересылки трафика.

Текущее программное решение для пересылки (ltran): хорошая изоляция, плохая производительность

• Концептуальное основание: изоляция процессов, отсутствие влияния на другие бизнес-процессы при перезапуске.
• ltran действует как независимый процесс пересылки, используя отдельные ЦПУ для приемных и передающих потоков, по одному ядру каждому.
• ltran использует физический NIC, в то время как бизнес-процессы используют программные очереди.
• Чтобы предотвратить утечки памяти, между процессами происходит копирование пакетов.

Текущее аппаратное решение для пересылки: плохая изоляция, хорошая производительность* Каждый процесс использует режим работы мастер-слейва DPDK, делится большим адресным пространством страниц, пакеты пересылаются между процессами без копирования.

• Из-за общего большого адресного пространства страниц нет изоляции между процессами. Для предотвращения утечек памяти эти процессы должны рассматриваться как единое целое, запускаться и останавливаться вместе.
• Функциональность аппаратной пересылки Flow Director не универсальна.
• Число очередей NIC является постоянным и определяется во время инициализации, поддерживающим фиксированное количество потоков протокольной стековой системы.### 3. Балансировка и пересылка трафика

Цели дизайна:

• Интеграция программных и аппаратных решений для пересылки.
• Удаление центральных узлов пересылки и кросс-процессного копирования, предотвращающего утечки ресурсов при необычном завершении процессов.

Программное решение для пересылки

• Отсутствие дополнительного выделенного ЦПУ как независимого потока; выполняется после получения пакета в протокольном стеке.
• Реализовано на основе хэш-таблиц DPDK, поддерживающих параллельное чтение и запись.
• Каждая очередь оборудования NIC соответствует программной очереди, распределяющей пакеты другим потокам через программные очереди. Программные очереди используют модель множества производителей/единственного потребителя.

Решение по управлению памятью

Требуется управляющий узел для мониторинга состояний процессов и освобождения ресурсов при нормальном/необычном завершении процессов. При запуске потока протокольного стека:* queue_alloc: выделение queue_id, представляющего очередь аппаратуры сетевой карты (NIC) и программную очередь маршрутизации, используемую для приема и передачи пакетов.

• rule_add: добавление правил маршрутизации во время connect/listen и удаление их во время close.

• memp_alloc: выделение серии memp (около десяти) для пула памяти фиксированной длины протокольного стека. Примечание: создается memp_list, который используется для хранения всех memp потоков протокольного стека для последующего освобождения.

• mbuf_get: каждый queue_id связан с mbufpool, используемым для приема и передачи пакетов.При завершении работы потока протокольного стека:

• queue_free: освобождение queue_id, что приводит к временной потере пакетов в этой очереди.

• rule_delete: прохождение по таблицам соединений TCP и UDP протокольного стека для удаления правил маршрутизации.

• memp_free: прохождение по memp_list для освобождения всех memp.

• mbuf_put: прохождение по mbufpool с использованием rte_mempool_walk() и rte_mempool_obj_iter для возврата незапрошенных mbufs.

Управление памятью mbuf

Поток данных пакетов:

• #1 Прием пакетов: Каждая очередь NIC связана с L1_mbufpool. Mbufs выделяются NIC-драйвером и освобождаются Gazelle.

• #2 Передача пакетов: Gazelle запрашивает mbufs из L1_mbufpool, а после завершения передачи NIC mbufs освобождаются.

• #3 Передача пакетов при давлении на память: Когда память становится недоступной из-за большого количества соединений, то есть когда L1_mbufpool падает ниже нижней границы, создается L2_mbufpool для передачи.

Проблемы конкуренции mbufpool:

• Кэши на уровне соединения заменены кэшами на уровне процессора, как указано в rte_mempool_default_cache().
• Когда mbufpool падает ниже нижней границы, флаг rte_lcore_id() отключается, и проводится сканирование для возврата памяти из кэшей уровня процессора.

Тестирование DT

Существующие проблемы:* Требуются физические/виртуальные сетевые адаптеры и два хоста; низкий уровень автоматизации тестирования; покрывает только "решение программной маршрутизации ltran".Цели дизайна:

• Отсутствие зависимости от аппаратной среды (один узел, нет требований к физическим/виртуальным сетевым адаптерам), однокликовая автоматизация развертывания, быстрый результат (в течение 10 минут). Выступает в роли барьера для разработки.
• Проектирование пользовательского виртуального сетевого адаптера, user-veth, используя программные очереди для имитации очередей оборудования сетевых адаптеров с использованием rte_softrss для имитации балансировки нагрузки RSS.
• Проектирование виртуального моста, user-vbridge, используя хэширование для имитации второго уровня пересылки данных.
• Тестирование запуска физического сетевого адаптера, аппаратного выгрузочного режима и производительности сети только при необходимости. При наличии только одного узла несколько VF сетевых адаптеров могут быть виртуализированы с помощью SR-IOV для тестирования.

Оптимизация производительности - TODO

• rte_trace
• rte_metrics