DPDK应用如何为ETH_RSS_VXLAN/ETH_RSS_GENEVE启用RSS实现按VNI分发VXLAN流量

硬件支持原生隧道RSS时的哈希参数构成 #

如果网卡硬件原生支持ETH_RSS_VXLAN、ETH_RSS_GENEVE这类隧道RSS卸载能力，硬件RSS哈希引擎的输入参数会完全围绕隧道业务标识设计，从机制上避开外层封装头对分发结果的干扰：

• 启用ETH_RSS_VXLAN时，硬件抓取的哈希计算输入为：VXLAN头里24位VNI、内层报文的源IP、目的IP、内层TCP/UDP源端口、目的端口。计算过程完全不会把外层IP、外层UDP端口算进哈希输入，刚好匹配按VNI而非外层信息分发流量的需求。
• 启用ETH_RSS_GENEVE时，逻辑和VXLAN一致，硬件会提取GENEVE头里的24位VNI、内层五元组作为哈希输入，完全忽略外层封装的所有字段。

当前环境下的能力边界与实际效果 #

结合你给出的DPDK版本、网卡固件版本、测试配置现状，实际可实现的RSS效果和原生隧道RSS的设计目标有明显差距：

• 能力上报层面：ConnectX-5搭配16.30.1004固件、DPDK20.11.1版本时，mlx5驱动不会向上层上报ETH_RSS_VXLAN、ETH_RSS_GENEVE对应的卸载能力位。哪怕把这些位写到RSS哈希的字段掩码里，驱动也会直接丢弃，根本不会给硬件下发对应的提取规则。
• 现有测试配置的实际行为：你之前在l3fwd里测的各类基于内层IP字段的RSS配置，硬件层面的实际逻辑是：mlx5驱动识别到流量是VXLAN隧道报文后，自动跳过外层封装头的字段，直接抓内层IP、端口字段算RSS哈希——整个过程完全不会把VNI当哈希输入。也就是说现在的配置效果是按内层五元组分发流量，既不参考外层的IP和端口，也识别不了VNI维度，根本达不到纯按VNI分发的目标。
• 无RTE_FLOW的限制：因为现在用的是l3fwd自带的RSS配置逻辑，没有通过RTE_FLOW下发自定义规则，ConnectX-5的硬件RSS哈希引擎默认支持的提取字段集合里，本身就不包含VXLAN头里VNI所在的偏移位置，没有办法纯靠RSS参数把VNI加进哈希计算。

注意：要在当前硬件上实现纯按VNI的流量分发，必须借助RTE_FLOW接口配置带action_rss的流规则，明确匹配对应隧道端口、并指定哈希输入包含VNI字段，靠l3fwd原生的RSS参数配置是实现不了的。

内容的提问来源于stack exchange，提问作者Ameer Usman