我开发了一个XDP程序，该程序根据一些特定规则过滤数据包，然后将其丢弃(XDP_DROP(或重定向(xdp_redirect_map(到另一个接口。这个程序能够很好地在四个CPU核心上处理大约11Mpps的合成负载(这就是我的流量生成器的全部能力(。
现在，我已经将该程序更改为使用XDP_TX在接收数据包的接口上发送数据包，而不是将它们重定向到另一个接口。不幸的是，这个简单的更改导致吞吐量大幅下降，现在它几乎无法处理约4Mpps。
我不明白，这可能是什么原因，或者如何进一步调试，这就是我在这里问的原因。
我复制问题的最小测试设置：
- 两台具有Intel x520 SFP+NIC的机器直接相互连接，两个NIC都配置为具有相同数量的"；组合的"；因为机器有CPU核心
-
机器1使用linux源代码中的示例应用程序运行pktgen：
./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运行一个简单的程序，该程序删除(或反映(所有数据包并对pps进行计数。在那个程序中，我用
XDP_TX替换了XDP_DROP返回代码在反映数据包之前是否交换src/dest mac地址从来没有导致吞吐量的差异，所以我在这里省略了这一点
当使用XDP_DROP运行程序时，机器2上的4个内核略微加载了ksoftirqd线程，同时下降了约11Mps。由于NIC中的哈希工作方式，pktgen发送了4个不同的数据包，这些数据包只填充了4个rx队列，因此只加载了4个内核是有道理的。
但是，当使用XDP_TX运行程序时，其中一个核心在使用ksoftirqd时约100%繁忙，并且仅处理约4Mpp。在这里，我不确定为什么会发生这种情况。
你知道是什么原因导致吞吐量下降和CPU使用率增加吗？
编辑：下面是关于机器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作为数据包生成器，并用10Mpps和100种不同的数据包变体(流(淹没了Machine 2。现在，当以最小的CPU负载丢弃所有这些数据包时，流量在内核之间的分布会更好。但XDP_TX仍然无法跟上，在处理~3pps时将单个内核加载到100%。
我现在已经将Machine 2的内核升级到5.12.0-rc3，问题消失了。看起来这是一个内核问题。
如果有人对此了解更多，或者对此有更改日志，请告诉我。