netdev - Re: [PATCH v1 net-next 1/5] Documentations: Analyze heavily used Networking related structs

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: <CADjXwji6+OSxZzLoPUKpEHM9VNcN4nm5Lq9LAzU0qO619uk_8Q@mail.gmail.com>
Date: Wed, 20 Sep 2023 23:38:07 -0700
From: Coco Li <lixiaoyan@...gle.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Jakub Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>, 
	Neal Cardwell <ncardwell@...gle.com>, Mubashir Adnan Qureshi <mubashirq@...gle.com>, 
	Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, Chao Wu <wwchao@...gle.com>, 
	Wei Wang <weiwan@...gle.com>
Subject: Re: [PATCH v1 net-next 1/5] Documentations: Analyze heavily used
 Networking related structs

We used 64 bytes for L3_cacheline_size_x86.

We only have arm64 in our testing environment, and we can update some
results on that with the different levels of cache lines on arm64 and
x86.

On Sat, Sep 16, 2023 at 7:36 AM Andrew Lunn <andrew@...n.ch> wrote:
>
> On Sat, Sep 16, 2023 at 01:06:21AM +0000, Coco Li wrote:
> > Analyzed a few structs in the networking stack by looking at variables
> > within them that are used in the TCP/IP fast path.
> >
> > Fast path is defined as TCP path where data is transferred from sender to
> > receiver unidirectionaly. It doesn't include phases other than
> > TCP_ESTABLISHED, nor does it look at error paths.
> >
> > We hope to re-organizing variables that span many cachelines whose fast
> > path variables are also spread out, and this document can help future
> > developers keep networking fast path cachelines small.
> >
> > Optimized_cacheline field is computed as
> > (Fastpath_Bytes/L3_cacheline_size_x86), and not the actual organized
> > results (see patches to come for these).
>
> What value do you use for L3_cacheline_size_x86? What is
> L3_cacheline_size_arm64, L3_cacheline_size_s390, etc.
>
> Do you have any profile data which compares L3 cache misses vs L2, vs
> L1. I guess there should be some gains by changing the order of
> structure members, such that those which are used at a similar time
> are in the same L1 and L2 cache lines, and so only need to be fetched
> once, so reducing cache thrashing.
>
>       Andrew