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

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

[Bin Huang]

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

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

[Nélio Laranjeiro]

Hi Bin,

On Mon, Mar 26, 2018 at 06:09:35PM +0800, Bin Huang wrote:
> 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?

According to the mlx5_set_ptype_table(), the index of the array is a
little more complex:

 /*
  * The index to the array should have:
  * bit[1:0] = l3_hdr_type
  * bit[4:2] = l4_hdr_type
  * bit[5] = ip_frag
  * bit[6] = tunneled
  * bit[7] = outer_l3_type
  */

If in the CQE the other three fields are 0, your hypothesis is correct
and index 0x12 should be filled.

Can you also check it?

> Thanks for your time,
> 
> Bin

Thanks,

-- 
Nélio Laranjeiro
6WIND

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

[Yongseok Koh]

On Tue, Mar 27, 2018 at 09:14:34AM +0200, Nélio Laranjeiro wrote:
> Hi Bin,
> 
> On Mon, Mar 26, 2018 at 06:09:35PM +0800, Bin Huang wrote:
> > 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?
> 
> According to the mlx5_set_ptype_table(), the index of the array is a
> little more complex:
> 
>  /*
>   * The index to the array should have:
>   * bit[1:0] = l3_hdr_type
>   * bit[4:2] = l4_hdr_type
>   * bit[5] = ip_frag
>   * bit[6] = tunneled
>   * bit[7] = outer_l3_type
>   */
> 
> If in the CQE the other three fields are 0, your hypothesis is correct
> and index 0x12 should be filled.
> 
> Can you also check it?

When I changed it to the current array-based conversion, I followed the use of 
MLX5_CQE_RX_TCP_PACKET [1], but it looks Bin is right. A packet should be
identified as TCP packet if l4_hdr_type is 1, 3 or 4.

Bin, will you send out a patch for it or shall I?
I'd love to see a patch from you. :-)


[1] http://dpdk.org/browse/dpdk/commit/?id=ea16068c00647fb6c7fe8704d8ad2adff6bf378f

Thanks,
Yongseok

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

[Bin Huang]

Hi Nélio, Yongseok,


On Wed, Mar 28, 2018 at 5:12 AM, Yongseok Koh <yskoh@mellanox.com> wrote:
> On Tue, Mar 27, 2018 at 09:14:34AM +0200, Nélio Laranjeiro wrote:
>> Hi Bin,
>>
>> On Mon, Mar 26, 2018 at 06:09:35PM +0800, Bin Huang wrote:
>> > 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?
>>
>> According to the mlx5_set_ptype_table(), the index of the array is a
>> little more complex:
>>
>>  /*
>>   * The index to the array should have:
>>   * bit[1:0] = l3_hdr_type
>>   * bit[4:2] = l4_hdr_type
>>   * bit[5] = ip_frag
>>   * bit[6] = tunneled
>>   * bit[7] = outer_l3_type
>>   */
>>
>> If in the CQE the other three fields are 0, your hypothesis is correct
>> and index 0x12 should be filled.
>>
>> Can you also check it?

I have checked other three bit fields from CQE:
bit[5] = ip_frag
bit[6] = tunneled
bit[7] = outer_l3_type
 they are all 0 as I use non-tunneled packet.

>
> When I changed it to the current array-based conversion, I followed the use of
> MLX5_CQE_RX_TCP_PACKET [1], but it looks Bin is right. A packet should be
> identified as TCP packet if l4_hdr_type is 1, 3 or 4.
>
> Bin, will you send out a patch for it or shall I?
> I'd love to see a patch from you. :-)
>

Sure, I will send out a patch for review.

>
> [1] http://dpdk.org/browse/dpdk/commit/?id=ea16068c00647fb6c7fe8704d8ad2adff6bf378f
>
> Thanks,
> Yongseok

Thanks,
Bin