netdev - Re: [PATCH v2 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: <87y1g1b8jw.fsf@meer.lwn.net>
Date: Tue, 17 Oct 2023 08:57:55 -0600
From: Jonathan Corbet <corbet@....net>
To: Coco Li <lixiaoyan@...gle.com>, 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>
Cc: netdev@...r.kernel.org, Chao Wu <wwchao@...gle.com>, Wei Wang
 <weiwan@...gle.com>, Coco Li <lixiaoyan@...gle.com>
Subject: Re: [PATCH v2 net-next 1/5] Documentations: Analyze heavily used
 Networking related structs

Coco Li <lixiaoyan@...gle.com> writes:

> 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).
>
> Note that the optimization is not cache line size dependent, we use
> x86 as an example of improvements.
>
> Investigation is done on 6.5
>
> Name	                Struct_Cachelines  Cur_fastpath_cache Fastpath_Bytes Optimized_cacheline
> tcp_sock	        42 (2664 Bytes)	   12   		396		8
> net_device	        39 (2240 bytes)	   12			234		4
> inet_sock	        15 (960 bytes)	   14			922		14
> Inet_connection_sock	22 (1368 bytes)	   18			1166		18
> Netns_ipv4 (sysctls)	12 (768 bytes)     4			77		2
> linux_mib	        16 (1060)	   6			104		2
>
> Note how there isn't much improvement space for inet_sock and
> Inet_connection_sock because sk and icsk_inet respective take up so
> much of the struct that rest of the variables become a small portion of
> the struct size.
>
> So, we decided to reorganize tcp_sock, net_device, Netns_ipv4, linux_mib
>
> Signed-off-by: Coco Li <lixiaoyan@...gle.com>
> Suggested-by: Eric Dumazet <edumazet@...gle.com>
> ---
>  .../net_cachelines/inet_connection_sock.rst   |  42 +++++
>  .../networking/net_cachelines/inet_sock.rst   |  37 ++++
>  .../networking/net_cachelines/net_device.rst  | 167 ++++++++++++++++++
>  .../net_cachelines/netns_ipv4_sysctl.rst      | 151 ++++++++++++++++
>  .../networking/net_cachelines/snmp.rst        | 128 ++++++++++++++
>  .../networking/net_cachelines/tcp_sock.rst    | 148 ++++++++++++++++

So none of this changelog tells us anything about this documentation you
are adding or what readers are supposed to gain from it.  What are these
files?

What they are *not* is RST; you clearly have not tried a documentation
build with these files in place.  I would say that needs to be fixed,
but I do wonder if this kind of information (to the extent that I
understand what it is) isn't better placed in the source itself?  If
nothing else, I would expect it to have a somewhat higher chance of
staying current that way.

Thanks,

jon