[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0807165f-3805-4f45-b4f6-893cf8480508@gmail.com>
Date: Mon, 16 Oct 2023 20:46:15 -0700
From: Florian Fainelli <f.fainelli@...il.com>
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>
Subject: Re: [PATCH v2 net-next 0/5] Analyze and Reorganize core Networking
Structs to optimize cacheline consumption
On 10/16/2023 6:47 PM, Coco Li wrote:
> Currently, variable-heavy structs in the networking stack is organized
> chronologically, logically and sometimes by cache line access.
>
> This patch series attempts to reorganize the core networking stack
> variables to minimize cacheline consumption during the phase of data
> transfer. Specifically, we looked at the TCP/IP stack and the fast
> path definition in TCP.
>
> For documentation purposes, we also added new files for each core data
> structure we considered, although not all ended up being modified due
> to the amount of existing cache line they span in the fast path. In
> the documentation, we recorded all variables we identified on the
> fast path and the reasons. We also hope that in the future when
> variables are added/modified, the document can be referred to and
> updated accordingly to reflect the latest variable organization.
This is great stuff, while Eric mentioned this work during Netconf'23
one concern that came up however is how can we make sure that a future
change which adds/removes/shuffles members in those structures is not
going to be detrimental to the work you just did? Is there a way to
"lock" the structure layout to avoid causing performance drops?
I suppose we could use pahole before/after for these structures and
ensure that the layout on a cacheline basis remains preserved, but that
means adding custom scripts to CI.
--
Florian
Powered by blists - more mailing lists