Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1406867pxf; Fri, 12 Mar 2021 08:48:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJwt6wDApuCVjhKrYk00oZ71aISa0le+AnhxiMWAofDRTlJ1lL/+nleef8IiHfEVU9tR1Yur X-Received: by 2002:a17:906:be9:: with SMTP id z9mr9399468ejg.35.1615567729041; Fri, 12 Mar 2021 08:48:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615567729; cv=none; d=google.com; s=arc-20160816; b=fqB0dKF8T0Pi8NphmPtcQYsPiZE7wD8HX/fpr1fXDN/aGqAa2dC5E8kxfbzoXT3ybU OqPqGlv+GxNuJlDa/Q7wz3sQ1n146NqC684Rp3fizEyOvo3QsafnOqMXWHL6V4Ys1x5L DR9ZOs6LpqBw/WJVb13MOWN4MfHX6H9VjJWahj4/bg6bktEpE/0zl9PFMh+RNiKtWcIR Q0rkL8zMGz0jbiM64Y9D4UQHmAVNO2CXbh8cuBd53oj2QLhqalgYpw8WGOstMITRD0uP 5xwt5Wb+iFWc1T5jYpBbLBhOKhfGwKBwGSdFDcQw6t/RB2HuwyNtU2hKRmOXqIxVWFMy aPxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=P32cze7a2DbaaHVivt3tjV61Cys7jJYG2tRw+9iO+48=; b=gvEw08/2/hfYlarqYTdKuMDLGbyjQH8J1WWDW/nnisn2aJ5jpFiuaYq0P5lfCf6PAn iAai8ijrUqwrHzZddxu04NIi7reLlXE3kO3b/BhfU2lSh5D2+CybBmpOJtLyaZ/eCsyg jepo0OQQ4Vpm/uoZP7HwU00+NsqNsAN6PJ4Vhrs4hwqRJ/qFQ4lEbibWe4KNMuzLZrXh iuBdWIEhUCyh/DriBBFMqNrvPgUfPaE9UaBDNq1moG6tHf47JC81KYadbBVwtlPxD3YY aOQKKYbYZqHFDa+QVQeCZCJ/nyShR2lQZnYQbVjJyV4hrlQqN3EaNwCaKZbxcUR7sB1Y nnrw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=sfH0qkB7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w10si4422670ejv.500.2021.03.12.08.48.26; Fri, 12 Mar 2021 08:48:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=sfH0qkB7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S231636AbhCLQr1 (ORCPT + 99 others); Fri, 12 Mar 2021 11:47:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60798 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232702AbhCLQrR (ORCPT ); Fri, 12 Mar 2021 11:47:17 -0500 Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E15C2C061761 for ; Fri, 12 Mar 2021 08:47:16 -0800 (PST) Received: by mail-yb1-xb34.google.com with SMTP id m9so26046124ybk.8 for ; Fri, 12 Mar 2021 08:47:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=P32cze7a2DbaaHVivt3tjV61Cys7jJYG2tRw+9iO+48=; b=sfH0qkB7X8pdt3swnbz6eV8GQgHxxoEqWQqarJBZE7wdJAmbVZMphPeQlS3JnTZj1f E1biaHjBI05u1CzRjkNX9S+zLeaG+HjIzPoiwNuHOGV1kXeDDBBitwga49KRPzUyZZ6N zRk1s/mB7eMkMmJ1YBlTGw+862OF1kyy+d7BensxtVS1XtP5ce0XQ1WnqG5vxHXzR0ok zsyKeii/tdejtSf3rTEY+fAASZWxBibSIuf7h6Yn/rCFKf00wfFxSze1jkDomKUWAvk8 yupy5VJKB4r53OxOqC8/H6oqC5P3YGntS8SzZ9wJtxH/413CwwBigtlEFFGK118pvM2a 18iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P32cze7a2DbaaHVivt3tjV61Cys7jJYG2tRw+9iO+48=; b=WvutW5FvEAQSt1QkRHvhkb5jfJvZbwwi9b73bq+lfdYkutcZHS4IuW04ObPt/v+8J0 FeeVBxFAy1MlCwq+tdFN9k0G92m1QG/N4+1lAOPM+MCExUuTzyzCSnGv3B52qwmXR5k6 ul8KDFubFJ8O8YEzgLVl6G1D/yqCVRBtfCKICSKnpBvKpIAOyA/IPGel59Vi5lybPdab KvUSQgE8Pf6WewX7dIDMKWeeeIFLJls3I3V9JOQ7ThREldc/XLG9nJrLlVPuEd+wVGc/ kA/ce9/fVoM86UPvY50Yo0vdR+V2cFKfgB+OgQzy6hAz3j8dL8c7kh+FRYxESiHNVUu3 N9gg== X-Gm-Message-State: AOAM533pfRuhepH7kl2oGfaazyqBvNoGoiHMj0SqzJDI+2jwc/JvVTrj 7Xw7MURBeLCmJ5Jl+av42f4+9TNiwUw5vKxxnfE3lQ== X-Received: by 2002:a5b:78f:: with SMTP id b15mr20331332ybq.234.1615567635381; Fri, 12 Mar 2021 08:47:15 -0800 (PST) MIME-Version: 1.0 References: <20210312162127.239795-1-alobakin@pm.me> <20210312162127.239795-3-alobakin@pm.me> In-Reply-To: <20210312162127.239795-3-alobakin@pm.me> From: Eric Dumazet Date: Fri, 12 Mar 2021 17:47:04 +0100 Message-ID: Subject: Re: [PATCH net-next 2/4] gro: don't dereference napi->gro_hash[x] multiple times in dev_gro_receive() To: Alexander Lobakin Cc: "David S. Miller" , Jakub Kicinski , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Wei Wang , Cong Wang , Taehee Yoo , netdev , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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, struct sk_buff *skb) > { > u32 bucket = skb_get_hash_raw(skb) & (GRO_HASH_BUCKETS - 1); > + struct gro_list *gro_list = &napi->gro_hash[bucket]; > struct list_head *head = &offload_base; > struct packet_offload *ptype; > __be16 type = skb->protocol; > @@ -6024,7 +6025,7 @@ static enum gro_result dev_gro_receive(struct napi_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 napi_struct *napi, struct sk_buff > if (NAPI_GRO_CB(skb)->flush) > goto normal; > > - if (unlikely(napi->gro_hash[bucket].count >= MAX_GRO_SKBS)) { > + if (unlikely(gro_list->count >= MAX_GRO_SKBS)) { > gro_flush_oldest(napi, gro_head); > } else { > - napi->gro_hash[bucket].count++; > + gro_list->count++; > } > NAPI_GRO_CB(skb)->count = 1; > NAPI_GRO_CB(skb)->age = jiffies; > @@ -6050,7 +6051,7 @@ static enum gro_result dev_gro_receive(struct napi_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.