On 2/21/23 02:43, Herbert Xu wrote:

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

quoted

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.

Nice! I'll mark this 1/21 patch as [draft], mentioning your work as it
will need to be re-made using per-request keys.
Still, I will keep iterating TCP-AO patches set during 6.3 RCs in order
to get more reviews/suggestions related to TCP changes.

quoted

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.

Fair point. Probably, kmalloc() is negligible. I'll measure as I have a
patch for iperf for TCP-MD5/TCP-AO measurements.

Thanks,
          Dmitry