Message ID | 20221123191627.3442831-2-lixiaoyan@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp2986985wrr; Wed, 23 Nov 2022 11:35:32 -0800 (PST) X-Google-Smtp-Source: AA0mqf4wxNf8okOqoGYU0zFNKGWRCcZtot3NMJVtpWTA39mm4CeILcO43NcMoIb1j856UtQadFXu X-Received: by 2002:a63:ec07:0:b0:470:90f1:6216 with SMTP id j7-20020a63ec07000000b0047090f16216mr27310343pgh.42.1669232132298; Wed, 23 Nov 2022 11:35:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669232132; cv=none; d=google.com; s=arc-20160816; b=NJtKE18Sb/HQr4tDW6Oqky5SyIRlsSfCDdsRP104coN0sP5VfVUTOcYk1MnzyJa5kL XeYTwnKCNXQU/E8pIUrqhMC/AnBv9LLu0ByBfsRUos0Enf+JrES1/HcEtqxR4nVz+psq Q0ahuWYOSF5QPYfhe8X6+eroC0qOH49FukJjgmxoLySuci3xWwfEGuo279LdyQVBifGt 1m4swDNM/xBrs8oAbpQVzO4d6wrQLChsPrKilD+eqGcFFgmSooU8z0ex0VTgjesLo7HE rJImLch9qJjhaPdP0t7oEV8DhuQrOWpvZMGRuXzPMc+ALc9xKbrsa9UsdkwDM361Iq+c 2nyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:dkim-signature; bh=mXrL4mXjPPRNXGN8jBngxsBYSqmiNdb+yw7fcajaaOY=; b=YjhjcUmCDAAhddHOZi89lMKq9yJxA2mjjFjr9ymXHa8L4OQkBIM1uiFIWY1/BJx5Ax EkPWUUiOn3DossgJdn2yRNge4K18n4h/gERT/+13NUMY2AmY3ea+AxE2fCGYSNsypHN8 H+YOd7d3ejjOR4UE+xzeuQLNpEJRX4SOXBPFmqOH/5axZciFgsnrnVR0GILFmOpNQwhv kpvvXQSo+dxxQAgX/FG18UU9EMQkUpJpyj/seu2zYkX4YA5f1NexGAAH+Ug70H33OP0x WwlgAbmVRtSRfKlkbn64NKfrk+55fGDopP2IgjyC9oARLEnHvu2opQKxHOM4NTrLG/2d aK9w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=IB+ar8Wm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n1-20020a63b441000000b00438b79bcf26si17134829pgu.151.2022.11.23.11.35.19; Wed, 23 Nov 2022 11:35:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=IB+ar8Wm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236688AbiKWTQp (ORCPT <rfc822;fengqi706@gmail.com> + 99 others); Wed, 23 Nov 2022 14:16:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239329AbiKWTQm (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 23 Nov 2022 14:16:42 -0500 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EE185C720C for <linux-kernel@vger.kernel.org>; Wed, 23 Nov 2022 11:16:40 -0800 (PST) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-39967085ae9so121610457b3.11 for <linux-kernel@vger.kernel.org>; Wed, 23 Nov 2022 11:16:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=mXrL4mXjPPRNXGN8jBngxsBYSqmiNdb+yw7fcajaaOY=; b=IB+ar8WmQFgm8e6yBH0P9Orz+hB2yaIz/otrVtei4QWtyj59kJt1c7tiuX7/fBPoSL RdX4ca0AUITSv5FsjskmtSgYK/c7CwNua3yClFXeyWHsalnTdTuBgQk9dm52CNntiRmP cv/RPUbgGsbuNJFjjlCSXaE7Fs/k8DHDPB68UqRo/Mq59Vn2bLRPRrnvc9vFw15DkI95 wpbaxjxkegzhABrjskD/Esv5IuLITp0Om7jyukeXKmUeMDELC8F4UGu2fj1Y2M390d9l IwxU520sbdiwpnZrKzvLOrta6O7+W6d0vXuGWC9fbjW9L6os3L8z2k85Za30Djjrtc3S jb+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mXrL4mXjPPRNXGN8jBngxsBYSqmiNdb+yw7fcajaaOY=; b=mzuBowwn0l0AuKJw7GnmQ1CLVWc72vncC3yva0W7DH9jJxwM/uMKYoA3zcZD6qaIZm 3DdNBUQ+3hLJ0h9Ey4PFZobebo7vFgbqgNGWHK3ql64sq1oWf/P/ljqmT96GxwFrCqUk nItAcAHR6z+VNqy9YN+oe6PjiZ5MkS/fpND4RND5NGb9/WlpGRhfk62J5Zd4hhF0Z370 Q7YksFXHSuDKHSTNxM+pyqCvEI6fVpqq7GBQdjlme7M6DRVioZKgAJN2CPUHfIcTWMh2 E6bV+Pi4J+CsxoOOo6BTeg9ENJrOQWEpT/CwsxFbhKiUI8gpqZ6jgoJ52TD5+aYXk7Gw V/Qw== X-Gm-Message-State: ANoB5pkGIOB2MOO7XpLE4eMtTqxW0JS/mSfAJxZL4rtAWew/zhuNWGEI IzNzX3Jjo01DLx9MoCKVeylfRMubBzV0q8o= X-Received: from lixiaoyan-desktop.svl.corp.google.com ([2620:15c:2c4:201:d403:2d3e:7222:9b9c]) (user=lixiaoyan job=sendgmr) by 2002:a25:84cc:0:b0:6e6:b5f0:3ae0 with SMTP id x12-20020a2584cc000000b006e6b5f03ae0mr28492403ybm.439.1669231000212; Wed, 23 Nov 2022 11:16:40 -0800 (PST) Date: Wed, 23 Nov 2022 11:16:27 -0800 In-Reply-To: <20221123191627.3442831-1-lixiaoyan@google.com> Mime-Version: 1.0 References: <20221123191627.3442831-1-lixiaoyan@google.com> X-Mailer: git-send-email 2.38.1.584.g0f3c55d4c2-goog Message-ID: <20221123191627.3442831-2-lixiaoyan@google.com> Subject: [RFC net-next v2 2/2] bnxt: Use generic HBH removal helper in tx path From: Coco Li <lixiaoyan@google.com> To: "David S. Miller" <davem@davemloft.net>, Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>, David Ahern <dsahern@kernel.org>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Michael Chan <michael.chan@broadcom.com> Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Coco Li <lixiaoyan@google.com> Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HK_RANDOM_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750316752163955097?= X-GMAIL-MSGID: =?utf-8?q?1750316752163955097?= |
Series |
[net-next,v2,1/2] IPv6/GRO: generic helper to remove temporary HBH/jumbo header in driver
|
|
Commit Message
Coco Li
Nov. 23, 2022, 7:16 p.m. UTC
Eric Dumazet implemented Big TCP that allowed bigger TSO/GRO packet sizes
for IPv6 traffic. See patch series:
'commit 89527be8d8d6 ("net: add IFLA_TSO_{MAX_SIZE|SEGS} attributes")'
This reduces the number of packets traversing the networking stack and
should usually improves performance. However, it also inserts a
temporary Hop-by-hop IPv6 extension header.
Using the HBH header removal method in the previous path, the extra header
be removed in bnxt drivers to allow it to send big TCP packets (bigger
TSO packets) as well.
Tested:
Compiled locally
To further test functional correctness, update the GSO/GRO limit on the
physical NIC:
ip link set eth0 gso_max_size 181000
ip link set eth0 gro_max_size 181000
Note that if there are bonding or ipvan devices on top of the physical
NIC, their GSO sizes need to be updated as well.
Then, IPv6/TCP packets with sizes larger than 64k can be observed.
Signed-off-by: Coco Li <lixiaoyan@google.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 4 ++++
1 file changed, 4 insertions(+)
Comments
On Wed, Nov 23, 2022 at 11:16 AM Coco Li <lixiaoyan@google.com> wrote: > > Eric Dumazet implemented Big TCP that allowed bigger TSO/GRO packet sizes > for IPv6 traffic. See patch series: > 'commit 89527be8d8d6 ("net: add IFLA_TSO_{MAX_SIZE|SEGS} attributes")' > > This reduces the number of packets traversing the networking stack and > should usually improves performance. However, it also inserts a > temporary Hop-by-hop IPv6 extension header. > > Using the HBH header removal method in the previous path, the extra header > be removed in bnxt drivers to allow it to send big TCP packets (bigger > TSO packets) as well. > > Tested: > Compiled locally > > To further test functional correctness, update the GSO/GRO limit on the > physical NIC: > > ip link set eth0 gso_max_size 181000 > ip link set eth0 gro_max_size 181000 > > Note that if there are bonding or ipvan devices on top of the physical > NIC, their GSO sizes need to be updated as well. > > Then, IPv6/TCP packets with sizes larger than 64k can be observed. > > Signed-off-by: Coco Li <lixiaoyan@google.com> > --- > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c > index 0fe164b42c5d..2bfa5e9fb179 100644 > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c > @@ -389,6 +389,9 @@ static netdev_tx_t bnxt_start_xmit(struct sk_buff *skb, struct net_device *dev) > return NETDEV_TX_BUSY; > } > > + if (unlikely(ipv6_hopopt_jumbo_remove(skb))) > + goto tx_free; > + > length = skb->len; > len = skb_headlen(skb); > last_frag = skb_shinfo(skb)->nr_frags; > @@ -13657,6 +13660,7 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) > dev->features &= ~NETIF_F_LRO; > dev->priv_flags |= IFF_UNICAST_FLT; > > + netif_set_tso_max_size(dev, GSO_MAX_SIZE); Our chips can only transmit TSO packets up to 64K bytes, so I think this won't work.
On Wed, Nov 23, 2022 at 11:42 AM Michael Chan <michael.chan@broadcom.com> wrote: > > On Wed, Nov 23, 2022 at 11:16 AM Coco Li <lixiaoyan@google.com> wrote: > > > > @@ -13657,6 +13660,7 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) > > dev->features &= ~NETIF_F_LRO; > > dev->priv_flags |= IFF_UNICAST_FLT; > > > > + netif_set_tso_max_size(dev, GSO_MAX_SIZE); > > Our chips can only transmit TSO packets up to 64K bytes, so I think > this won't work. I wanted to double check with the hardware team but there's no one in the office today. I will confirm early next week. Thanks.
On Wed, Nov 23, 2022 at 11:42 AM Michael Chan <michael.chan@broadcom.com> wrote: > > On Wed, Nov 23, 2022 at 11:16 AM Coco Li <lixiaoyan@google.com> wrote: > > > > Eric Dumazet implemented Big TCP that allowed bigger TSO/GRO packet sizes > > for IPv6 traffic. See patch series: > > 'commit 89527be8d8d6 ("net: add IFLA_TSO_{MAX_SIZE|SEGS} attributes")' > > > > This reduces the number of packets traversing the networking stack and > > should usually improves performance. However, it also inserts a > > temporary Hop-by-hop IPv6 extension header. > > > > Using the HBH header removal method in the previous path, the extra header > > be removed in bnxt drivers to allow it to send big TCP packets (bigger > > TSO packets) as well. > > > > Tested: > > Compiled locally > > > > To further test functional correctness, update the GSO/GRO limit on the > > physical NIC: > > > > ip link set eth0 gso_max_size 181000 > > ip link set eth0 gro_max_size 181000 > > > > Note that if there are bonding or ipvan devices on top of the physical > > NIC, their GSO sizes need to be updated as well. > > > > Then, IPv6/TCP packets with sizes larger than 64k can be observed. > > > > Signed-off-by: Coco Li <lixiaoyan@google.com> I've confirmed with our hardware team that this is supported by our chips, and I've tested it up to gso_max_size of 524280. Thanks. Tested-by: Michael Chan <michael.chan@broadcom.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com>
Great, thanks Michael! Will send a new version of the patch. Best, Coco Li On Tue, Nov 29, 2022 at 12:59 AM Michael Chan <michael.chan@broadcom.com> wrote: > > On Wed, Nov 23, 2022 at 11:42 AM Michael Chan <michael.chan@broadcom.com> wrote: > > > > On Wed, Nov 23, 2022 at 11:16 AM Coco Li <lixiaoyan@google.com> wrote: > > > > > > Eric Dumazet implemented Big TCP that allowed bigger TSO/GRO packet sizes > > > for IPv6 traffic. See patch series: > > > 'commit 89527be8d8d6 ("net: add IFLA_TSO_{MAX_SIZE|SEGS} attributes")' > > > > > > This reduces the number of packets traversing the networking stack and > > > should usually improves performance. However, it also inserts a > > > temporary Hop-by-hop IPv6 extension header. > > > > > > Using the HBH header removal method in the previous path, the extra header > > > be removed in bnxt drivers to allow it to send big TCP packets (bigger > > > TSO packets) as well. > > > > > > Tested: > > > Compiled locally > > > > > > To further test functional correctness, update the GSO/GRO limit on the > > > physical NIC: > > > > > > ip link set eth0 gso_max_size 181000 > > > ip link set eth0 gro_max_size 181000 > > > > > > Note that if there are bonding or ipvan devices on top of the physical > > > NIC, their GSO sizes need to be updated as well. > > > > > > Then, IPv6/TCP packets with sizes larger than 64k can be observed. > > > > > > Signed-off-by: Coco Li <lixiaoyan@google.com> > > I've confirmed with our hardware team that this is supported by our > chips, and I've tested it up to gso_max_size of 524280. Thanks. > > Tested-by: Michael Chan <michael.chan@broadcom.com> > Reviewed-by: Michael Chan <michael.chan@broadcom.com>
On Tue, Nov 29, 2022 at 9:29 AM Coco Li <lixiaoyan@google.com> wrote: > > Great, thanks Michael! Will send a new version of the patch. > I just realized one thing. In bnxt_features_check() -> bnxt_exthdr_check(), we check to make sure every extension header is supported by the chip and the number of headers does not exceed what the chip can support. So to be more complete, I think we need to exclude this from being counted.
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c index 0fe164b42c5d..2bfa5e9fb179 100644 --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c @@ -389,6 +389,9 @@ static netdev_tx_t bnxt_start_xmit(struct sk_buff *skb, struct net_device *dev) return NETDEV_TX_BUSY; } + if (unlikely(ipv6_hopopt_jumbo_remove(skb))) + goto tx_free; + length = skb->len; len = skb_headlen(skb); last_frag = skb_shinfo(skb)->nr_frags; @@ -13657,6 +13660,7 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) dev->features &= ~NETIF_F_LRO; dev->priv_flags |= IFF_UNICAST_FLT; + netif_set_tso_max_size(dev, GSO_MAX_SIZE); #ifdef CONFIG_BNXT_SRIOV init_waitqueue_head(&bp->sriov_cfg_wait); #endif