Mellanox ConnectX-3中不支持DPDK数据包碎片？

各位专家好,

我正在Mellanox NIC上使用DPDK，但正在努力应用数据包 DPDK应用程序中的碎片

sungho@c3n24:~$ lspci | grep Mellanox
81:00.0 Ethernet controller: Mellanox Technologies MT27500 Family
[ConnectX-3]

dpdk应用程序（l3fwd、ip碎片、ip组装）未启动 将接收到的数据包识别为ipv4标头

首先，我在发送ipv4报头时编制了自己的数据包，因此 假设我以错误的方式制作数据包

所以我使用了DPDK pktgen，但使用了DPDK应用程序（l3fwd、ip碎片、， ip（汇编）未识别ipv4标头。 作为最后的手段，我已经测试了dpdk testpmd，并在中发现了这一点 状态信息

********************* Infos for port 1 *********************
MAC address: E4:1D:2D:D9:CB:81
Driver name: net_mlx4
Connect to socket: 1
memory allocation on the socket: 1
Link status: up
Link speed: 10000 Mbps
Link duplex: full-duplex
MTU: 1500
Promiscuous mode: enabled
Allmulticast mode: disabled
Maximum number of MAC addresses: 127
Maximum number of MAC addresses of hash filtering: 0
VLAN offload:
strip on
filter on
qinq(extend) off
No flow type is supported.
Max possible RX queues: 65408
Max possible number of RXDs per queue: 65535
Min possible number of RXDs per queue: 0
RXDs number alignment: 1
Max possible TX queues: 65408
Max possible number of TXDs per queue: 65535
Min possible number of TXDs per queue: 0
TXDs number alignment: 1
testpmd> show port

根据DPDK文件。 在信息流类型中，端口1的状态应显示，但我的显示 不支持任何流类型。 以下示例应为需要以流类型显示的示例：

Supported flow types:
ipv4-frag
ipv4-tcp
ipv4-udp
ipv4-sctp
ipv4-other
ipv6-frag
ipv6-tcp
ipv6-udp
ipv6-sctp
ipv6-other
l2_payload
port
vxlan
geneve
nvgre

我的NIC也是如此，Mellanox Connect X-3不支持DPDK IP碎片？或者是 在尝试数据包碎片之前，还需要进行其他配置吗

--[编辑] 所以我检查了来自DPDK-PKTGEN的数据包和DPDK应用程序接收到的数据包。 我收到的数据包正是我从应用程序发送的数据包。（我得到了正确的数据）

问题从代码开始

struct rte_mbuf *pkt
RTE_ETH_IS_IPV4_HDR(pkt->packet_type) 

这将确定数据包是否为ipv4。 DPDK-PKTGEN和DPDK应用程序的pkt->packet_type的值均为零。如果pkt-packet_类型为零，则DPDK应用程序将此数据包视为非IPV4报头

此基本类型检查器从一开始就是错误的。 因此，我认为DPDK样本是错误的，或者NIC由于某种原因无法支持ipv4

我收到的数据在开始时有一些模式，我收到了正确的消息，但在那之后，数据包序列在MAC地址和数据偏移量之间有不同的数据

---

因此，我假设他们以不同的方式解释数据，并得到错误的结果

我非常确定任何NIC，包括Mellanox ConnectX-3都必须支持ip碎片

您所指的流类型适用于流控制器，即将特定流映射到特定RX队列。即使您的NIC不支持flow director，IP碎片也无关紧要

我猜安装或应用程序中有错误。你写道：

dpdk应用程序未将收到的数据包识别为ipv4标头

我会更仔细地研究这个问题。尝试使用

dpdk pdump

转储这些数据包，甚至只需在控制台上使用

rte_pktmbuf_dump（）

如果您仍然怀疑NIC，最好的选择是用其他品牌或虚拟设备临时替换它。只是为了确认它确实是NIC

编辑：

查看

mlx4_ptype_表

对于分段的IPv4数据包，它应该返回

packet_type

设置为

RTE_ptype_L2_ETHER | RTE_ptype_L3_IPv4_EXT_UNKNOWN | RTE_ptype_L4_FRAG

请注意，该功能是在DPDK 17.11中添加的

---

我建议您在控制台上转储

pkt->packet\u type

，以确保它确实为零。还要确保安装了最新的

libmlx4

。

谢谢您的回复，但问题是我尝试了rte_pktmbuf_dump（），但我不知道正确的数据包是什么，因为我没有任何有效的示例。我曾尝试使用testpmd进行测试，但根本没有ipv4数据包发送选项（只有mac地址），因此我无法知道ipv4头应该如何正确编制。是的，我认为testpmd无法生成ipv4数据包，只有DPDK pktgen可以。正如你所说，我唯一的选择就是查看数据包，但最大的问题是我不知道正确的格式是什么。我将再次检查pktgen，找出ipv4数据包的完整版本，然后尝试制作类似的版本。那么您如何知道“dpdk应用程序没有将收到的数据包识别为ipv4报头？”“？可能它是无效的MAC，您只需要修复它或将NIC置于混杂模式？不，我肯定有正确的MAC地址。对于这一部分，我非常确定，并且我可以发送和接收消息，我正在比较从PKTGEN和DPDK应用程序发送的数据包。正如您所预测的，可能会有所不同。”在l2报头和数据偏移量之间（我假设它是l3报头）@SunghoHong您认为

pkt->packet\u type

是否为零还是检查了它？转储上的数据包肯定是IPv4数据包。所以看起来数据包类型信息在某处丢失了。请查看我的更新答案。