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

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?

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.

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
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
[email protected]                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich