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
next prev parent 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).