Re: [PATCH net-next v9 0/5] TLS read_sock performance scalability

On 5/3/26 3:04 AM, Jakub Kicinski wrote:
> On Wed, 29 Apr 2026 17:48:07 -0400 Chuck Lever wrote:
>> I'd like to encourage in-kernel kTLS consumers (i.e., NFS and
>> NVMe/TCP) to coalesce on the use of read_sock. When I suggested
>> this to Hannes, he reported a few performance scalability issues
>> with read_sock. 
> 
> Meaning, this series achieves.. what right now?
> I mean - the headline is "performance scalability" and there's no
> performance testing result in any of the messages :S
> Patch 5 for instance "seems logical" but how much difference does
> it make?

The cover Subject: line has not been changed so all the revisions of
this series can be located easily.

The cover letter makes it clear that the series is now only a clean-up
series. Since async_capable is set to false for TLSv1.3, there is no
performance benefit to these changes, so I don't intend to post a
motivation for it based on performance.


>> However, batch async decryption and its
>> submit/deliver scaffolding were dropped from this series because
>> async_capable is always false for TLS 1.3, the TLS version that
>> NFS and NVMe/TCP both require. Async crypto support for TLS 1.3
>> is a prerequisite for revisiting that work.
>>
>> This series is now only a set of clean-ups. Support for async
>> has been deferred until after TLS KeyUpdate has been merged.
> 
> What does "after TLS KeyUpdate has been merged" mean?
> KeyUpdate is supported.. You mean in NFS? Or in async?

We want to support TLS KeyUpdate in the in-kernel TLS consumers, which
include NFSD, the NFS client, the NVMe/TCP host, and the NVMe/TCP
target. There are two pre-requisites:

1. The in-kernel TLS consumers need to reliably and securely handle TLS
   Alerts. That is coming in the next series I plan to post.

2. The TLS handshake upcall needs to handle KeyUpdate operations. That
   is the series Alistair has been posting since forever, and is waiting
   on getting this series and support for TLS Alerts merged into the
   four in-kernel TLS consumers listed above.


> FTR async support is a major pain and we'd rather get rid of it
> (and switch away from cryto API) than extend it.

That would have been nice to know three months ago when I started work
on this series.

Is there nothing left to do here but drop this series? We'd really like
to get TLS KeyUpdate working for in-kernel TLS consumers, so anything
that can move this process forward is welcome.


-- 
Chuck Lever