与XDP_DROP/重定向相比，XDP_TX的低吞吐量

Question

我开发了一个XDP程序，它根据某些特定的规则过滤数据包，然后删除它们(XDP_DROP)或将它们(xdp_redirect_map)重定向到另一个接口。这个程序能够在四个CPU核心上处理大约11 11Mpps的综合负载(这是我的流量生成器所能做到的)。

现在，我已经更改了程序，使用XDP_TX将数据包发送到接收到的接口上，而不是将它们重定向到另一个接口。不幸的是，这个简单的更改导致了吞吐量的大幅度下降，现在它很难处理~4 4Mpps。

我不明白，这是什么原因，或者如何进一步调试，这就是我在这里问的原因。

我的最小测试设置来重现问题：

• 两台具有英特尔x520 SFP+ NIC直接连接的机器，这两台NIC被配置成具有与机器具有CPU核一样多的“组合”queus。
• Machine 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个内核)
• Machine2运行一个简单程序，它删除(或反射)所有数据包并对pps进行计数。在该程序中，我将XDP_DROP返回代码替换为XDP_TX。-在反映数据包之前，我是否交换src/dest mac地址并不会导致吞吐量上的差异，所以我把它放在这里。

在使用XDP_DROP运行程序时，Machine2上的4个内核在放置约11 are时会稍微加载ksoftirqd线程。只加载4个内核是有意义的，因为pktgen发送了4个不同的数据包，因为NIC中的散列是如何工作的，因此只填充了4个rx队列。

但是，当使用XDP_TX运行程序时，其中一个核心是~100%忙于ksoftirqd，并且只处理~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作为包生成器，并且用10‘ve和100个不同的数据包(流)淹没了Machine2。现在，当以最小的CPU负载丢弃所有这些数据包时，通信量在内核之间分布得更好。但是，在处理~3Mpps时，XDP_TX仍然无法跟上并将单个内核加载到100%。

Answer 1

我现在已经将机器2的内核升级到5.12.0-rc3，这个问题就消失了。看起来这是个内核问题。

如果有人对此了解更多，或对此有改变，请告诉我。