Re: [PATCH net-next 2/3] docs: net: tls-offload: document tls_dev_del, tls_dev_resync, and rekey
flat view
From: Randy Dunlap <rdunlap@infradead.org>
Date: 2026-06-11 18:13:07
Also in:
bpf, linux-doc
On 6/11/26 10:18 AM, Jakub Kicinski wrote:
quoted hunk ↗ jump to hunk
On Wed, 10 Jun 2026 23:06:44 +0200 Sabrina Dubroca wrote:quoted
quoted
+The third TLS device callback is :c:member:`tls_dev_resync`, called by the core +to synchronize the TCP stream with the record boundaries: + +.. code-block:: c + + int (*tls_dev_resync)(struct net_device *netdev, + struct sock *sk, u32 seq, u8 *rcd_sn, + enum tls_offload_ctx_dir direction); + +See the `Resync handling`_ section for details.Hmm, this callback is not mentioned at all in the "Resync handling" section. I think it'd be good to add at least a quick note there about how/when it's invoked, and what the arguments mean (at least the two types of sequence numbers, since the rest is identical to the other driver CBs).Something like this, you mean?--- a/Documentation/networking/tls-offload.rst +++ b/Documentation/networking/tls-offload.rst@@ -278,9 +278,9 @@ sequence number (as it will be updated from a different context). bool tls_offload_tx_resync_pending(struct sock *sk) Next time ``ktls`` pushes a record it will first send its TCP sequence number -and TLS record number to the driver. Stack will also make sure that -the new record will start on a segment boundary (like it does when -the connection is initially added). +and TLS record number to the driver via the ``tls_dev_resync`` callback. +Stack will also make sure that the new record will start on a segment boundary
Preferably "The stack ..."
quoted hunk ↗ jump to hunk
+(like it does when the connection is initially added). RX --
-- ~Randy