Gh0st
/
linux
mirror of https://github.com/torvalds/linux.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Documentation: tls_offload: fix typos and grammar 

Fix typos and grammar where it improves readability.

Signed-off-by: Leo Stone <leocstone@gmail.com>
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
Link: https://patch.msgid.link/20241124230002.56058-1-leocstone@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
This commit is contained in:
Leo Stone 2024-11-24 15:00:02 -08:00 committed by Paolo Abeni
parent 6e33123a18
commit 04f5cb4899
1 changed files with 15 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
Documentation/networking/tls-offload.rst
View File

@ -51,7 +51,7 @@ and send them to the device for encryption and transmission.
RX RX
-- --
On the receive side if the device handled decryption and authentication On the receive side, if the device handled decryption and authentication
successfully, the driver will set the decrypted bit in the associated successfully, the driver will set the decrypted bit in the associated
:c:type:`struct sk_buff <sk_buff>`. The packets reach the TCP stack and :c:type:`struct sk_buff <sk_buff>`. The packets reach the TCP stack and
are handled normally. ``ktls`` is informed when data is queued to the socket are handled normally. ``ktls`` is informed when data is queued to the socket
@ -120,8 +120,9 @@ before installing the connection state in the kernel.
RX RX
-- --
In RX direction local networking stack has little control over the segmentation, In the RX direction, the local networking stack has little control over
so the initial records' TCP sequence number may be anywhere inside the segment. segmentation, so the initial records' TCP sequence number may be anywhere
inside the segment.
Normal operation Normal operation
================ ================
@ -138,8 +139,8 @@ There are no guarantees on record length or record segmentation. In particular
segments may start at any point of a record and contain any number of records. segments may start at any point of a record and contain any number of records.
Assuming segments are received in order, the device should be able to perform Assuming segments are received in order, the device should be able to perform
crypto operations and authentication regardless of segmentation. For this crypto operations and authentication regardless of segmentation. For this
to be possible device has to keep small amount of segment-to-segment state. to be possible, the device has to keep a small amount of segment-to-segment
This includes at least: state. This includes at least:
* partial headers (if a segment carried only a part of the TLS header) * partial headers (if a segment carried only a part of the TLS header)
* partial data block * partial data block
@ -175,12 +176,12 @@ and packet transformation functions) the device validates the Layer 4
checksum and performs a 5-tuple lookup to find any TLS connection the packet checksum and performs a 5-tuple lookup to find any TLS connection the packet
may belong to (technically a 4-tuple may belong to (technically a 4-tuple
lookup is sufficient - IP addresses and TCP port numbers, as the protocol lookup is sufficient - IP addresses and TCP port numbers, as the protocol
is always TCP). If connection is matched device confirms if the TCP sequence is always TCP). If the packet is matched to a connection, the device confirms
number is the expected one and proceeds to TLS handling (record delineation, if the TCP sequence number is the expected one and proceeds to TLS handling
decryption, authentication for each record in the packet). The device leaves (record delineation, decryption, authentication for each record in the packet).
the record framing unmodified, the stack takes care of record decapsulation. The device leaves the record framing unmodified, the stack takes care of record
Device indicates successful handling of TLS offload in the per-packet context decapsulation. Device indicates successful handling of TLS offload in the
(descriptor) passed to the host. per-packet context (descriptor) passed to the host.
Upon reception of a TLS offloaded packet, the driver sets Upon reception of a TLS offloaded packet, the driver sets
the :c:member:`decrypted` mark in :c:type:`struct sk_buff <sk_buff>` the :c:member:`decrypted` mark in :c:type:`struct sk_buff <sk_buff>`
@ -439,7 +440,7 @@ by the driver:
* ``rx_tls_resync_req_end`` - number of times the TLS async resync request * ``rx_tls_resync_req_end`` - number of times the TLS async resync request
properly ended with providing the HW tracked tcp-seq. properly ended with providing the HW tracked tcp-seq.
* ``rx_tls_resync_req_skip`` - number of times the TLS async resync request * ``rx_tls_resync_req_skip`` - number of times the TLS async resync request
procedure was started by not properly ended. procedure was started but not properly ended.
* ``rx_tls_resync_res_ok`` - number of times the TLS resync response call to * ``rx_tls_resync_res_ok`` - number of times the TLS resync response call to
the driver was successfully handled. the driver was successfully handled.
* ``rx_tls_resync_res_skip`` - number of times the TLS resync response call to * ``rx_tls_resync_res_skip`` - number of times the TLS resync response call to
@ -507,8 +508,8 @@ in packets as seen on the wire.
Transport layer transparency Transport layer transparency
---------------------------- ----------------------------
The device should not modify any packet headers for the purpose For the purpose of simplifying TLS offload, the device should not modify any
of the simplifying TLS offload. packet headers.
The device should not depend on any packet headers beyond what is strictly The device should not depend on any packet headers beyond what is strictly
necessary for TLS offload. necessary for TLS offload.