netdev - Re: [PATCH net-next 2/3] net: gro: minor optimization for dev_gro

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <07cd64ccacb61cb933bb66af83cb238caf956c96.camel@gmail.com>
Date:   Thu, 03 Feb 2022 08:39:57 -0800
From:   Alexander H Duyck <alexander.duyck@...il.com>
To:     Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Alexander Lobakin <alexandr.lobakin@...el.com>,
        Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH net-next 2/3] net: gro: minor optimization for
 dev_gro_receive()

On Thu, 2022-02-03 at 16:48 +0100, Paolo Abeni wrote:
> While inspecting some perf report, I noticed that the compiler
> emits suboptimal code for the napi CB initialization, fetching
> and storing multiple times the memory for flags bitfield.
> This is with gcc 10.3.1, but I observed the same with older compiler
> versions.
> 
> We can help the compiler to do a nicer work clearing several
> fields at once using an u32 alias. The generated code is quite
> smaller, with the same number of conditional.
> 
> Before:
> objdump -t net/core/gro.o | grep " F .text"
> 0000000000000bb0 l     F .text  0000000000000357 dev_gro_receive
> 
> After:
> 0000000000000bb0 l     F .text  000000000000033c dev_gro_receive
> 
> RFC -> v1:
>  - use __struct_group to delimt the zeroed area (Alexander)
> 
> Signed-off-by: Paolo Abeni <pabeni@...hat.com>
> ---
>  include/net/gro.h | 52 +++++++++++++++++++++++++--------------------
> --
>  net/core/gro.c    | 18 +++++++---------
>  2 files changed, 35 insertions(+), 35 deletions(-)
> 
> diff --git a/include/net/gro.h b/include/net/gro.h
> index 8f75802d50fd..fa1bb0f0ad28 100644
> --- a/include/net/gro.h
> +++ b/include/net/gro.h
> @@ -29,46 +29,50 @@ struct napi_gro_cb {
>         /* Number of segments aggregated. */
>         u16     count;
>  
> -       /* Start offset for remote checksum offload */
> -       u16     gro_remcsum_start;
> +       /* Used in ipv6_gro_receive() and foo-over-udp */
> +       u16     proto;
>  
>         /* jiffies when first packet was created/queued */
>         unsigned long age;
>  
> -       /* Used in ipv6_gro_receive() and foo-over-udp */
> -       u16     proto;
> +       /* portion of the cb set to zero at every gro iteration */
> +       __struct_group(/* no tag */, zeroed, /* no attrs */,

Any specific reason for using __struct_group here rather than the
struct_group macro instead?