[dpdk-users] mlx5 driver didn't set corresponding packet_type flag in TCP_ACK packet case

[Bin Huang <huangbin.mails@gmail.com>]

Greetings all,


I have run l3fwd example program using two mlx5 NIC(
MLNX_OFED_LINUX-4.3-1.0.1.0 ) base on DPDK 17.08 and use pktgen as
flowgen.

This demo provided by DPDK works fine in UDP case, but in pktgen TCP
case, l3fwd can't forward packet to nexthop port.


After look into function rxq_cq_to_pkt_type(), I found while handling
IPv4 TCP ACK packets:

> l4_hdr_type bits[2:0] in CQE is (100)

> l3_hdr_type bits[1:0] in CQE is (10)


It looks fine according to CQE format in
<Ethernet_Adapters_Programming_Manual> doc:

> l4_hdr_type:
    0 - None
    1 - TCP header was present in the packet
    2 - UDP header was present in the packet
    3 - TCP header was present in the packet with Empty TCP ACK
indication. (TCP packet <ACK> flag is set, and packet carries no data)
    4 - TCP header was present in the packet with TCP ACK indication.
(TCP packet <ACK> flag is set, and packet carries data).

> l3_hdr_type:

    00 - None
    01 - IPv6
    10 - IPv4


But combined l4_hdr_type and l3_hdr_type into idx, the idx would be
0x12, which was not reserved in mlx5_set_ptype_type().

Then RTE_PTYPE_UNKNOWN would be return to caller which caused
sub-sequence procedure going wrong.


Did I omit any possible configuration to make ptype flag work for TCP
ACK packets, or should I add (*p)[0x12] in mlx5_set_ptype_type() to
make this work?



Thanks for your time,

Bin