No DPDK packet fragmentation supported in Mellanox ConnectX-3?

Question

Hello Stackoverflow Experts,

I am using DPDK on Mellanox NIC, but am struggling with applying the packet fragmentation in DPDK application.

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

the dpdk application(l3fwd, ip-fragmentation, ip-assemble) did not recognized the received packet as the ipv4 header.

At first, I have crafted my own packets when sending ipv4 headers so I assumed that I was crafting the packets in a wrong way.

So I have used DPDK-pktgen but dpdk-application (l3fwd, ip-fragmentation, ip-assemble) did not recognized the ipv4 header. As the last resort, I have tested the dpdk-testpmd, and found out this in the status info.

********************* 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

According to DPDK documentation. in the flow type of the info status of port 1 should show, but mine shows that no flow type is supported. The below example should be the one that needs to be displayed in flow types:

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

So Is my NIC, Mellanox Connect X-3 does not support DPDK IP fragmentation? Or is there additional configuration that needs to be done before trying out the packet fragmentation?

-- [EDIT] So I have checked the packets from DPDK-PKTGEN and the packets received by DPDK application. The packets that I receive is the exact one that I have sent from the application. (I get the correct data)

The problem begins at the code

struct rte_mbuf *pkt
RTE_ETH_IS_IPV4_HDR(pkt->packet_type) 

This determines the whether the packet is ipv4 or not. and the value of pkt->packet_type is both zero from DPDK-PKTGEN and DPDK application. and if the pkt-packet_type is zero then the DPDK application reviews this packet as NOT IPV4 header.

This basic type checker is wrong from the start. So what I believe is that either the DPDK sample is wrong or the NIC cannot support ipv4 for some reason.

The data I received have some pattern at the beginning I receive the correct message but after that sequence of packets have different data between the MAC address and the data offset

So what I assume is they are interpreting the data differently, and getting the wrong result.

Answer 1

I am pretty sure any NIC, including Mellanox ConnectX-3 MUST support ip fragments.

The flow type you are referring is for the Flow Director, i.e. mapping specific flows to specific RX queues. Even if your NIC does not support flow director, it does not matter for the IP fragmentation.

I guess there is an error in the setup or in the app. You wrote:

the dpdk application did not recognized the received packet as the ipv4 header.

I would look into this more closely. Try to dump those packets with dpdk-pdump or even by simply dumping the receiving packet on the console with rte_pktmbuf_dump()

If you still suspect the NIC, the best option would be to temporary substitute it with another brand or a virtual device. Just to confirm it is the NIC indeed.

EDIT:

Have a look at mlx4_ptype_table for fragmented IPv4 packets it should return packet_type set to RTE_PTYPE_L2_ETHER | RTE_PTYPE_L3_IPV4_EXT_UNKNOWN | RTE_PTYPE_L4_FRAG

Please note the functionality was added in DPDK 17.11.

I suggest you to dump pkt->packet_type on console to make sure it is zero indeed. Also make sure you have the latest libmlx4 installed.