[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230416211221.4650013f@kernel.org>
Date: Sun, 16 Apr 2023 21:12:21 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Pablo Neira Ayuso <pablo@...filter.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
pabeni@...hat.com, fw@...len.de
Subject: Re: [PATCH net-next 4/5] net: skbuff: push nf_trace down the
bitfield
On Sat, 15 Apr 2023 10:31:19 +0200 Pablo Neira Ayuso wrote:
> On Fri, Apr 14, 2023 at 09:01:04AM -0700, Jakub Kicinski wrote:
> > nf_trace is a debug feature, AFAIU, and yet it sits oddly
> > high in the sk_buff bitfield. Move it down, pushing up
> > dst_pending_confirm and inner_protocol_type.
> >
> > Next change will make nf_trace optional (under Kconfig)
> > and all optional fields should be placed after 2b fields
> > to avoid 2b fields straddling bytes.
> >
> > dst_pending_confirm is L3, so it makes sense next to ignore_df.
> > inner_protocol_type goes up just to keep the balance.
>
> Well, yes, this is indeed a debug feature.
>
> But if only one single container enables debugging, this cache line
> will be visited very often. The debugging infrastructure is guarded
> under a static_key, which is global.
I wasn't thinking about cacheline placement, really, although you're
right, under some custom configs it may indeed push the bit from the
second to the third cache line.
The problem is that I can't make the bit optional if it sits this far
up in the bitfield because (as mentioned) 2 bit fields start to
straddle bytes. And that leads to holes.
WiFi is a bit lucky because it has 2 bits and largest fields are also
2b so it can't cause straddling when Kconfig'ed out.
Powered by blists - more mailing lists