From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B10C0C433E0 for ; Fri, 12 Mar 2021 18:38:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7C20064DEC for ; Fri, 12 Mar 2021 18:38:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233580AbhCLShn (ORCPT ); Fri, 12 Mar 2021 13:37:43 -0500 Received: from mail1.protonmail.ch ([185.70.40.18]:62345 "EHLO mail1.protonmail.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233517AbhCLShK (ORCPT ); Fri, 12 Mar 2021 13:37:10 -0500 Date: Fri, 12 Mar 2021 18:36:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail; t=1615574228; bh=C4flYNl55MhaTml/vQIThEyldeDzlRdNXoMAWOGH2ZU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=Qz+2/NJcNf9bDM6PkSlnYsbqlAX12lI2+aZ/GiEqrund2o7VjfuoRcv6C6wXppBZ/ KoPhQqf2NMM85+XnHD+Sv6xkuWlX5SSbwdl6T4l4yWf4mtRCVVsO7iWk4U2aVAXp43 LUNM5aMMbaUXX38bZoM5qlBzvs5lq/eVz/SGkL9lHS0hEIiICmkGBLZoQ9yWrsOduv 0bQA82/45rbBgfWo9CvaD7ugphtytM/W6s36VLDdjddneMRTOYprNMapNNHbs6Oj3t y/AM2DzN3A4JY6ZNFY5qeHHylgDPhXAdIkdQcBCqjt4eICH/IVr31XnaONkSATSWNN +GbDLk+9HPuTQ== To: Eric Dumazet From: Alexander Lobakin Cc: Alexander Lobakin , "David S. Miller" , Jakub Kicinski , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Wei Wang , Cong Wang , Taehee Yoo , netdev , LKML Reply-To: Alexander Lobakin Subject: Re: [PATCH net-next 2/4] gro: don't dereference napi->gro_hash[x] multiple times in dev_gro_receive() Message-ID: <20210312183648.242117-1-alobakin@pm.me> In-Reply-To: References: <20210312162127.239795-1-alobakin@pm.me> <20210312162127.239795-3-alobakin@pm.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Eric Dumazet Date: Fri, 12 Mar 2021 17:47:04 +0100 > On Fri, Mar 12, 2021 at 5:22 PM Alexander Lobakin wrote: > > > > GRO bucket index doesn't change through the entire function. > > Store a pointer to the corresponding bucket on stack once and use > > it later instead of dereferencing again and again. > > > > Signed-off-by: Alexander Lobakin > > --- > > net/core/dev.c | 9 +++++---- > > 1 file changed, 5 insertions(+), 4 deletions(-) > > > > diff --git a/net/core/dev.c b/net/core/dev.c > > index adc42ba7ffd8..ee124aecb8a2 100644 > > --- a/net/core/dev.c > > +++ b/net/core/dev.c > > @@ -5957,6 +5957,7 @@ static void gro_flush_oldest(struct napi_struct *= napi, struct list_head *head) > > static enum gro_result dev_gro_receive(struct napi_struct *napi, struc= t sk_buff *skb) > > { > > u32 bucket =3D skb_get_hash_raw(skb) & (GRO_HASH_BUCKETS - 1); > > + struct gro_list *gro_list =3D &napi->gro_hash[bucket]; > > struct list_head *head =3D &offload_base; > > struct packet_offload *ptype; > > __be16 type =3D skb->protocol; > > @@ -6024,7 +6025,7 @@ static enum gro_result dev_gro_receive(struct nap= i_struct *napi, struct sk_buff > > if (pp) { > > skb_list_del_init(pp); > > napi_gro_complete(napi, pp); > > - napi->gro_hash[bucket].count--; > > + gro_list->count--; > > } > > > > if (same_flow) > > @@ -6033,10 +6034,10 @@ static enum gro_result dev_gro_receive(struct n= api_struct *napi, struct sk_buff > > if (NAPI_GRO_CB(skb)->flush) > > goto normal; > > > > - if (unlikely(napi->gro_hash[bucket].count >=3D MAX_GRO_SKBS)) { > > + if (unlikely(gro_list->count >=3D MAX_GRO_SKBS)) { > > gro_flush_oldest(napi, gro_head); > > } else { > > - napi->gro_hash[bucket].count++; > > + gro_list->count++; > > } > > NAPI_GRO_CB(skb)->count =3D 1; > > NAPI_GRO_CB(skb)->age =3D jiffies; > > @@ -6050,7 +6051,7 @@ static enum gro_result dev_gro_receive(struct nap= i_struct *napi, struct sk_buff > > if (grow > 0) > > gro_pull_from_frag0(skb, grow); > > ok: > > - if (napi->gro_hash[bucket].count) { > > + if (gro_list->count) { > > if (!test_bit(bucket, &napi->gro_bitmask)) > > __set_bit(bucket, &napi->gro_bitmask); > > } else if (test_bit(bucket, &napi->gro_bitmask)) { > > -- > > 2.30.2 > > > > > > This adds more register pressure, do you have precise measures to > confirm this change is a win ? > > Presumably the compiler should be able to optimize the code just fine, > it can see @bucket does not change. This is mostly (if not purely) cosmetic, I don't think it changes anything at all for the most of sane compilers. Regarding registers, since @gro_list and @gro_head are pretty the same, we could drop @gro_head in favour of @gro_list and just use @gro_list->list instead. Al