tjh.dev / kernel
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

docs: tls: Enhance TLS resync async process documentation

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>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/1768298883-1602599-1-git-send-email-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

authored by

Shahar Shitrit and committed by
Jakub Kicinski 8fc80710 e8c6888e

+30
+30
Documentation/networking/tls-offload.rst
··· 318 318 When the header is matched the device sends a confirmation request 319 319 to the kernel, asking if the guessed location is correct (if a TLS record 320 320 really starts there), and which record sequence number the given header had. 321 + 322 + The asynchronous resync process is coordinated on the kernel side using 323 + struct tls_offload_resync_async, which tracks and manages the resync request. 324 + 325 + Helper functions to manage struct tls_offload_resync_async: 326 + 327 + ``tls_offload_rx_resync_async_request_start()`` 328 + Initializes an asynchronous resync attempt by specifying the sequence range to 329 + monitor and resetting internal state in the struct. 330 + 331 + ``tls_offload_rx_resync_async_request_end()`` 332 + Retains the device's guessed TCP sequence number for comparison with current or 333 + future logged ones. It also clears the RESYNC_REQ_ASYNC flag from the resync 334 + request, indicating that the device has submitted its guessed sequence number. 335 + 336 + ``tls_offload_rx_resync_async_request_cancel()`` 337 + Cancels any in-progress resync attempt, clearing the request state. 338 + 339 + When the kernel processes an RX segment that begins a new TLS record, it 340 + examines the current status of the asynchronous resynchronization request. 341 + 342 + If the device is still waiting to provide its guessed TCP sequence number 343 + (the async state), the kernel records the sequence number of this segment so 344 + that it can later be compared once the device's guess becomes available. 345 + 346 + If the device has already submitted its guessed sequence number (the non-async 347 + state), the kernel now tries to match that guess against the sequence numbers of 348 + all TLS record headers that have been logged since the resync request 349 + started. 350 + 321 351 The kernel confirms the guessed location was correct and tells the device 322 352 the record sequence number. Meanwhile, the device had been parsing 323 353 and counting all records since the just-confirmed one, it adds the number