Message ID | 20221202221213.236564-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 q4csp1096258wrr; Fri, 2 Dec 2022 14:17:55 -0800 (PST) X-Google-Smtp-Source: AA0mqf5a/pBuaX4nZxK43KWZ1VDBAjyqQ/VveYs1GE2V6a5NdmTx4OaeDm+e4mJOcgew/mFehW5W X-Received: by 2002:aa7:dd4d:0:b0:45c:98a9:7bbf with SMTP id o13-20020aa7dd4d000000b0045c98a97bbfmr49814737edw.372.1670019475366; Fri, 02 Dec 2022 14:17:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670019475; cv=none; d=google.com; s=arc-20160816; b=YIKOxtZk6M549I3e4xsRpXWzIuvEP/2RWVsWf3HLnU4QogmvsSeJLuAZybCz4qh4I3 PYcty+ZRyv/4w7DIVH9GmUF8cUsZv5W4gCgapI/PB8m1Uqa+32Z1l3rg+ifbJxcr+8nK pqZyaUwqEP6TBQx1lOehwlgm4KLqlkBUSPNz1Vxah6q5sTZGOx9o+bjieLv3nS+/alOK JVghurCF7qtF/bLPe/VrWdj30q259xJUGM4SJbgKsvkngJrD2uexJQCOkdKMfnU5/2Lv ierYWfeA+EfH520H78DyPEbkou+L0gHHgrqei/UlMOyQzHhgJaAMpyZiHfnWH2jUbID+ TpeA== 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=RxFknGyAkcIOOsCgLG6r1err07+MBrN/SSNfaLXlwhg=; b=urTgQKWQppHZZvcAT/+2xu/nRJtgIo8vw2dcac6Cph36Zo6HgCA8sm8sD2PrUn0fhK BLJFSMuOp2IzxW64pUdaWvLHNf9hmxCEpHoLaFvNcw7QItpbwY3wHE+b0krWkYfkzb3w DlE+xyzwFwBj4NqwNY9LZ2n64GukfhA/DfMeM1qF7pBaQrDOiQNsA7cG7t4qBzcvbl6S hLH6eKQH/oNTs9qGQfh8piHgaWJmF3eRl049yCgGF8OK1DutCHcmFZhSDxpcAlxgixWI KJsI9qJgSlB6BRb7y5pzvO/lcvPM/3hO6rFULpTVhwWaLKADTkIaitervByrpkMLYZxG BbBQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=dB0yZm0v; 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 g8-20020a056402090800b004604906b23csi5156317edz.545.2022.12.02.14.17.32; Fri, 02 Dec 2022 14:17:55 -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=dB0yZm0v; 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 S234804AbiLBWMa (ORCPT <rfc822;lhua1029@gmail.com> + 99 others); Fri, 2 Dec 2022 17:12:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59344 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234191AbiLBWMX (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 2 Dec 2022 17:12:23 -0500 Received: from mail-pf1-x449.google.com (mail-pf1-x449.google.com [IPv6:2607:f8b0:4864:20::449]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 53807F9304 for <linux-kernel@vger.kernel.org>; Fri, 2 Dec 2022 14:12:22 -0800 (PST) Received: by mail-pf1-x449.google.com with SMTP id 67-20020a621946000000b00575f8210320so6107618pfz.10 for <linux-kernel@vger.kernel.org>; Fri, 02 Dec 2022 14:12:22 -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=RxFknGyAkcIOOsCgLG6r1err07+MBrN/SSNfaLXlwhg=; b=dB0yZm0vtYjeMx8aJ36Rn/NpjR0HOQmUVA3aFPdVivS5kxj7wKoAsTcPNoAT8arhsA mQ+6r2J7uLpsNM8NKQTyTNs2dq7CwDZ+Weqd9hrvp/SKJTIFJHtCid/SZc3i8gTmyvQu C7aJm96Wbv/dWI2bZdS7+Yt72IEFTOLcuNOol3UVrk2PpZhu6wBtUMy6AzH0T59kGjbk 8d3jHrPMVbv0y2Wjpq8abKjL0TqRYfkNXrjHpFKLSIKysLF2EKnhVQX9dOYMbLlW1ssP QfeaS1GnYMTpnZsw7unZNrZUy9WZ21Su51G8exq8HfqMVSO9Tf4q2MU4/zRNq8crE6y6 W72Q== 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=RxFknGyAkcIOOsCgLG6r1err07+MBrN/SSNfaLXlwhg=; b=FjEQjOzyJPdOSOmdaSkHlHnCeeA20ysHFOg4dK3FVtmNaqB7bBcpQCxfI/38vlseTP bOPLedjLjyjTdZAWWMgJagVc9+Ex8uTEMR53Sjzz19ZSjUlybFuHyaWl3GpTvYoIpc2n WFKZ9DqSUjMwCAY/V/BYbzWdQH1e+sm0rQ+jjXpo6SKmyMftrKilvGAPfI2VWp5N5DCd 2M+08mW+pdPd/tuAsAajKz1+821Z63yFACLbE7qMO/xVXY1AM1xmLALA0P9W2jk4zwnO 8BHegjK4qnszQgpwSnPjl0bH0L55Gzon6jBtcquxUclb/8Ca5u2GX86pMMTFG7KzDlBr ZOfA== X-Gm-Message-State: ANoB5pmeuGQ8fPIslyLMOObdT08kGzDCwUruZttmFhf6WkgMMz2iwnKU tyoMCp1U2ZK1Gzu3N8uX3JXrm7PgJx4u+0w= X-Received: from lixiaoyan-desktop.svl.corp.google.com ([2620:15c:2c4:201:806c:1abb:ce24:13cf]) (user=lixiaoyan job=sendgmr) by 2002:a05:6a00:2183:b0:574:2104:5657 with SMTP id h3-20020a056a00218300b0057421045657mr51866119pfi.58.1670019141829; Fri, 02 Dec 2022 14:12:21 -0800 (PST) Date: Fri, 2 Dec 2022 14:12:13 -0800 In-Reply-To: <20221202221213.236564-1-lixiaoyan@google.com> Mime-Version: 1.0 References: <20221202221213.236564-1-lixiaoyan@google.com> X-Mailer: git-send-email 2.39.0.rc0.267.gcb52ba06e7-goog Message-ID: <20221202221213.236564-2-lixiaoyan@google.com> Subject: [RFC net-next v4 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?1751142341379521478?= X-GMAIL-MSGID: =?utf-8?q?1751142341379521478?= |
Series |
[RFC,net-next,v4,1/2] IPv6/GRO: generic helper to remove temporary HBH/jumbo header in driver
|
|
Commit Message
Coco Li
Dec. 2, 2022, 10:12 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. Big TCP functionality is tested by Michael, feature checks not yet. Tested by Michael: 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> Signed-off-by: Coco Li <lixiaoyan@google.com> --- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 26 ++++++++++++++++++++++- 1 file changed, 25 insertions(+), 1 deletion(-)
Comments
On Fri, Dec 2, 2022 at 11:12 PM 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. > > Big TCP functionality is tested by Michael, feature checks not yet. > > Tested by Michael: > 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> > Signed-off-by: Coco Li <lixiaoyan@google.com> > --- > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 26 ++++++++++++++++++++++- > 1 file changed, 25 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c > index 0fe164b42c5d..c2713cb5debd 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; > @@ -11342,9 +11345,28 @@ static bool bnxt_exthdr_check(struct bnxt *bp, struct sk_buff *skb, int nw_off, > > if (hdrlen > 64) > return false; > + > + /* The ext header may be a hop-by-hop header inserted for > + * big TCP purposes. This will be removed before sending > + * from NIC, so do not count it. > + */ > + if (*nexthdr == NEXTHDR_HOP) { > + if (likely(skb->len <= GRO_LEGACY_MAX_SIZE)) > + goto increment_hdr; > + > + struct hop_jumbo_hdr *jhdr = (struct hop_jumbo_hdr *)(nexthdr + hdrlen); We discourage adding a variable declaration in the middle of code. > + > + if (jhdr->tlv_type != IPV6_TLV_JUMBO || jhdr->hdrlen != 0 || > + (jhdr->nexthdr != IPPROTO_TCP && jhdr->nexthdr != IPPROTO_UDP)) Why testing IPPROTO_UDP ? I do not think we support BIG UDP yet. > + goto increment_hdr; > + > + goto next_hdr; > + } > +increment_hdr: > + hdr_count++; > +next_hdr: > nexthdr = &hp->nexthdr; > start += hdrlen; > - hdr_count++; > } > if (nextp) { > /* Caller will check inner protocol */ > @@ -13657,6 +13679,8 @@ 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 > -- > 2.39.0.rc0.267.gcb52ba06e7-goog >
On Sun, Dec 4, 2022 at 9:14 PM Eric Dumazet <edumazet@google.com> wrote: > > On Fri, Dec 2, 2022 at 11:12 PM 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. > > > > Big TCP functionality is tested by Michael, feature checks not yet. > > > > Tested by Michael: > > 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> > > Signed-off-by: Coco Li <lixiaoyan@google.com> > > --- > > drivers/net/ethernet/broadcom/bnxt/bnxt.c | 26 ++++++++++++++++++++++- > > 1 file changed, 25 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c > > index 0fe164b42c5d..c2713cb5debd 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; > > @@ -11342,9 +11345,28 @@ static bool bnxt_exthdr_check(struct bnxt *bp, struct sk_buff *skb, int nw_off, > > > > if (hdrlen > 64) > > return false; > > + > > + /* The ext header may be a hop-by-hop header inserted for > > + * big TCP purposes. This will be removed before sending > > + * from NIC, so do not count it. > > + */ > > + if (*nexthdr == NEXTHDR_HOP) { > > + if (likely(skb->len <= GRO_LEGACY_MAX_SIZE)) > > + goto increment_hdr; > > + > > + struct hop_jumbo_hdr *jhdr = (struct hop_jumbo_hdr *)(nexthdr + hdrlen); > > We discourage adding a variable declaration in the middle of code. > This doesn't work. Initially nexthdr points to the nexthdr in the ipv6 header. It should be coded like this: struct hop_jumbo_hdr *jhdr = (struct hop_jumbo_hdr *)hp; Thanks.
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c index 0fe164b42c5d..c2713cb5debd 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; @@ -11342,9 +11345,28 @@ static bool bnxt_exthdr_check(struct bnxt *bp, struct sk_buff *skb, int nw_off, if (hdrlen > 64) return false; + + /* The ext header may be a hop-by-hop header inserted for + * big TCP purposes. This will be removed before sending + * from NIC, so do not count it. + */ + if (*nexthdr == NEXTHDR_HOP) { + if (likely(skb->len <= GRO_LEGACY_MAX_SIZE)) + goto increment_hdr; + + struct hop_jumbo_hdr *jhdr = (struct hop_jumbo_hdr *)(nexthdr + hdrlen); + + if (jhdr->tlv_type != IPV6_TLV_JUMBO || jhdr->hdrlen != 0 || + (jhdr->nexthdr != IPPROTO_TCP && jhdr->nexthdr != IPPROTO_UDP)) + goto increment_hdr; + + goto next_hdr; + } +increment_hdr: + hdr_count++; +next_hdr: nexthdr = &hp->nexthdr; start += hdrlen; - hdr_count++; } if (nextp) { /* Caller will check inner protocol */ @@ -13657,6 +13679,8 @@ 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