All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Coco Li <lixiaoyan@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	Neal Cardwell <ncardwell@google.com>,
	Mubashir Adnan Qureshi <mubashirq@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Andrew Lunn <andrew@lunn.ch>,
	Jonathan Corbet <corbet@lwn.net>,
	David Ahern <dsahern@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	netdev@vger.kernel.org, Chao Wu <wwchao@google.com>,
	Wei Wang <weiwan@google.com>,
	Pradeep Nemavat <pnemavat@google.com>
Subject: Re: [PATCH v7 net-next 1/5] Documentations: Analyze heavily used Networking related structs
Date: Mon, 20 Nov 2023 17:19:59 +0000	[thread overview]
Message-ID: <20231120171959.GC245676@kernel.org> (raw)
In-Reply-To: <20231113233301.1020992-2-lixiaoyan@google.com>

On Mon, Nov 13, 2023 at 11:32:57PM +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 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
> 
> 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, linux_mib
> 
> Signed-off-by: Coco Li <lixiaoyan@google.com>
> Suggested-by: Eric Dumazet <edumazet@google.com>

...

> diff --git a/Documentation/networking/net_cachelines/index.rst b/Documentation/networking/net_cachelines/index.rst
> new file mode 100644
> index 0000000000000..92a6fbe93af35
> --- /dev/null
> +++ b/Documentation/networking/net_cachelines/index.rst
> @@ -0,0 +1,13 @@

Hi Coco,

A minor nit from my side: an SPDX header is probably appropriate at the top
of each .rst file

 
> +===================================
> +Common Networking Struct Cachelines
> +===================================
> +
> +.. toctree::
> +   :maxdepth: 1
> +
> +   inet_connection_sock
> +   inet_sock
> +   net_device
> +   netns_ipv4_sysctl
> +   snmp
> +   tcp_sock

...

  parent reply	other threads:[~2023-11-20 17:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-13 23:32 [PATCH v7 net-next 0/5] Analyze and Reorganize core Networking Structs to optimize cacheline consumption Coco Li
2023-11-13 23:32 ` [PATCH v7 net-next 1/5] Documentations: Analyze heavily used Networking related structs Coco Li
2023-11-15  4:30   ` Jakub Kicinski
2023-11-15  7:07     ` Eric Dumazet
2023-11-15 17:59       ` Coco Li
2023-11-20 17:19   ` Simon Horman [this message]
2023-11-13 23:32 ` [PATCH v7 net-next 2/5] cache: enforce cache groups Coco Li
2023-11-15  4:32   ` Jakub Kicinski
2023-11-13 23:32 ` [PATCH v7 net-next 3/5] netns-ipv4: reorganize netns_ipv4 fast path variables Coco Li
2023-11-13 23:33 ` [PATCH v7 net-next 4/5] net-device: reorganize net_device " Coco Li
2023-11-16 12:39   ` kernel test robot
2023-11-17 19:44     ` Coco Li
2023-11-20 19:41       ` Nathan Chancellor
2023-11-13 23:33 ` [PATCH v7 net-next 5/5] tcp: reorganize tcp_sock " Coco Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231120171959.GC245676@kernel.org \
    --to=horms@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=corbet@lwn.net \
    --cc=daniel@iogearbox.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=lixiaoyan@google.com \
    --cc=mubashirq@google.com \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pnemavat@google.com \
    --cc=weiwan@google.com \
    --cc=wwchao@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.