On Mon, Feb 20, 2023 at 04:57:20PM +0000, Dmitry Safonov wrote:
. 

Do you have a timeline for that work?
And if you don't mind I keep re-iterating, as I'm trying to address TCP
reviews and missed functionality/selftests.

I'm hoping to get it ready for the next merge window.
 

1) before your per-request key patches - it's not possible.
2) after your patches - my question would be: "is it better to
kmalloc(GFP_ATOMIC) in RX/TX for every signed TCP segment, rather than
pre-allocate it?"

The price of (2) may just well be negligible, but worth measuring before
switching.

Please keep in mind that you're already performing crypto which
is usually a lot slower than a kmalloc.  In any case, if there is
any optimisation to be done to make the kmalloc faster by using
pools, then that optimisation should go into mm.

Cheers,
-- 
Email: Herbert Xu [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt