hpnn-proto/docs/OVS_DPDK_MIGRATION.md

Переход на OVS-DPDK: перечень необходимых изменений

Дата: 2026-08-17 Зачем: в ПРОД-окружении нода HPNN (маршрутизатор и балансировщик) работает на выделенном физическом сервере с OVS-DPDK. Документ фиксирует, что для этого нужно изменить, что переносится как есть и где ожидаются потери. Основание: фактическое состояние стенда на 2026-08-17 (шаг 3).

1. Исходное состояние — что измерено

Параметр	Значение в стенде
Сборка OVS	3.1.0, dpdk_initialized=false, dpdk_version=none
Датапас	system@ovs-system — kernel datapath
datapath_type моста	пусто (то есть system)
Порты моста	11: pub0 (macvlan), p2/p3 (veth в docker-бридж), hcif-p2/hcif-p3 (internal), 6 veth к контейнерам ВМ
Правил в пайплайне	105 + 1024 в таблице слотов
Действия пайплайна	load 91, goto_table 52, move 36, learn 36, ct 16, IN_PORT 14, mod_dl_src 11, mod_dl_dst 10, multipath 4, dec_ttl 3
Состояние ct	~250 записей, 19 потоков датапаса с recirc

Вывод из инвентаризации: вся форвардинг-логика DPDK-совместима — все перечисленные действия поддерживает userspace-датапас (netdev). Переделке подлежит не пайплайн, а способ подключения портов, размещение узла и инструментарий. Отдельный разговор — производительность: ct, learn и multipath определяют её потолок (раздел 6).

2. Что переносится без изменений

• lb/pipeline.sh целиком — таблицы 0/1/5/6/10/11/12/15/16/20/21/24/25, включая ARP- и ICMP-респондеры (move/load/IN_PORT), dec_ttl, multipath(symmetric_l4), ct(commit,nat) и ct(nat), действие learn, рассылку по списку портов и fail_mode=secure.
• Логика Maglev (hc/maglev.go) и формат бандла ovs-ofctl — датапаса не касаются вовсе.
• Детерминизм выбора члена. multipath считается в ofproto, а не в датапасе, поэтому номер слота для одного 5-tuple не зависит от типа датапаса — раскладка и дайджест при переходе не меняются. Подлежит подтверждению спайком S-DPDK-1 (раздел 8).
• Адресная модель: VIP в правилах, шлюзы сегментов, уникальные адреса источника health-проб, PRIV_LISTENERS.

3. Изменения по слоям

3.1. Хост и ОС

Что	Требование
Hugepages	1 GB страницы, объём под dpdk-socket-mem + vhost-user; default_hugepagesz=1G hugepagesz=1G hugepages=N в cmdline
Изоляция ядер	isolcpus, nohz_full, rcu_nocbs для ядер PMD; PMD-ядра не отдаются планировщику
Драйвер NIC	vfio-pci (с iommu=pt intel_iommu=on), NIC отвязана от ядра
NUMA	PMD-ядра, hugepages и NIC — на одном сокете; проверять numactl -H и /sys/class/net/*/device/numa_node
Пакеты	OVS, собранный с DPDK (--with-dpdk), версии OVS и DPDK согласованы
Модуль openvswitch	не нужен — modprobe openvswitch из scripts/host-prereq.sh и lb/entrypoint.sh уходит

3.2. Конфигурация OVS

ovs-vsctl set Open_vSwitch . other_config:dpdk-init=true
ovs-vsctl set Open_vSwitch . other_config:dpdk-socket-mem="2048,0"
ovs-vsctl set Open_vSwitch . other_config:dpdk-lcore-mask=0x1
ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x3c      # ядра PMD
ovs-vsctl set Open_vSwitch . other_config:userspace-tso-enable=true
ovs-vsctl add-br br-lb -- set bridge br-lb datapath_type=netdev \
    -- set bridge br-lb fail_mode=secure \
    -- set bridge br-lb protocols=OpenFlow13,OpenFlow15

datapath_type=netdev на мосту — единственное изменение в самой сборке моста; fail_mode=secure и набор протоколов сохраняются.

3.3. Порты — главная переделка

Сейчас	В ПРОД на DPDK
pub0 — macvlan поверх enp3s0, перенесённый в netns контейнера	type=dpdk, options:dpdk-devargs=0000:xx:00.0; при необходимости dpdkbond для LAG
p2/p3 — veth в docker-бридж (аплинк сегмента к шлюзу Docker)	физический порт или VLAN-подынтерфейс к фабрике сегмента; шлюза Docker в ПРОД нет
Порты ВМ (be1…cli3) — veth, создаваемые scripts/attach-segment.sh через nsenter	type=dpdkvhostuserclient, options:vhost-server-path=/var/run/openvswitch/vhostuserN; порты создаёт гипервизор при старте ВМ
hcif-p2/hcif-p3 — type=internal с IP в ядре	type=internal в netdev-мосте (реализуется как tap) либо отдельная management-NIC в ядре — см. 3.5

Предпосылка шага 3 «порт ВМ — порт OVS» на DPDK выполняется естественно: vhost-user — это и есть порт моста. scripts/attach-segment.sh и make attach в ПРОД не нужны — вместе с network_mode: none и всей docker-обвязкой.

Дополнительно потребуется задать: mtu_request (jumbo, если фабрика позволяет), options:n_rxq и other_config:pmd-rxq-affinity для распределения очередей по PMD, options:n_rxq_desc/n_txq_desc.

3.4. Размещение узла: контейнер → сервер

• docker-compose.yml, lb/Dockerfile, privileged: true, /lib/modules:ro — уходят. Узел ставится на железо.
• lb/entrypoint.sh разделяется на: конфигурацию OVS (systemd-юнит ovs-vswitchd с DPDK-опциями), сборку моста и портов (штатный ovsdb-конфиг, а не скрипт при старте) и запуск hcd как systemd-сервиса.
• lb/topology.env остаётся источником правды, но описывает физические порты, PCI-адреса и пути vhost-user вместо MAC docker-интерфейсов. Опознание порта по MAC (find_dev_by_mac) заменяется на PCI-адрес и имя vhost-сокета.
• lb/apply.sh, lb/lbctl.sh работают как есть — они общаются с OVS через ovs-vsctl/ovs-ofctl локально; из них убираются обёртки docker compose exec.

3.5. Health-check (hc/)

Демон менять почти не нужно, но одно место требует решения: пробы уходят из сетевого стека ядра (net.Dialer.LocalAddr на адресе internal-порта). В DPDK-мосте такой порт — tap-устройство, и трафик проб идёт медленным путём через ядро. Для проб (единицы пакетов в секунду на члена) это допустимо, но требует проверки задержки и того, что tap не привязан к PMD-ядру.

Варианты, которые надо сравнить на спайке:

1. type=internal в netdev-мосте — минимум изменений, hcd остаётся как есть. Предпочтительный вариант по умолчанию.
2. Отдельная management-NIC в ядре — пробы идут в обход датапаса; требует маршрутной достижимости сегментов бэкендов, то есть меняет топологию.
3. Пробер поверх DPDK (собственный TCP-стек или AF_XDP) — снимает зависимость от ядра, но это отдельная разработка; вне рамок миграции.

Остальное в hc/ переносится без изменений: exec ovs-ofctl bundle, HTTP API, /metrics, Maglev, гистерезис.

3.6. Инструментарий и проверки

Файл	Что делать
scripts/host-prereq.sh	переписать: вместо modprobe openvswitch и macvlan-shim — hugepages, vfio-pci, проверка изоляции ядер и NUMA
scripts/attach-segment.sh	удалить: порты создаёт гипервизор
scripts/verify.sh	сохранить структуру проверок, заменить транспорт: docker compose exec → ssh/локальные вызовы на ВМ; добавить проверки PMD (загрузка, drops, pmd-rxq-show)
Makefile	цели up/down/attach/shim заменяются на управление сервисами; flows, health, slots, fdb, trace остаются
perftest/k6_bench.js	k6 через стек ядра не покажет предел DPDK: нужен генератор трафика (TRex, MoonGen, dpdk-pktgen) с профилем по новым соединениям в секунду, а не только по PPS

4. Что нужно решить до миграции — влияние на пайплайн

Ни одно из перечисленного не блокирует запуск, но каждое влияет на потолок производительности и должно быть решено осознанно.

Механизм	Где	Состояние на DPDK	Решение
ct(commit,nat) / ct(nat)	t12, t15, t24	userspace conntrack работает, включая NAT	оставить на первом этапе; параллельно вести переход на stateless un-DNAT (nw_src=member, tp_src=8080 → VIP:80) — он уже стоит в заделе шага 3
learn (FDB t25, adjacency t21)	t0, t1	работает, но каждый новый MAC/адрес — upcall; несовместим с полным HW offload	для ВМ состав сегмента известен control plane: заменить обучение на статические записи, оставив learn только как страховку
multipath	t10	считается в ofproto, работает	оставить; проверить детерминизм спайком
recirculation	после ct	работает	учесть в бюджете PMD-цикла: каждый recirc — повторный проход
IN_PORT, рассылка по списку портов	t5, t25	работает	при большом числе ВМ в сегменте заменить рассылку на явные группы вывода
type=internal	hcif-*	tap, медленный путь	см. 3.5
Hardware offload (hw-offload=true, rte_flow)	—	несовместим с ct, learn, multipath, recirc	на первом этапе не включать; рассматривать только после перехода на stateless-датапас

5. Изменения по файлам — сводка

Файл	Действие
lb/pipeline.sh	без изменений (кроме подстановки новых номеров портов)
hc/maglev.go, hc/main.go	без изменений; открытый вопрос — источник проб (3.5)
lb/topology.env	переписать порты: PCI-адреса, пути vhost-user, номера ofport
lb/entrypoint.sh	разделить на systemd-юниты и конфигурацию OVS
lb/apply.sh, lb/lbctl.sh	убрать обёртки docker compose exec
docker-compose.yml, lb/Dockerfile	не применяются в ПРОД (остаются для стенда)
scripts/attach-segment.sh	удалить
scripts/host-prereq.sh	переписать под hugepages/vfio/NUMA
scripts/verify.sh	адаптировать транспорт, добавить PMD-проверки
perftest/	заменить k6 на аппаратный генератор
Makefile	цели жизненного цикла заменить на управление сервисами

6. Потолок производительности — что определяет предел

Главный вывод анализа: на DPDK узкое место сместится с PPS на число новых соединений в секунду (CPS).

• multipath вычисляет слот от 5-tuple, поэтому megaflow для балансируемого трафика матчит полный 5-tuple: каждое новое соединение даёт upcall и собственную запись в датапасе. То же делает ct(commit).
• Установленные соединения обслуживаются из кэшей (EMC → SMC → megaflow) на скорости PMD; проблема только в темпе появления новых.
• Настройки, влияющие на это: размер EMC (emc-insert-inv-prob), число handler threads, pmd-cpu-mask, n_rxq.

Отсюда программа измерений: отдельно PPS на установленных потоках и отдельно CPS на новых. Сравнивать надо с текущим kernel-датапасом на том же профиле, иначе цифры не сопоставимы.

Второй фактор — recirculation после каждого ct: удваивает число проходов по таблицам для балансируемого трафика.

7. План миграции по этапам

Этап	Содержание	Критерий готовности
1	Стенд с datapath_type=netdev на том же железе, порты — dpdkvhostuser + одна физическая NIC	все текущие проверки verify.sh проходят, дайджест раскладки совпадает с kernel-датапасом
2	Спайки S-DPDK-1…3 (раздел 8)	детерминизм подтверждён, источник проб выбран, CPS измерен
3	Замена learn на статические записи от control plane	FDB и adjacency не зависят от трафика; verify.sh зелёный
4	Stateless un-DNAT вместо ct в t15 и t24	сессии живут, dump-conntrack пуст, recirc-проходов меньше
5	Профилирование и тюнинг: n_rxq, pmd-rxq-affinity, hugepages, TSO	целевые PPS и CPS достигнуты, PMD без drops
6	Оценка HW offload (только после этапа 4)	измеренный выигрыш против потери гибкости

Порядок не произвольный: этапы 3 и 4 снимают именно те механизмы, которые блокируют offload и дают upcall на каждое соединение.

8. Спайки, которые надо выполнить до перевода ПРОД

• S-DPDK-1 — детерминизм multipath. Один и тот же корпус синтетических 5-tuple через ofproto/trace на kernel- и netdev-датапасе обязан давать одинаковые reg1/reg2. Блокирующий: на нём стоит вся модель раскладки.
• S-DPDK-2 — ct с NAT в userspace. Проверить обратную трансляцию в t15 и t24, поведение при переполнении таблицы соединений, стоимость recirc.
• S-DPDK-3 — источник health-проб. Работает ли type=internal в netdev-мосте, какова задержка проб под нагрузкой PMD, не голодает ли tap.
• S-DPDK-4 — CPS и PPS. Аппаратный генератор: предел по новым соединениям и по установленным потокам, с профилем, приближенным к целевому.

9. Открытые вопросы к разработке и эксплуатации

1. Сколько ВМ в сегменте ожидается — от этого зависит, допустима ли рассылка списком портов в t25 и нужны ли группы вывода.
2. Нужен ли dpdkbond/LACP на аплинке и VLAN-теги на портах сегментов — сейчас VLAN в пайплайне не используется вовсе.
3. Целевые MTU и включение TSO для vhost-user.
4. Кто создаёт vhost-user порты и заполняет topology.env — гипервизор, оркестратор или control plane HPNN (это же вопрос модели Load_Balancer → Listener → Pool → Member в OVSDB).
5. Останется ли профиль A (default бэкенда мимо балансировщика) или в ПРОД используется профиль B — от этого зависит объём egress через узел.
6. Где живёт узел относительно фабрики: сегменты приходят отдельными портами, VLAN'ами или туннелями.

10. Чек-лист конфигурации перед вводом в эксплуатацию

# датапас и DPDK
ovs-vsctl get Open_vSwitch . dpdk_initialized          # true
ovs-vsctl get bridge br-lb datapath_type               # netdev
ovs-appctl dpif/show                                   # netdev@ovs-netdev

# PMD и очереди
ovs-appctl dpif-netdev/pmd-rxq-show
ovs-appctl dpif-netdev/pmd-stats-show                  # drops, cycles
ovs-appctl dpif-netdev/pmd-perf-show

# хост
cat /proc/meminfo | grep Huge
lscpu | grep -i numa; numactl -H
dpdk-devbind.py --status                               # NIC на vfio-pci

# функциональность (как в стенде)
make flows && make health && make slots && make fdb
lbctl trace <src> <sport> p2