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 D15074318E for ; Tue, 17 Oct 2023 18:47:20 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AF6F942DC4; Tue, 17 Oct 2023 18:47:20 +0200 (CEST) Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) by mails.dpdk.org (Postfix) with ESMTP id 11956427DE for ; Tue, 17 Oct 2023 18:47:18 +0200 (CEST) Received: by mail-pg1-f182.google.com with SMTP id 41be03b00d2f7-565334377d0so4411246a12.2 for ; Tue, 17 Oct 2023 09:47:18 -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=nJNze6/AZmNo6JLVR55ZOqORtrbOqFu2tGBcMj+cEUl0vRan74m88pi2e97yFQSZyn isK+a6fCkFC2tvAK1bQpcSB9qvitklhdgqMyZaQIEv8R5lmmG5TGy8G4Cu3Y7F4/K6Ug HdaVXDmm2o7uBiYHej0kCZu/rcU4N4TEYeILEHMWSfU2UbtUmKtgdihqf5wR5Tz5/RDp TSqbGC421+6ESGUEdzL1rZuZQNPCbl0gvCRyggcHUrBZEy1kKe+n/r9BsYan2Fva5IKR h+cmHDicGsw1U+k831YgxJszz9ly/BdgR2CGQ1hZTaw5puKM9ImwJ4s2W75fIe8914On ruSQ== X-Gm-Message-State: AOJu0YyY3gYPyh/UBBdoh5x9P/+q3hvZGJ5Mo6WlludJOzwsdOsXrcp3 xK4CmXGsGJ+blTSHLKUmcm2xEw== 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: 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 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)