Re: [RFC PATCH 1/4] net: Introduce read_sock_cmsg proto_ops for control message delivery

On 2/18/26 2:29 AM, Hannes Reinecke wrote:
> On 2/17/26 23:20, Chuck Lever wrote:
>> From: Chuck Lever <[email protected]>
>>
>> Kernel TCP consumers that use the read_sock interface
>> (proto_ops.read_sock) cannot receive TLS control messages (Alerts,
>> Handshake records) when kTLS is active. The current
>> tls_sw_read_sock() method rejects non-data records with -EINVAL, and
>> the sk_read_actor_t callback has no channel for delivering record-
>> type metadata.
>>
>> Four kernel subsystems are affected: NFSD (sunrpc svcsock), NFS
>> client (sunrpc xprtsock), NVMe target (nvmet-tcp), and NVMe host
>> (nvme-tcp). Each of these either falls back to the slower
>> sock_recvmsg() API or lacks TLS alert handling entirely.
>>
> And that is the contentious topic.
> Is it really slower?

I measured 5-10% throughput increases and latency drops with NFSD,
/without/ TLS. The primary benefit of this series is that it handles
CMSG (TLS Alerts) much more cleanly.


> The way I see it, ->read_sock() has an advantage when you can work
> with skbuffs (ie network packets) directly. Then it has the benefit
> of being paced with the packets arriving as they do on the network.
> 
> But for TLS this is no longer true; the TLS skbuffs are synthesized
> on top of the TCP stream, and the boundary of a TLS skbuff is completely
> decoupled from the TCP skbuff (in theory, at least).
> 
> This can result in TLS skbuff stalls when waiting for the remainder
> of the TCP data stream to arrive.

An entire TLS Record has to be present before it can be decrypted and
passed to the socket consumer. Is that what you mean?


> So for TLS I _think_ it's beneficial to use recvmsg, as there you have
> the full set of options available.
> 
> And actually I have a patch switching nvme over to recvmsg(), but that
> has stalled due to precisely this question: read_sock() inherently
> faster than recvmsg? Or is that just the perception (we are closer
> to the hardware, so it _must_ be faster)?
> 
> (Speaking as the author of the ->read_sock() callback for TLS.
> I never really liked it ;-)
> 
> Cheers,
> 
> Hannes


-- 
Chuck Lever