Низкая пропускная способность с XDP_TX по сравнению с XDP_DROP/REDIRECT

Я разработал программу XDP, которая фильтрует пакеты на основе определенных правил, а затем либо отбрасывает их (XDP_DROP), либо перенаправляет (xdp_redirect_map) на другой интерфейс. Эта программа вполне справлялась с синтетической нагрузкой ~11Mpps (это все, на что способен мой генератор трафика) всего на четырех ядрах процессора.

Теперь я изменил эту программу, чтобы использовать XDP_TX для отправки пакетов на интерфейс, на котором они были получены, вместо перенаправления их на другой интерфейс. К сожалению, это простое изменение привело к значительному падению пропускной способности, и теперь он с трудом справляется с ~4Mpps.

Я не понимаю, в чем может быть причина или как это дальше отлаживать, поэтому и спрашиваю здесь.

Моя минимальная тестовая установка для воспроизведения проблемы:

• Два компьютера с сетевыми адаптерами Intel x520 SFP+ напрямую подключены друг к другу, оба сетевых адаптера настроены на наличие столько объединенных очередей, сколько ядер ЦП на компьютере.
• Машина 1 запускает pktgen с использованием примера приложения из исходников Linux: ./pktgen_sample05_flow_per_thread.sh -i ens3 -s 64 -d 1.2.3.4 -t 4 -c 0 -v -m MACHINE2_MAC (4 потока, потому что эта конфигурация привела к максимальному количеству генерируемых Mpps, даже несмотря на то, что машина имеет более 4 ядер)
• Компьютер 2 запускает простой программа, которая отбрасывает (или отражает) все пакеты и подсчитывает количество пакетов в секунду. В этой программе я заменил код возврата XDP_DROP на XDP_TX. - Если я поменяю местами MAC-адреса src/dest перед отражением пакета, это никогда не повлияет на пропускную способность, поэтому я не буду об этом говорить.

При запуске программы с XDP_DROP 4 ядра на Machine 2 слегка загружены ksoftirqd потоками, при этом скорость снижается примерно на ~11 Мбит/с. То, что загружаются только 4 ядра, имеет смысл, учитывая, что pktgen отправляет 4 разных пакета, которые заполняют только 4 очереди rx из-за того, как работает хеширование в сетевой карте.

Но при запуске программы с XDP_TX одно из ядер занято ~100% с ksoftirqd и обрабатывается только ~4Mpps. Здесь я не уверен, почему это происходит.

У вас есть идея, что может быть причиной этого падения пропускной способности и увеличения использования ЦП?

Редактировать: вот еще некоторые подробности о конфигурации машины 2:

# ethtool -g ens2f0
Ring parameters for ens2f0:
Pre-set maximums:
RX:             4096
RX Mini:        n/a
RX Jumbo:       n/a
TX:             4096
Current hardware settings:
RX:             512   # changing rx/tx to 4096 didn't help
RX Mini:        n/a
RX Jumbo:       n/a
TX:             512

# ethtool -l ens2f0
Channel parameters for ens2f0:
Pre-set maximums:
RX:             n/a
TX:             n/a
Other:          1
Combined:       63
Current hardware settings:
RX:             n/a
TX:             n/a
Other:          1
Combined:       32

# ethtool -x ens2f0
RX flow hash indirection table for ens2f0 with 32 RX ring(s):
    0:      0     1     2     3     4     5     6     7
    8:      8     9    10    11    12    13    14    15
   16:      0     1     2     3     4     5     6     7
   24:      8     9    10    11    12    13    14    15
   32:      0     1     2     3     4     5     6     7
   40:      8     9    10    11    12    13    14    15
   48:      0     1     2     3     4     5     6     7
   56:      8     9    10    11    12    13    14    15
   64:      0     1     2     3     4     5     6     7
   72:      8     9    10    11    12    13    14    15
   80:      0     1     2     3     4     5     6     7
   88:      8     9    10    11    12    13    14    15
   96:      0     1     2     3     4     5     6     7
  104:      8     9    10    11    12    13    14    15
  112:      0     1     2     3     4     5     6     7
  120:      8     9    10    11    12    13    14    15
RSS hash key:
d7:81:b1:8c:68:05:a9:eb:f4:24:86:f6:28:14:7e:f5:49:4e:29:ce:c7:2e:47:a0:08:f1:e9:31:b3:e5:45:a6:c1:30:52:37:e9:98:2d:c1
RSS hash function:
    toeplitz: on
    xor: off
    crc32: off

# uname -a
Linux test-2 5.8.0-44-generic #50-Ubuntu SMP Tue Feb 9 06:29:41 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Редактировать 2: я также попробовал MoonGen в качестве генератора пакетов и заполнил машину 2 10Mpps и 100 различными вариантами пакетов (потоками). Теперь трафик лучше распределяется между ядрами при отбрасывании всех этих пакетов с минимальной нагрузкой на процессор. Но XDP_TX по-прежнему не справляется и загружает одно ядро ​​на 100% при обработке ~3Mpps.