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

Question

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

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

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

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

两个 machine 与 Intel x520 SFP+ NIC 直接相互连接，两个 NIC 配置为具有与 machine 具有 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，即使 machine 有超过 4 个内核）
机器 2 运行 simple program 丢弃（或反射）所有数据包并计算 pps。在那个程序中，我用 XDP_TX 替换了 XDP_DROP return 代码。 - 我是否在反映数据包之前交换 src/dest mac 地址不会导致吞吐量差异，所以我将其留在这里。

当运行具有 XDP_DROP 的程序时， 机器 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，问题消失了。看起来这是一个内核问题。

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

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

Low throughput with XDP_TX in comparison with XDP_DROP/REDIRECT

linux-kernel

ebpf

xdp-bpf