Re: [PATCH net-next 2/3] docs: net: tls-offload: document tls_dev_del, tls_dev_resync, and rekey

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 10 Jun 2026 23:06:44 +0200 Sabrina Dubroca wrote:
> > +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
+(like it does when the connection is initially added).
 
 RX
 --
@@ -372,9 +372,10 @@ all TLS record headers that have been logged since the resync request
 started.
 
 The kernel confirms the guessed location was correct and tells the device
-the record sequence number. Meanwhile, the device had been parsing
-and counting all records since the just-confirmed one, it adds the number
-of records it had seen to the record number provided by the kernel.
+the record sequence number via the ``tls_dev_resync`` callback. Meanwhile,
+the device had been parsing and counting all records since the just-confirmed
+one, it adds the number of records it had seen to the record number provided
+by the kernel.
 At this point the device is in sync and can resume decryption at next
 segment boundary.
 
@@ -398,7 +399,8 @@ schedules resynchronization after it has received two completely encrypted
 records.
 
 The stack waits for the socket to drain and informs the device about
-the next expected record number and its TCP sequence number. If the
+the next expected record number and its TCP sequence number via the
+``tls_dev_resync`` callback. If the
 records continue to be received fully encrypted stack retries the
 synchronization with an exponential back off (first after 2 encrypted
 records, then after 4 records, after 8, after 16... up until every