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

2026-05-03, 21:34:01 +0200, Chuck Lever wrote:
> 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.

(not to bikeshed, links to lore also do that)

> 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.

Maybe I misunderstood, but I thought there was a somewhat noticeable
benefit to the "suppress spurious wakeups" patch (not +20%, but at
least improved behavior for some users of kTLS), and maybe the "flush
backlog" one.

Patch 2 may still be beneficial (though it's now mixing 2 separate
changes), and patch 1 is a very reasonable code cleanup.

Patch 4 does feel like a pretty large amount of churn if it has no
observable benefit.


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

(the "don't use crypto API" thing is news to me, that seems to be
trendy these days)

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

I remember discussing this with Jakub, but I don't know if that was
on-list. There's been a lot of bugs in that code.


> We'd really like
> to get TLS KeyUpdate working for in-kernel TLS consumers, so anything
> that can move this process forward is welcome.

But net/tls doesn't need any changes for that, right? net/handshake
maybe, but that's a separate "component" (MAINTAINERS entry).

-- 
Sabrina