Различия

Показаны различия между двумя версиями страницы.

--- dpi:dpi_components:platform:dpi_config [2020/09/21 07:11] – ↷ Страница перемещена из dpi:dpi_options:dpi_divert_spec:star:dpi:dpi_components:platform:dpi_config в dpi:dpi_components:platform:dpi_config lexx26
+++ dpi:dpi_components:platform:dpi_config [2024/09/26 15:29] (текущий) – внешнее изменение 127.0.0.1
@@ Строка 1: / Строка 1: @@
-====== Настройка ======
+====== Настройка DPDK интерфейсов ======
-{{indexmenu_n>3}}
+{{indexmenu_n>1}}
-Настройки DPI платформы находятся в файле /etc/dpi/fastdpi.conf
-==Конфигурирование используемых сетевых интерфейсов:==
+[[https://www.dpdk.org/|DPDK]] (Data Plane Development Kit) позволяет работать с сетевыми картами напрямую, фактически без посредничества ядра Linux, тем самым повышается производительность решения. DPDK поддерживает намного больше моделей сетевых карт, чем pf_ring, и намного более богатый интерфейс работы с ними, что позволяет реализовать различные схемы работы с картами, подходящие как для 10G трафика, так и для трафика 25G, 40G, 100G и т.д.
-интерфейсы конфигурируются парами "вход"-"выход" (для последующего удобства конфигурирования опций интерфейс "вход"
-должен быть обращен во внутреннюю сеть оператора, а "выход" в сторону аплинка). Каждая пара образует сетевой мост,
-прозрачный на уровне L2. Доступные для конфигурирования интерфейсы имеют специальные имена вида dna<цифра>.
-==Пример 1==
+===== Подготовка системы =====
-Создает следующие пары (мосты)\\
-dna0 <--> dna1\\
+Начальная установка DPI делается техподдержкой VAS Experts, просьба не пытаться делать начальную установку самостоятельно, так как
-dna2 <--> dna3\\
+потом может потребоваться проверить все сделанные вами шаги, что увеличивает трудоемкость работ ТП.
-dna4 <--> dna5\\
+Далее вы сможете самостоятельно добавить или удалить сетевые порты и изменить конфигурацию.
+===== Конфигурирование портов =====
+Сетевые карты, с которыми будет работать СКАТ, выведены из-под управления операционной системы и поэтому как Ethernet устройства для нее не видны.
+DPDK адресует Ethernet устройства по их PCI идентификаторам, которые можно получить командой:
 <code>
-in_dev=dna0:dna2:dna4
+lspci -D|grep Eth
-out_dev=dna1:dna3:dna5
+:04:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
+:04:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
 </code>
+Эта команда выведет список всех PCI-устройств типа ethernet. Каждая строка начинается с системного идентификатора PCI-устройства, - именно эти PCI-идентификаторы являются уникальными идентификаторами сетевой карты в DPDK.
-==Пример 2==
+Список карт в режиме DPDK можно проверить командой ''[[dpi:dpi_components:utilities:management_utilities|driverctl list-overrides]]''.\\ Вывод:
-Полноценный файл конфигурации DPI для фильтрации по реестру Роскомнадзора и Минюста:
 <code>
-in_dev=dna0
+:04:00.0 vfio-pci
-out_dev=dna1
+:04:00.1 vfio-pci
-federal_black_list=true
 </code>
-В процессе установки системы могли быть сделаны другие важные настройки системы, которые не следует удалять,
+При необходимости карты можно вывести из режима DPDK [[dpi:dpi_components:utilities:management_utilities|командой]], при этом для них активируется штатный драйвер Linux.
-и можно изменять только если вы понимаете последствия того, что делаете. Вот некоторые из них:
+Предварительно остановить процесс Fastdpi
 <code>
-#Scale factor is about 1 for every 1 Gigabit of bandwidth
+service fastdpi stop
-scale_factor=10
+</code>
-timeout_check_dev=0
-#FDPI Control
+<code>
-ctrl_port=29000
+driverctl unset-override 0000:04:00.0
-ctrl_dev=lo
+driverctl unset-override 0000:04:00.1
+</code>
-#Turn on UDP detection
+После работ со штатных драйвером не забудьте вернуть их обратно под управление DPDK [[dpi:dpi_components:utilities:management_utilities|командой]]
-only_tcp=0
+<code>
+driverctl -v set-override 0000:04:00.0 vfio-pci
+driverctl -v set-override 0000:04:00.1 vfio-pci
+</code>
+<note important>При переводе карт в режим DPDK будьте внимательны и не переведите случайно управляющий интерфейс сервера в режим DPDK - связь с сервером сразу прервется!</note>
+<note important>В старых инсталляциях вместо vfio-pci использовался драйвер igb_uio, что можно увидеть в выводе команды<code>
+driverctl list-overrides
+:04:00.0 igb_uio</code>
+В этом случае рекомендуется перейти на использование драйвера vfio-pci
+для чего выполнить команды
+<code>echo "options vfio enable_unsafe_noiommu_mode=1" > /etc/modprobe.d/vfio-noiommu.conf
+driverctl -v set-override 0000:04:00.0 vfio-pci</code>
+для всех устройств из списка возращаемого list-overrides.
+Установка ''enable_unsafe_noiommu_mode=1'' может потребовать ребута сервера.
+ </note>
-#Turn on UDR
+===== Конфигурирование СКАТ =====
-udr=1
+После того, как система настроена для работы с DPDK, можно приступать к конфигурированию СКАТ. Интерфейсы конфигурируются парами «вход»-«выход» (для последующего удобства конфигурирования опций интерфейс «вход» должен быть обращен во внутреннюю сеть оператора, а «выход» в сторону аплинка). Каждая пара образует сетевой мост, прозрачный на уровне L2. В качестве имен интерфейсов выступают PCI-идентификаторы с заменой ':' на '-' (так как символ ':' в имени интерфейса зарезервирован в СКАТ для разделения интерфейсов в одном кластере) и без начального префикса "0000:" - он у всех одинаковый:
+<code>
+   # Вход - порт 41:00.0
+in_dev=41-00.0
+   # Выход - порт 41:00.1
+out_dev=41-00.1
 </code>
+Такая конфигурация задает единственный мост 41-00.0 ←→ 41-00.1 \\
+Можно указывать группу интерфейсов через ':'
+<code>
+in_dev=41-00.0:01-00.0:05-00.0
+out_dev=41-00.1:01-00.1:05-00.1
+</code>
+Эта группа образует следующие пары (мосты): \\
+-00.0 ←→ 41-00.1 \\
+-00.0 ←→ 01-00.1 \\
+-00.0 ←→ 05-00.1 \\
+В парах должны быть устройства одинаковой скорости; недопустимо объединять в пару 10G и 40G карты. Однако, в группе могут быть интерфейсы разной скорости, например, одна пара 10G, другая - 40G.
+Maксимальный размер ethernet-пакета на девайсах задается опцией ''snaplen'' в fastdpi.conf, по умолчанию ''snaplen=1540''.
+===== Задание псевдонимов девайсов =====
+В СКАТ 9.5.3 появилась возможность задавать псевдонимы (alias) девайсов. Вызвано это тем, что DPDK поддерживает большое количество девайсов, не только PCI, но и, например, vmbus-девайсы (Hyper-V) или виртуальные девайсы vdev. Кроме того, каждый DPDK-драйвер поддерживает свой набор конфигурационных параметров для тонкой настройки. Синтаксис описания таких девайсов несовместим с синтаксисом задания в ''in_dev''/''out_dev'', поэтому введено понятие псевдонима девайса.
+Суть псевдонима очень проста: вы описываете необходимый девайс в отдельном параметре и задаете этому описанию имя. Далее в параметрах ''in_dev'', ''out_dev'', ''tap_dev'' (и во всех остальных, которые ссылаются на девайсы из ''in_dev'' и ''out_dev'') вы указываете это имя - псевдоним девайса.
+Каждый псевдоним задается отдельным параметром ''dpdk_device'':
+<code>
+dpdk_device=alias:bus:device-description
+</code>
+здесь:
+  * ''alias'' - задает псевдоним девайса (например, eth1). В псевдониме допустимы только буквы и цифры.
+  * ''bus'' - тип шины: ''pci'', ''vmbus'', ''vdev''
+  * ''device-description'' - описатель девайса в синтаксисе, принятом в DPDK
+Например:
+<code>
+  # eth1 - псевдоним PCI-девайса 41:00.0
+dpdk_device=eth1:pci:41:00.0
+  # eth2 - псевдоним PCI-девайса 41:00.1
+dpdk_device=eth2:pci:41:00.1
+in_dev=eth1
+out_dev=eth2
+</code>
+Это описание эквивалентно следующему:
+<code>
+in_dev=41-00.0
+out_dev=41-00.1
+</code>
+Отметим, что в ''dpdk_device'' PCI-девайс задается в каноническом виде ''41:00.0''.
+<note tip>Для PCI-девайсов задание в ''in_dev''/''out_dev'' через псевдонимы не обязательно, можно использовать прежнюю нотацию.</note>
+Если требуется подключить Hyper-V девайсы (а это не PCI, а VMbus-девайсы), то использование псевдонимов обязательно. Пример:
+<code>
+dpdk_device=subs1:vmbus:392b7b0f-dbd7-4225-a43f-4c926fc87e39
+dpdk_device=subs2:vmbus:58f75a6d-d949-4320-99e1-a2a2576d581c,latency=30
+dpdk_device=inet1:vmbus:34f1cc16-4b3f-4d8a-b567-a0eb61dc2b78
+dpdk_device=inet2:vmbus:aed6f53e-17ec-43f9-b729-f4a238c49ca9,latency=30
+in_dev=subs1:subs2
+out_dev=inet1:inet2
+</code>
+Здесь мы не только задаем псевдоним, но и указываем аргумент ''latency=30'' для DPDK-драйвера. В принципе, каждый драйвер DPDK поддерживает свой набор аргументов, см. [[https://doc.dpdk.org/guides/nics/index.html|документацию DPDK]] соответствующей версии (версия DPDK, с которой собран СКАТ, выводится в ''fastdpi_alert.log'' при старте, а также при вызове ''fastdpi -ve''). Следует отметить, что бездумное задание аргументов для драйвера может привести к труднообнаружимым ошибкам и потере работоспособности СКАТа, поэтому не советуем пользоваться этой возможностью без консультаций с нашей техподдержкой.
+===== Конфигурирование в Hyper-V =====
+Начиная с версии 9.5.3, СКАТ поддерживает работу в виртуальной машине Hyper-V.
+На гостевой [[veos:installation|VEOS]] должны быть установлены:
+<code>
+   # Поддержка multi-queue - необходима для СКАТ
+dnf install kernel-modules-extra
+</code>
+<note important>Host-система (Windows) должна поддерживать multiple channel для виртуализованных сетевых карт</note>
+Девайсы в Hyper-V являются VMBus-, а не PCI-девайсами, поэтому им требуется особый перевод в режим DPDK.
+Каждый девайс (интерфейс) идентифицируется своим уникальным идентификатором UUID, поэтому сначала нужно узнать UUID всех интерфейсов, с которыми будет работать СКАТ. Затем нужно перевести девайс в DPDK-режим:
+<code>
+# переводим интерфейсы eth0 и eth2 в DPDK-режим
+for DEV in eth0 eth2
+do
+    # получаем UUID девайса
+    DEV_UUID=$(basename $(readlink /sys/class/net/$DEV/device))
+    # переводим в DPDK compatible mode
+    driverctl -b vmbus set-override $DEV_UUID uio_hv_generic
+    # Device appears in
+    # /sys/bus/vmbus/drivers/uio_hv_generic/$DEV_UUID
+    echo "$DEV uuid=$DEV_UUID"
+done
+</code>
+При необходимости интерфейс может быть переведен обратно в kernel-режим так:
+<code>
+ETH0_UUID=<eth0_UUID>
+driverctl -b vmbus unset-override $ETH0_UUID
+</code>
+Далее конфигурируем СКАТ — задаем девайсы в ''fastdpi.conf''. При этом используем [[#задание_псевдонимов_девайсов|псевдонимы]] для указания UUID, которые мы только что узнали:
+<code>
+   # eth0 UUID=392b7b0f-dbd7-4225-a43f-4c926fc87e39
+dpdk_device=eth0:vmbus:392b7b0f-dbd7-4225-a43f-4c926fc87e39
+   # eth2 UUID=34f1cc16-4b3f-4d8a-b567-a0eb61dc2b78
+dpdk_device=eth2:vmbus:34f1cc16-4b3f-4d8a-b567-a0eb61dc2b78
+   # далее везде используем псевдонимы eth0 и eth2 при указании девайсов
+in_dev=eth0
+out_dev=eth2
+</code>
+===== Кластеры =====
+DPDK-версия СКАТ поддерживает кластеризацию: можно указывать, какие интерфейсы входят в каждый кластер. Разделителем кластеров является символ '|'
+<code>
+in_dev=41-00.0|01-00.0:05-00.0
+out_dev=41-00.1|01-00.1:05-00.1
+</code>
+Этот пример создает два кластера:
+  * кластер с мостом 41-00.0 ←→ 41-00.1
+  * кластер с мостами 01-00.0 ←→ 01-00.1 и 05-00.0 ←→ 05-00.1
+Кластеры являются в большей мере наследием pf_ring-версии СКАТ: в pf_ring кластер является базовым понятием, означающим "один поток диспетчера + RSS потоков-обработчиков", и это чуть ли не единственный способ масштабирования. Недостатом кластерного подхода является то, что кластеры физически изолированы друг от друга: невозможно переслать пакет с интерфейса X кластера #1 на интерфейс Y кластера #2. Это может являться значительным препятствием в режиме L2 BRAS СКАТ.
+В DPDK кластеры также изолированы друг от друга, но в отличие от pf_ring здесь кластер - понятие во многом логическое, наследуемое от pf_ring. DPDK намного гибче, чем pf_ring, и позволяет строить сложные многомостовые конфигурации со множеством диспетчеров без использования кластеров. Фактически, единственным аргументом "за" кластеризацию в DPDK-версии СКАТ является случай, когда у вас к СКАТ подключены две независимые сети A и B, которые никоим образом не должны взаимодействовать друг с другом.
+<note tip>Совет: вместо использования кластеров рассмотрите переход на другой ''dpdk_engine'', более подходящий под вашу нагрузку</note>
+Далее при описании конфигураций предполагается, что есть только один кластер (то есть кластеризация не используется).
+===== Число ядер (потоков) =====
+Ядра CPU являются, пожалуй, самым критичным ресурсом СКАТ. Чем больше физических ядер имеется в системе, тем больший трафик сможет обрабатывать СКАТ.
+<note important>СКАТ не использует Hyper-Threading: учитываются только реальные физические ядра, а не логические</note>
+Для работы СКАТу нужны следующие потоки:
+  * потоки обработки - обрабатывают входящие пакеты, пишут в TX-очереди карты;
+  * потоки диспетчера - читают RX-очереди карты и раскидывают входящие пакеты по потокам обработки;
+  * служебные потоки - выполняют отложенные (продолжительные) действия, принимают и обрабатывают команды fdpi_ctrl и CLI, связь с PCRF, отправка netflow
+  * системное ядро - выделено для работы операционной системы.
+Потоки обработки и диспетчера не могут располагаться на одном ядре. При старте СКАТ привязывает потоки к ядрам.
+СКАТ по умолчанию выбирает число потоков-обработчиков в зависимости от скорости интерфейса:\\
+G - 4 потока\\
+G - 8 потоков\\
+G, 50G, 56G - 16 потоков\\
+G - 32 потока\\
+Для группы число потоков равно сумме числа потоков для каждой пары; например, для таких карт
+<code>
+   # 41-00.x - 25G NIC
+   # 01-00.x - 10G NIC
+in_dev=41-00.0:01-00.0
+out_dev=41-00.1:01-00.1
+</code>
+будет создано 12 потоков обработки (8 для 25G карты и 4 для 10G)
+В fastdpi.conf можно явно указать число потоков на кластер с помощью параметра ''num_threads'':
+<code>
+   # 41-00.x - 25G NIC
+   # 01-00.x - 10G NIC
+in_dev=41-00.0:01-00.0
+out_dev=41-00.1:01-00.1
+num_threads=8
+</code>
+Такая конфигурация создаст 8 потоков обработки.
+<note important>СКАТ при планировании ядер учитывает NUMA node, к которой относятся ядра и карта: если карта на NUMA node 0, СКАТ назначит потоки обработчиков и диспетчеров также на NUMA node 0. Если ядер в NUMA node не хватает, СКАТ не запустится</note>
+Кроме потоков-обработчиков, для работы нужен также как минимум один поток-диспетчер (и значит, еще как минимум одно ядро), читающий rx-очереди интерфейсов. Задача диспетчера - чтобы пакеты, относящиеся к одному flow, попадали в один и тот же поток обработчика.
+Внутренняя архитектура работы с одним или множеством диспетчеров разительно отличается, поэтому СКАТ предоставляет несколько движков, конфигурируемых параметром ''dpdk_engine'' файла конфигурации fastdpi.conf:
+  * ''dpdk_engine=0'' - read/write движок по умолчанию, один диспетчер на все;
+  * ''dpdk_engine=1'' - read/write движок с двумя потоками-диспетчерами: на каждое направление по диспетчеру;
+  * ''dpdk_engine=2'' - read/write движок с поддержкой RSS: для каждого направления создается ''dpdk_rss'' диспетчеров (по умолчанию ''dpdk_rss=2''), таким образом, общее количество диспетчеров = ''2 * dpdk_rss'';
+  * ''dpdk_engine=3'' - read/write движок с отдельным диспетчером на каждый мост.
+Далее подробно описываются все эти движки, особенности их настройки и области применения, но сначала - общее замечание про потоки диспетчеров.
+==== Явная привязка к ядрам ====
+Можно задать в fastdpi.conf явную привязку потоков к ядрам. За это отвечают параметры:
+  * ''engine_bind_cores'' - список номеров ядер для потоков-обработчиков
+  * ''rx_bind_core'' - список номеров ядер для потоков диспетчеров
+Формат задания этих списков одинаков:
+<code>
+# 10G карты - 4 потока обработчика, 1 диспетчер на кластер
+in_dev=01-00.0|02-00.0
+out_dev=01-00.1|02-00.1
+# Привязываем потоки обработки для кластера #1 к ядрам 2-5, диспетчер - к ядру 1
+#    для кластера #2 к ядрам 7-10, диспетчер - к ядру 6
+engine_bind_cores=2:3:4:5|7:8:9:10
+rx_bind_core=1|6
+</code>
+Для бескластерного задания:
+<code>
+# 10G карты - 4 потока обработчика на карту
+in_dev=01-00.0:02-00.0
+out_dev=01-00.1:02-00.1
+# 2 диспетчера (по направлениям)
+dpdk_engine=1
+# Привязка потоков обработчиков и диспетчеров
+engine_bind_cores=3:4:5:6:7:8:9:10
+rx_bind_core=1:2
+</code>
+Как уже отмечалось, потоки обработчиков и диспетчеров должны иметь выделенные ядра; не допускается привязывать несколько потоков к одному ядру, - СКАТ при этом выругается в fastdpi_alert.log и не будет запускаться.
+<note tip>Явная привязка к ядрам может быть применена только в экстренных случаях; обычно достаточно автоматической привязки. Для выяснения номеров ядер советуем запустить СКАТ с автоматической привязкой (без параметров ''engine_bind_cores'' и ''rx_bind_core'') и посмотреть в fastdpi_alert.log дамп топологии системы: номер ядра - это lcore</note>
+<note important>При явной привязке СКАТ строго следует заданным в fastdpi.conf параметрам и не учитывает NUMA node, что может негативно сказаться на производительности (минус 10% - 20%)</note>
+===== Загрузка потока диспетчера =====
+Значение загрузки потока диспетчера, близкое к 100%, не говорит о том, что диспетчер не справляется: DPDK предполагает, что данные с карты считываются потребителем (это как раз и есть диспетчер) без каких-либо прерываний типа "пришли данные", поэтому диспетчер постоянно опрашивает состояние rx-очередей интерфейсов на наличие пакетов (так называемый poll mode). Если в течение N циклов опроса не принято ни одного пакета, диспетчер засыпает на несколько микросекунд, что вполне достаточно для снижения нагрузки на ядро до единиц процентов. Но если пакеты поступают раз в N-i циклов опроса, диспетчер не будет переходить в режим сна, и загрузка ядра будет 100%. Это нормально.
+<note tip>Загрузку потоков СКАТа можно посмотреть следующей командой:
+<code>
+top -H -p `pidof fastdpi`
+</code>
+</note>
+Истинное состояние каждого диспетчера можно увидеть в fastdpi_stat.log, - в него, помимо прочего, периодически выводится статистика по диспетчерам вида:
+<code>
+[STAT    ][2020/06/15-18:17:17:479843]  [HAL][DPDK] Dispatcher statistics abs/delta:
+	                 drop (worker queue full)           |  empty NIC RX |       RX packets
+	Cluster #0:               0/0           0.0%/  0.0% |   98.0%/95.0% |  100500000/100500
+</code>
+здесь ''empty NIC RX'' - это и есть процент холостых опросов rx-очередей карт - абсолютный процент (с начала работы СКАТ) и относительный (дельта с последнего вывода в stat-лог). 100% - значит, входных пакетов нет, диспетчер работает вхолостую. Если относительный процент меньше 10 (то есть в более чем 90% опросов интерфейсов есть входные пакеты) - диспетчер не справляется и надо рассмотреть вариант с другим движком, где большее число диспетчеров.
+Также хорошим индикатором, что текущий движок в целом не справляется, является ненулевое значение дельты для показателя ''drop (worker queue full)''. Это число отброшенных пакетов, которые диспетчер не смог отправить в поток обработки из-за переполнения входной очереди обработчика. Это значит, что обработчики не справляются с обработкой входящего трафика; причины могут быть две:
+  * либо слишком мало потоков-обработчиков, надо увеличить параметр ''num_threads'' или выбрать другой движок (параметр ''dpdk_engine'');
+  * либо трафик сильно перекошен и большинство пакетов попадает в один-два обработчика, тогда как остальные свободны. В этой ситуации нужно анализировать структуру трафика. Можно попробовать увеличить или уменьшить на единицу число потоков-обработчиков, чтобы хеш-функция диспетчера раскидывала пакеты более равномерно (напомним, что номер потока обработки есть ''хеш_пакета mod число_обработчиков'')
+==== dpdk_engine=0: Один диспетчер ====
+В этом режиме работы СКАТ создает один поток диспетчера на кластер.
+Диспетчер читает входящие пакеты со всех ''in_dev'' и ''out_dev'' устройств и раскидывает пакеты по потокам обработчиков.
+Подходит для 10G карт, выдерживает нагрузку до 20G и более (зависит от модели CPU и режима разбора туннелей [[dpi:dpi_components:platform:dpi_inst_spec:dpi_tunnels|check_tunnels]])
+<note tip>Общее число требуемых ядер равно числу обработчиков плюс одно ядро на диспетчер</note>
+СКАТ конфигурирует карты следующим образом:
+  * RX queue count = 1
+  * TX queue count = число потоков обработки. Потоки обработки пишут напрямую каждый в свою TX-очередь карты.
+<note tip>Для read-only режима (без ''out_dev'') число TX queue равно нулю. Некоторые DPDK-драйверы (например, vmxnet3) не позволяют конфигурировать карту с числом TX queue, равным нулю. Для таких драйверов в версии СКАТ 10.2 введен параметр fastdpi.conf ''dpdk_txq_count'': следует задать ''dpdk_txq_count=1''
+</note>
+==== dpdk_engine=1: Диспетчеры по направлению ====
+В этом режиме создается два потока диспетчера: один для направления от абонентов в inet (для ''in_dev''), другой - для направления из inet к абонентам (для ''out_dev'').
+Подходит для нагрузок свыше 20G (карты 25G, 40G).
+<note tip>Общее число требуемых ядер равно числу обработчиков плюс два ядра на диспетчеры</note>
+СКАТ конфигурирует карты следующим образом:
+  * RX queue count = 1
+  * TX queue count = число потоков обработки. Потоки обработки пишут напрямую каждый в свою TX-очередь карты.
+==== dpdk_engine=2: Поддержка RSS ====
+В данном режиме задействуется RSS (receive side scaling) карты.
+Значение RSS задается в fastdpi.conf параметром
+<code>
+dpdk_rss=2
+</code>
+Значение ''dpdk_rss'' не должно быть менее 2.
+Для каждого направления создается ''dpdk_rss'' диспетчеров.
+<note tip>Общее число требуемых ядер равно числу обработчиков плюс ''dpdk_rss * 2'' на диспетчеры</note>
+Подходит для мощных карт 50G+ (то есть для СКАТ-100+). Если у вас 50G набрано из нескольких карт группировкой, данный режим вряд ли подойдет, так как для каждой карты из группы требует дополнительно как минимум 2 ядра (при ''dpdk_rss=2''). Лучше рассмотреть варианты ''dpdk_engine=1'' или ''dpdk_engine=3''.
+СКАТ конфигурирует карты следующим образом:
+  * RX queue count = ''dpdk_rss''
+  * TX queue count = число потоков обработки. Потоки обработки пишут напрямую каждый в свою TX-очередь карты.
+==== dpdk_engine=3: Диспетчер на мост ====
+Для каждого моста создается отдельный поток диспетчера.
+Предназначен для конфигураций со множеством девайсов на входе и выходе:
+<code>
+in_dev=01-00.0:02-00.0:03-00.0
+out_dev=01-00.1:02-00.1:03-00.1
+dpdk_engine=3
+</code>
+Для данного примера создается три потока диспетчеров:
+  * для моста 01-00.0 <--> 01-00.1
+  * для моста 02-00.0 <--> 02-00.1
+  * для моста 03-00.0 <--> 03-00.1
+<note tip>Общее число требуемых ядер равно числу обработчиков плюс число мостов</note>
+Данный движок предназначен для нескольких карт 25G/40G/50G в группе (то есть для СКАТ-100+)
+СКАТ конфигурирует карты следующим образом:
+  * RX queue count = 1
+  * TX queue count = число потоков обработки. Потоки обработки пишут напрямую каждый в свою TX-очередь карты.
+==== dpdk_engine=4: Диспетчер на порт ====
+Для каждого порта (девайса) создается отдельный поток диспетчера.
+Предназначен для конфигураций со множеством девайсов на входе и выходе:
+<code>
+in_dev=01-00.0:02-00.0:03-00.0
+out_dev=01-00.1:02-00.1:03-00.1
+dpdk_engine=4
+</code>
+Для данного примера создается шесть потоков диспетчеров - для каждого девайса по диспетчеру. Очевидно, что если у нас только один мост, данный движок эквивалентен ''dpdk_engine=1'' - один диспетчер на направление.
+<note tip>Общее число требуемых ядер равно числу обработчиков плюс число портов</note>
-Другие настройки относятся к конкретным опциям и находятся в [[dpi:dpi_options:start|соответствующих разделах]].
+Данный движок предназначен для нескольких карт 25G/40G/50G в группе (то есть для СКАТ-100+)
-Примечание:\\
+СКАТ конфигурирует карты следующим образом:
-in_dev и out_dev - холодные параметры\\
+  * RX queue count = 1
-federal_black_list - горячий параметр\\
+  * TX queue count = число потоков обработки. Потоки обработки пишут напрямую каждый в свою TX-очередь карты.
-Подробнее смотрите раздел [[:dpi_admin|администрирование]]