patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Harold Huang <baymaxhuang@gmail.com>
To: Ophir Munk <ophirmu@nvidia.com>
Cc: "stable@dpdk.org" <stable@dpdk.org>,
	Keith Wiles <keith.wiles@intel.com>,
	 Raslan Darawsheh <rasland@nvidia.com>,
	"jiayu.hu@intel.com" <jiayu.hu@intel.com>,
	 Ferruh Yigit <ferruh.yigit@intel.com>
Subject: Re: [PATCH] net/tap: do not include l2 header in gso size when compared with mtu
Date: Mon, 21 Mar 2022 10:52:18 +0800	[thread overview]
Message-ID: <CAHJXk3abnJXwR7A6mZMG73oy-UxCOZ0+28GxWKiOzfdNnhxHyg@mail.gmail.com> (raw)
In-Reply-To: <CO6PR12MB5490CF4359B61BEB79E521D8DC139@CO6PR12MB5490.namprd12.prod.outlook.com>

Hello,

On Fri, Mar 18, 2022 at 5:22 PM Ophir Munk <ophirmu@nvidia.com> wrote:
>
> The effective limit in Tx is the maximum packet size and not the MTU.
> On my Ethernet NIC the MTU size is 1500 bytes. As long as I send packets
> up to 1514 bytes size (including an Ethernet header of 14 bytes) - TX succeeds.
> Conversely, if I add to the packet VLAN, Q-in-Q, VXLAX or any other L2 headers - TX fails

How did you test the largest packet with vlan tag? IMO, vlan is a l2
header which is not included in MTU.  And in my testbed, if I add a
vlan tag in a Ethernet NIC with  mtu 1500, the largest frame is
1518(1514+4), the tcpdump result  is showed as followed:

10:43:08.847060 6c:92:bf:84:b4:7f > 6c:92:bf:89:9f:77, ethertype
802.1Q (0x8100), length 1518: vlan 8, p 0, ethertype IPv4, (tos 0x0,
ttl 64, id 47606, offset 0, flags [none], proto TCP (6), length 1500)
    172.16.2.2.43754 > 172.16.2.3.5201: Flags [.], cksum 0x61f4
(incorrect -> 0x8ffb), seq 412040:413488, ack 1, win 229, options
[nop,nop,TS val 1557628892 ecr 2075223301], length 1448
10:43:08.847061 6c:92:bf:84:b4:7f > 6c:92:bf:89:9f:77, ethertype
802.1Q (0x8100), length 1518: vlan 8, p 0, ethertype IPv4, (tos 0x0,
ttl 64, id 47607, offset 0, flags [none], proto TCP (6), length 1500)
    172.16.2.2.43754 > 172.16.2.3.5201: Flags [.], cksum 0x61f4
(incorrect -> 0x69cf), seq 413488:414936, ack 1, win 229, options
[nop,nop,TS val 1557628892 ecr 2075223301], length 1448

Furthermore, in the tap driver, I see gso_types is set as
RTE_ETH_TX_OFFLOAD_TCP_TSO, ie. VXLAN is not supported. As a result. I
think gso_size could not consider VXLAN Packet here.

> This is because the NIC's maximum packet size is 1514 bytes, regardless of the L2 header size.
> (Remark: NIC max size may include 4 bytes CRC as well).
> Having said that - I suggest setting up an MTU TAP that considers the maximum supported packet size.
> Using mbuf_in-> l2_len in calculating the tso_segsz limit - does not seem right to me.
>
> > -----Original Message-----
> > From: Harold Huang <baymaxhuang@gmail.com>
> > Sent: Tuesday, March 8, 2022 4:35 PM
> > To: dev@dpdk.org
> > Cc: Ophir Munk <ophirmu@nvidia.com>; stable@dpdk.org; Keith Wiles
> > <keith.wiles@intel.com>; Raslan Darawsheh <rasland@nvidia.com>;
> > jiayu.hu@intel.com
> > Subject: Re: [PATCH] net/tap: do not include l2 header in gso size when
> > compared with mtu
> >
> > On Mon, Feb 28, 2022 at 4:27 PM Harold Huang <baymaxhuang@gmail.com>
> > wrote:
> > >
> > > The gso size is calculated with all of the headers and payload. As a
> > > result, the l2 header should not be included when comparing gso size
> > > with mtu.
> > >
> > > Fixes: 050316a88313 ("net/tap: support TSO (TCP Segment Offload)")
> > > Cc: stable@dpdk.org
> > > Signed-off-by: Harold Huang <baymaxhuang@gmail.com>
> > > ---
> > >  drivers/net/tap/rte_eth_tap.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/tap/rte_eth_tap.c
> > > b/drivers/net/tap/rte_eth_tap.c index f1b48cae82..2b561d232c 100644
> > > --- a/drivers/net/tap/rte_eth_tap.c
> > > +++ b/drivers/net/tap/rte_eth_tap.c
> > > @@ -731,7 +731,7 @@ pmd_tx_burst(void *queue, struct rte_mbuf
> > **bufs, uint16_t nb_pkts)
> > >                                         mbuf_in->l4_len;
> > >                         tso_segsz = mbuf_in->tso_segsz + hdrs_len;
> > >                         if (unlikely(tso_segsz == hdrs_len) ||
> > > -                               tso_segsz > *txq->mtu) {
> > > +                               tso_segsz > *txq->mtu +
> > > + mbuf_in->l2_len) {
> > >                                 txq->stats.errs++;
> > >                                 break;
> > >                         }
> > > --
> > > 2.27.0
> > >
> >
> > Hi, Jiayu,
> >
> > This is the only example in the driver to use GSO. I think it is important for us
> > to calculate a correct GSO size. I see you are the GSO lib maintainer, could
> > you please help review this patch?

Thanks
Harold

  reply	other threads:[~2022-03-21  2:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28  8:27 Harold Huang
2022-03-04 16:30 ` Ferruh Yigit
2022-03-08 14:35 ` Harold Huang
2022-03-18  9:22   ` Ophir Munk
2022-03-21  2:52     ` Harold Huang [this message]
2022-05-20 22:08   ` Ferruh Yigit
2022-05-24 14:01     ` Ophir Munk
2023-10-17 16:47   ` Stephen Hemminger

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=CAHJXk3abnJXwR7A6mZMG73oy-UxCOZ0+28GxWKiOzfdNnhxHyg@mail.gmail.com \
    --to=baymaxhuang@gmail.com \
    --cc=ferruh.yigit@intel.com \
    --cc=jiayu.hu@intel.com \
    --cc=keith.wiles@intel.com \
    --cc=ophirmu@nvidia.com \
    --cc=rasland@nvidia.com \
    --cc=stable@dpdk.org \
    /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).