From: Shahar Shitrit <shshitrit@nvidia.com>

Expand the tls-offload.rst documentation to provide a more detailed
explanation of the asynchronous resync process, including the role
of struct tls_offload_resync_async in managing resync requests on
the kernel side.

Also, add documentation for helper functions
tls_offload_rx_resync_async_request_start/ _end/ _cancel.

Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
 Documentation/networking/tls-offload.rst | 28 ++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/networking/tls-offload.rst b/Documentation/networking/tls-offload.rst
index 7354d48cdf92..6d2769316699 100644
--- a/Documentation/networking/tls-offload.rst
+++ b/Documentation/networking/tls-offload.rst
@@ -318,6 +318,34 @@ is restarted.
 When the header is matched the device sends a confirmation request
 to the kernel, asking if the guessed location is correct (if a TLS record
 really starts there), and which record sequence number the given header had.
+
+The asynchronous resync process is coordinated on the kernel side using
+struct tls_offload_resync_async, which tracks and manages the resync request.
+
+Helper functions to manage struct tls_offload_resync_async:
+
+``tls_offload_rx_resync_async_request_start()``
+Initializes an asynchronous resync attempt by specifying the sequence range to
+monitor and resetting internal state in the struct.
+
+``tls_offload_rx_resync_async_request_end()``
+Retains the device's guessed TCP sequence number for comparison with current or
+future logged ones. It also clears the RESYNC_REQ_ASYNC flag from the resync
+request, indicating that the device has submitted its guessed sequence number.
+
+``tls_offload_rx_resync_async_request_cancel()``
+Cancels any in-progress resync attempt, clearing the request state.
+
+When the kernel processes an RX segment that begins a new TLS record, it
+examines the current status of the asynchronous resynchronization request.
+- If the device is still waiting to provide its guessed TCP sequence number
+  (the async state), the kernel records the sequence number of this segment
+  so that it can later be compared once the device's guess becomes available.
+- If the device has already submitted its guessed sequence number (the non-async
+  state), the kernel now tries to match that guess against the sequence numbers
+  of 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

base-commit: e05021a829b834fecbd42b173e55382416571b2c
-- 
2.31.1

On Tue, Nov 25, 2025 at 09:00:37AM +0200, Tariq Toukan wrote:
> +When the kernel processes an RX segment that begins a new TLS record, it
> +examines the current status of the asynchronous resynchronization request.
> +- If the device is still waiting to provide its guessed TCP sequence number
> +  (the async state), the kernel records the sequence number of this segment
> +  so that it can later be compared once the device's guess becomes available.
> +- If the device has already submitted its guessed sequence number (the non-async
> +  state), the kernel now tries to match that guess against the sequence numbers
> +  of all TLS record headers that have been logged since the resync request
> +  started.
> +

You need to separate the status list:

---- >8 ----
diff --git a/Documentation/networking/tls-offload.rst b/Documentation/networking/tls-offload.rst
index 6d276931669979..a41d02d72e1ee6 100644
--- a/Documentation/networking/tls-offload.rst
+++ b/Documentation/networking/tls-offload.rst
@@ -338,6 +338,7 @@ Cancels any in-progress resync attempt, clearing the request state.
 
 When the kernel processes an RX segment that begins a new TLS record, it
 examines the current status of the asynchronous resynchronization request.
+
 - If the device is still waiting to provide its guessed TCP sequence number
   (the async state), the kernel records the sequence number of this segment
   so that it can later be compared once the device's guess becomes available.

Thanks.

-- 
An old man doll... just what I always wanted! - Clara

On Tue, 25 Nov 2025 09:00:37 +0200 Tariq Toukan wrote:
> Expand the tls-offload.rst documentation to provide a more detailed
> explanation of the asynchronous resync process, including the role
> of struct tls_offload_resync_async in managing resync requests on
> the kernel side.
> 
> Also, add documentation for helper functions
> tls_offload_rx_resync_async_request_start/ _end/ _cancel.

Documentation/networking/tls-offload.rst:342: ERROR: Unexpected indentation.
Documentation/networking/tls-offload.rst:344: WARNING: Block quote ends without a blank line; unexpected unindent.
-- 
pw-bot: cr