[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230215094332.GB9908@breakpoint.cc>
Date: Wed, 15 Feb 2023 10:43:32 +0100
From: Florian Westphal <fw@...len.de>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
pabeni@...hat.com, willemb@...gle.com, fw@...len.de
Subject: Re: [RFC] net: skbuff: let struct skb_ext live inside the head
Jakub Kicinski <kuba@...nel.org> wrote:
> This is a bit more crazy than the previous patch. For drivers
> which already use build_skb() it's relatively easy to add more
> space to the shinfo. Use this approach to place skb_ext inside
> the head. No allocation needed.
>
> This approach is a bit slower in trivial benchmarks than the recycling
> because it requires extra cache line accesses (12.1% loss, ->18.6Gbps).
>
> In-place skb_ext may be shorter than a full skb_ext object.
> The driver only reserves space for exts it may use.
> Any later addition will reallocate the space via CoW,
> abandoning the in-place skb_ext and copying the data to
> a full slab object.
I think the cleaner solution would be to move the new extension ids
into sk_buff itself (at the end, uninitialized data unless used).
Those extensions would always reside there and not in the slab object.
Obviously that only makes sense for extensions where we assume
that typical workload will require them, which might be a hard call to
make.
I concur with Paolo that the napi-caching is nicer/less intrusive,
I think we have to wait and see if it helps with psp (async crypto
needed?) when it lands.
Powered by blists - more mailing lists