c++ - Mellanox 上的 DPDK IPv4 流过滤

Question

我有一个 DPDK 应用程序，它使用 Boost asio 加入多播组，并在特定 UDP 端口号上通过 VLAN 接收多播 IPv4 UDP 数据包(其他 UDP 端口也用于其他流量)。我试图仅在 DPDK 应用程序的那个端口接收那些多播 UDP 数据包，并将它们放入 RX 队列，并让所有其他入口网络流量表现得好像 DPDK 应用程序没有运行(转到内核)。因此，我使用流隔离模式 (rte_flow_isolate())。我的应用程序的流过滤部分基于 DPDK 提供的 flow_filtering 示例，添加了对 rte_flow_isolate() 的调用和 VLAN 过滤器。我使用的过滤器如下:

action[0].type = RTE_FLOW_ACTION_TYPE_QUEUE;
action[0].conf = &queue;
action[1].type = RTE_FLOW_ACTION_TYPE_END;

pattern[0].type = RTE_FLOW_ITEM_TYPE_ETH;
pattern[1].type = RTE_FLOW_ITEM_TYPE_VLAN;
//vlan id here
pattern[2].type = RTE_FLOW_ITEM_TYPE_IPV4;
//no specific ip address given
pattern[3].type = RTE_FLOW_ITEM_TYPE_UDP;
//udp port here
pattern[4].type = RTE_FLOW_ITEM_TYPE_END;

使用这些过滤器，我无法接收任何数据包，如果我只删除 UDP 过滤器，情况也是如此。但是，如果我同时删除 IPV4 和 UDP 过滤器(保留 ETH 和 VLAN 过滤器)，我可以接收所有我需要的数据包，以及其他我不想要的数据包(并希望发送到内核)。

这是我需要从 Wireshark 捕获中接收的数据包的条目。目前我的理论是，因为在 IPv4 header 中设置了保留位(邪恶位)，所以数据包未被识别为 IPv4。这可能是一个延伸:

Frame 100: 546 bytes on wire (4368 bits), 546 bytes captured (4368 bits) on interface 0

Ethernet II, Src: (src MAC), Dst: IPv4mcast_...
802.1Q Virtual LAN, PRI: 0, FRI: 0, ID: 112
Internet Protocol Version 4, Src: (src IP), Dst: (Dst mcast IP)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
    Total length: 1108
    Identification: 0x000 (0)
    Flags: 0x04 (RESERVED BIT HAS BEEN SET)
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0xd8c4 [validation disabled]
    Source: srcip
    Destination: dstip
User Datagram Protocol, Src Port: (src port), Dst Port: (dst port)
Data (N bytes)

我正在运行的硬件有一个 Mellanox ConnectX-5 卡，因此，DPDK 使用的是 MLX5 驱动程序，它不支持 RTE_FLOW_ITEM_TYPE_RAW 以及 RTE Flow API 中的许多其他项目。我在 DPDK 19.11 上，我使用的 OFED 版本是 4.6 for RHEL 7.6 (x86_64)

我在这里做错了什么，为什么添加 RTE_FLOW_ITEM_TYPE_IPV4 过滤器(没有 ip 地址、规范和掩码 memset 为 0)导致我的应用程序收不到任何数据包，即使它们是 IPv4 数据包？有没有办法使用 DPDK 的 MLX5 驱动程序解决这个问题？

Answer 1

答案很简单:数据包是碎片化的。无法匹配的原因有两个:

1. UDP header 仅出现在第一个 IP 片段中，

2. 所以从 NIC 的角度来看，分片的 UDP 只是一个 IP 数据包。

尝试匹配非分片数据包进行确认。