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
| ||
|
Message-ID: <20231202195922.a3ekbrdfgqzfm6al@google.com> Date: Sat, 2 Dec 2023 20:00:56 +0000 From: Shakeel Butt <shakeelb@...gle.com> To: Coco Li <lixiaoyan@...gle.com> 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>, Andrew Lunn <andrew@...n.ch>, Jonathan Corbet <corbet@....net>, David Ahern <dsahern@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org, Chao Wu <wwchao@...gle.com>, Wei Wang <weiwan@...gle.com>, Pradeep Nemavat <pnemavat@...gle.com> Subject: Re: [PATCH v8 net-next 1/5] Documentations: Analyze heavily used Networking related structs On Wed, Nov 29, 2023 at 07:27:52AM +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 unidirectionally. It doesn't include phases other than > TCP_ESTABLISHED, nor does it look at error paths. > > We hope to re-organizing We plan to reorganize? > 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). > > 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 > Is there any hidden meaning behind the capital I and N for Inet_connection_sock and Netns_ipv4? > Note how there isn't much improvement space for inet_sock and > Inet_connection_sock because sk and icsk_inet respectively takes 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 > > Suggested-by: Eric Dumazet <edumazet@...gle.com> > Signed-off-by: Coco Li <lixiaoyan@...gle.com> Reviewed-by: Shakeel Butt <shakeelb@...gle.com> This is really awesome work and motivated me to do something similar for struct mem_cgroup (and or mm structs) as well.
Powered by blists - more mailing lists