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 B610E4318E; Tue, 17 Oct 2023 18:47:19 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A13E3427DE; Tue, 17 Oct 2023 18:47:19 +0200 (CEST) Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) by mails.dpdk.org (Postfix) with ESMTP id 10AE0410D3 for ; Tue, 17 Oct 2023 18:47:18 +0200 (CEST) Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-6b1ef786b7fso4140295b3a.3 for ; Tue, 17 Oct 2023 09:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1697561237; x=1698166037; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=/rMbEaXib8tZ+qSRzL3OEct61n+7Xel46k1Hs7jnB0E=; b=tLyZOKdxFvuxp24DAHuwqzYR6WPEWTagrhjtAPvOoDWu8QBsRgtJgXOYUfq6UxP4MD HXbnh9b/v7qUclQedeQ4zNBCkUKkDHjggUG8r4Nb423W7FntvraS9no8Mnt9nQafc2v0 KuO8Iz83+LiAhWgUoX5cmbc7VKEvZRM5WFFCa5Ng8mxHavuExCpbD4Mm975O9BOdW6vr u58NMQYmgSIwEUOMTUxcxOXiiO/j5dMahtp4mvUEzjxPfr/sJaOuM4X5nf4rvxWM5F2A qfdNyq1x6eOPsWwsmFcLASufPHfru0s8DskTonfMwLpxXBN4pYpqNVBe8AjOZnVTmURX MklA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697561237; x=1698166037; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/rMbEaXib8tZ+qSRzL3OEct61n+7Xel46k1Hs7jnB0E=; b=kQvT5o4TMLWI0AJhxs2dDgfwDkUt4uN9PIxqjMmEab1CxMlknyLcno7ulIfsX3Nrr+ Folm8jl/IDJTlPfph5RZu0J9CkjkBgLHXP6r3U5+spqHqoE+SgURyOEV6uEU7XhyKVl0 r7GMF9RGH3WvwSr4J17DzHNaDwT5us4nK9jC/ir3O5i6pAjYs+UiMYcvAdNt0NAzxrep fzmqPTKzXjrutIsrNnXkvpjbIbMEJmd5lQv//HAQtSQ7qncxnWbdLxJdkx3VPVdM4MoP FaN/b8ku100i/zp6D0u4JfUg0+ThVqqkCRPlzScQpFb1BdaVSSo69N4R4qaH9CqZGaL2 Pnrw== X-Gm-Message-State: AOJu0YzoCljp7mQTl6Sf5qn2pG05KWXTEv03pHLvKNwhCaBa68jrsQY2 RvO7htCmfwl8qaja74i5K2gsOw== X-Google-Smtp-Source: AGHT+IHgNueijeGvRlJdrJu61yVt9c+c+Al4LeYhlWFaMCrXvkNXOjmErXq6tOir8nQrecCOJxK5wg== X-Received: by 2002:a05:6300:8001:b0:13e:7d3:61d1 with SMTP id an1-20020a056300800100b0013e07d361d1mr2663037pzc.12.1697561237210; Tue, 17 Oct 2023 09:47:17 -0700 (PDT) Received: from hermes.local (204-195-126-68.wavecable.com. [204.195.126.68]) by smtp.gmail.com with ESMTPSA id jc2-20020a17090325c200b001c611e9a5fdsm1807016plb.306.2023.10.17.09.47.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 09:47:17 -0700 (PDT) Date: Tue, 17 Oct 2023 09:47:15 -0700 From: Stephen Hemminger To: Harold Huang Cc: dev@dpdk.org, ophirmu@mellanox.com, 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 Message-ID: <20231017094715.02bde0b7@hermes.local> In-Reply-To: References: <20220228082724.1646930-1-baymaxhuang@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, 8 Mar 2022 22:35:18 +0800 Harold Huang wrote: > 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? See Ophir's comment and address it in new version Please note that max size is calculated in the same function (drivers/net/tap/rte_eth_tap.c) as: max_size = *txq->mtu + (RTE_ETHER_HDR_LEN + RTE_ETHER_CRC_LEN + 4); Since tso_setgsz should not exceed the max packet size - the desired update should be: tso_segsz > max_size rather than the suggested one: tso_segsz > *txq->mtu + mbuf_in->l2_len)