From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 305FFA04FD for ; Mon, 21 Mar 2022 03:52:31 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 090864014F; Mon, 21 Mar 2022 03:52:31 +0100 (CET) Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) by mails.dpdk.org (Postfix) with ESMTP id 4B4BD4014F for ; Mon, 21 Mar 2022 03:52:30 +0100 (CET) Received: by mail-pf1-f175.google.com with SMTP id l8so14372827pfu.1 for ; Sun, 20 Mar 2022 19:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rBM7AMy2pZM4lw+QB5InSCC2gGiUy86DZ70PSmPfl0A=; b=jQOPqdtcEMddhVWILZQb9v02BstH0gduoYGH7SWKc8bYPMJwMOymHFQaC0B8CfubVK KcSorZoiswOICNijUS3WqNfpyz3uw7c2tMSKumzwFpDi5H3yLrz75UANNVq/4lLMXDZK blRY022mhXKmMfD1qxm/cy3iG6q1aIkKOcIA1B4BS5MST050+w6yhntlYyLQNz9yVczm mZw3+ZPAw8oFvCsGqGNLyhNltbeeu/h3qTmL4dcYPqOYDLGoCesni1vORjPZQR0PhXin RFwBtyezN227+tgY2qbUnFAwC/2jY94/noAQD2OcARTg6PguYfGleoJpzza2CnmPVH0+ o3Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rBM7AMy2pZM4lw+QB5InSCC2gGiUy86DZ70PSmPfl0A=; b=7QpG5gu0iWiOtvGUhOQpCRUNo6VYFZfSdToEe49JcyUN4X/OmIu2HXnom8oUYQIlSQ +PIouDGY/aTLfzwT58sYBcnyHzFjxs9K4B10GJiZi8yXGrxChRdg5hLAas3o6708W1/U 5bV3lhbEa5bg3SQDLLiJMFbJLek8uHO8t03YXFVnKK6V0fer8RwcsP7MZAFA2z3DprLN tKBnDO3JVbWBrVpA2nrwnKL9zBmLvNoMsBzacZLby73NmAATEa2w2/by1DtETMrfXlv0 kbuoPe9PcBPw5YJs+wK1MBS1nkSyG6CJ+y6wE9OEPBoTI1lVDsNnYGtGWHW+mEqC5Z5P XnFg== X-Gm-Message-State: AOAM53091UWUkN45QruqKTt7Sq1qhYhPvdAktAxOHC4DktYvKALs2TmZ 9o4wVzH/Tz2jqcIkT3It56XbLmUusTbvcQVkJRI= X-Google-Smtp-Source: ABdhPJyHtTmiXu1YJg3nXJWIs9VvsWHEcQy0dagYVbVkDNGTRFTtB3vCVviuFEvVEGtUht3NbAdRjd6O9XGhFleoN/c= X-Received: by 2002:a05:6a00:ad0:b0:4f7:a357:6899 with SMTP id c16-20020a056a000ad000b004f7a3576899mr21464061pfl.80.1647831149238; Sun, 20 Mar 2022 19:52:29 -0700 (PDT) MIME-Version: 1.0 References: <20220228082724.1646930-1-baymaxhuang@gmail.com> In-Reply-To: From: Harold Huang Date: Mon, 21 Mar 2022 10:52:18 +0800 Message-ID: Subject: Re: [PATCH] net/tap: do not include l2 header in gso size when compared with mtu To: Ophir Munk Cc: "stable@dpdk.org" , Keith Wiles , Raslan Darawsheh , "jiayu.hu@intel.com" , Ferruh Yigit Content-Type: text/plain; charset="UTF-8" X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Hello, On Fri, Mar 18, 2022 at 5:22 PM Ophir Munk 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 > > Sent: Tuesday, March 8, 2022 4:35 PM > > To: dev@dpdk.org > > Cc: Ophir Munk ; stable@dpdk.org; Keith Wiles > > ; Raslan Darawsheh ; > > 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 > > 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 > > > --- > > > 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