DPDK usage discussions
 help / color / mirror / Atom feed
From: Bin Huang <huangbin.mails@gmail.com>
To: Yongseok Koh <yskoh@mellanox.com>
Cc: "Nélio Laranjeiro" <nelio.laranjeiro@6wind.com>,
	users@dpdk.org, "Adrien Mazarguil" <adrien.mazarguil@6wind.com>
Subject: Re: [dpdk-users] mlx5 driver didn't set corresponding packet_type flag in TCP_ACK packet case
Date: Wed, 28 Mar 2018 10:51:54 +0800	[thread overview]
Message-ID: <CANni5bqyhyj-LEqVy=CR2Jn8Df6jVuc+PRuGBft1x3bifRGdVw@mail.gmail.com> (raw)
In-Reply-To: <20180327211021.GA16677@yongseok-MBP.local>

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

      reply	other threads:[~2018-03-28  2:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-26 10:09 Bin Huang
2018-03-27  7:14 ` Nélio Laranjeiro
2018-03-27 21:12   ` Yongseok Koh
2018-03-28  2:51     ` Bin Huang [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANni5bqyhyj-LEqVy=CR2Jn8Df6jVuc+PRuGBft1x3bifRGdVw@mail.gmail.com' \
    --to=huangbin.mails@gmail.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=nelio.laranjeiro@6wind.com \
    --cc=users@dpdk.org \
    --cc=yskoh@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).