Subject: [PATCH v3 0/8] TLS read_sock performance scalability

From: Chuck Lever <[email-masked]>
Date: Wed, 11 Mar 2026 21:47:56 -0400

From: Chuck Lever <[email-masked]>

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 number of nagging performance
scalability issues with read_sock. This series is an attempt to run
these issues down and get them fixed before we convert the above
sock_recvmsg consumers over to read_sock.

While I assemble performance data, let's nail down the preferred
code structure.

Base commit: 05e059510edf ("Merge branch 'eth-fbnic-add-fbnic-self-tests'")
---

Changes since v2:
- Fix short read self tests

Changes since v1:
- Add C11 reference
- Extend data_ready reduction to recvmsg and splice
- Restructure read_sock and recvmsg using shared helpers

Chuck Lever (8):
  tls: Factor tls_decrypt_async_drain() from recvmsg
  tls: Factor tls_rx_decrypt_record() helper
  tls: Fix dangling skb pointer in tls_sw_read_sock()
  tls: Factor tls_strp_msg_release() from tls_strp_msg_done()
  tls: Suppress spurious saved_data_ready on all receive paths
  tls: Flush backlog before tls_rx_rec_wait in read_sock
  tls: Restructure tls_sw_read_sock() into submit/deliver phases
  tls: Enable batch async decryption in read_sock

 net/tls/tls.h      |   3 +-
 net/tls/tls_strp.c |  34 ++++++--
 net/tls/tls_sw.c   | 213 ++++++++++++++++++++++++++++++++-------------
 3 files changed, 184 insertions(+), 66 deletions(-)

-- 
2.52.0