linux-kernel - 与 XDP_DROP/REDIRECT 相比，XDP_TX 的吞吐量较低

Question

我开发了一个 XDP 程序，它根据一些特定规则过滤数据包，然后丢弃它们 (XDP_DROP) 或将它们重定向 (xdp_redirect_map) 到另一个接口(interface)。该程序仅在四个 CPU 内核上就能够很好地处理约 11Mpps 的合成负载(这就是我的流量生成器的全部能力)。

现在我将该程序更改为使用 XDP_TX 在接收数据包的接口(interface)上发送数据包，而不是将它们重定向到另一个接口(interface)。不幸的是，这个简单的更改导致了吞吐量的大幅下降，现在它几乎无法处理 ~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 运行 simple program丢弃(或反射)所有数据包并计算 pps。在那个程序中，我用 XDP_TX 替换了 XDP_DROP 返回代码。 - 我是否在反射(reflect)数据包之前交换 src/dest mac 地址不会导致吞吐量差异，所以我将其留在这里。

当使用 XDP_DROP 运行程序时，Machine 2 上的 4 个核心略微加载了 ksoftirqd 线程，同时下降了大约 11Mps。考虑到 pktgen 发出 4 个不同的数据包，由于 NIC 中的散列的工作方式，这些数据包仅填充 4 个 rx 队列，因此仅加载 4 个内核是有道理的。

但是当使用 XDP_TX 运行程序时，其中一个内核约 100% 忙于 ksoftirqd，并且仅处理了约 4Mpps。我不确定为什么会这样。

您是否知道可能导致这种吞吐量下降和 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 种不同的数据包变体(流)淹没机器 2。现在，当以最小的 CPU 负载丢弃所有这些数据包时，流量可以更好地分布在内核之间。但是 XDP_TX 仍然跟不上，在处理 ~3Mpps 时将单个内核加载到 100%。

Answer 1

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

如果有人对此有更多了解或有关于此的变更日志，请告诉我。