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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ