Lines Matching +full:sync +full:- +full:on +full:- +full:green +full:- +full:active
1 .. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
13 For details regarding the user-facing interface refer to the TLS
18 * Software crypto mode (``TLS_SW``) - CPU handles the cryptography.
20 can be used, but depending on calling context CPU may utilize
22 latency on socket reads (decryption only starts when a read syscall
23 is made) and additional I/O load on the system.
24 * Packet-based NIC offload mode (``TLS_HW``) - the NIC handles crypto
25 on a packet by packet basis, provided the packets arrive in order.
28 (``ethtool`` flags ``tls-hw-tx-offload`` and ``tls-hw-rx-offload``).
29 * Full TCP NIC offload mode (``TLS_HW_RECORD``) - mode of operation where
33 abilities or QoS and packet scheduling (``ethtool`` flag ``tls-hw-record``).
35 The operation mode is selected automatically based on device configuration,
36 offload opt-in or opt-out on per-connection basis is not currently supported.
39 --
44 point on the TCP stack proceeds as normal.
48 for crypto offload based on the socket the packet is attached to,
52 --
54 On the receive side, if the device handled decryption and authentication
63 .. kernel-figure:: tls-offload-layers.svg
79 When TLS cryptographic connection state is installed on a ``ktls`` socket
82 network device is offload-capable and attempts the offload. In case offload
89 .. code-block:: c
98 to retrieve the connection 5-tuple and socket family (IPv4 vs IPv6).
108 --
121 --
138 There are no guarantees on record length or record segmentation. In particular
142 to be possible, the device has to keep a small amount of segment-to-segment
155 --
164 a connection identifier (note that a 5-tuple lookup is insufficient to identify
172 --
176 checksum and performs a 5-tuple lookup to find any TLS connection the packet
177 may belong to (technically a 4-tuple
178 lookup is sufficient - IP addresses and TCP port numbers, as the protocol
184 per-packet context (descriptor) passed to the host.
189 and non-decrypted segments do not get coalesced (e.g. by GRO or socket layer)
206 --
208 Segments transmitted from an offloaded socket can get out of sync
209 in similar ways to the receive side-retransmissions - local drops
225 In this mode depending on the implementation the driver can either ask
228 with the previous stream state - assuming that the out of order segment
233 Next record sync
240 may imply a local drop, the driver asks the stack to sync the device
245 .. code-block:: c
253 .. code-block:: c
259 the new record will start on a segment boundary (like it does when
263 --
269 .. kernel-figure:: tls-offload-reorder-good.svg
270 :alt: reorder of non-header segment
273 Reorder of non-header segment
275 Green segments are successfully decrypted, blue ones are passed
276 as received on wire, red stripes mark start of new records.
280 the next record starts inside 3, based on record length in segment 1.
288 spanning segments 1, 2 and 3. The device did not get out of sync,
294 .. kernel-figure:: tls-offload-reorder-bad.svg
308 When the device gets out of sync and the stream reaches TCP sequence
314 (based on the length fields at guessed locations).
323 and counting all records since the just-confirmed one, it adds the number
325 At this point the device is in sync and can resume decryption at next
331 restart scan. Given how unlikely falsely-matching stream is, however,
338 Stack-driven resynchronization
358 --
368 Any device TLS offload handling error on the transmission side must result
374 --
376 If the device encounters any problems with TLS offload on the receive
378 received on the wire.
385 to the host's stack as it was on the wire (recovering original packet in the
388 The Linux networking stack does not provide a way of reporting per-packet
409 --------------------
415 -------------------------------
417 Offload performance may depend on segment and record size.
420 significant performance impact on non-offloaded streams.
425 Following minimum set of TLS-related statistics should be reported
428 * ``rx_tls_decrypted_packets`` - number of successfully decrypted RX packets
430 * ``rx_tls_decrypted_bytes`` - number of TLS payload bytes in RX packets
432 * ``rx_tls_ctx`` - number of TLS RX HW offload contexts added to device for
434 * ``rx_tls_del`` - number of TLS RX HW offload contexts deleted from device
436 * ``rx_tls_resync_req_pkt`` - number of received TLS packets with a resync
438 * ``rx_tls_resync_req_start`` - number of times the TLS async resync request
440 * ``rx_tls_resync_req_end`` - number of times the TLS async resync request
441 properly ended with providing the HW tracked tcp-seq.
442 * ``rx_tls_resync_req_skip`` - number of times the TLS async resync request
444 * ``rx_tls_resync_res_ok`` - number of times the TLS resync response call to
446 * ``rx_tls_resync_res_skip`` - number of times the TLS resync response call to
448 * ``rx_tls_err`` - number of RX packets which were part of a TLS stream
450 * ``tx_tls_encrypted_packets`` - number of TX packets passed to the device
452 * ``tx_tls_encrypted_bytes`` - number of TLS payload bytes in TX packets
454 * ``tx_tls_ctx`` - number of TLS TX HW offload contexts added to device for
456 * ``tx_tls_ooo`` - number of TX packets which were part of a TLS stream
458 * ``tx_tls_skip_no_sync_data`` - number of TX packets which were part of
459 a TLS stream and arrived out-of-order, but skipped the HW offload routine
462 * ``tx_tls_drop_no_sync_data`` - number of TX packets which were part of
465 * ``tx_tls_drop_bypass_req`` - number of TX packets which were part of a TLS
474 5-tuple matching limitations
475 ----------------------------
477 The device can only recognize received packets based on the 5-tuple
482 any intermediate software device, therefore a 5-tuple match may
488 ------------
495 ---------------
502 -----------------------------------------------------
506 in packets as seen on the wire.
509 ----------------------------
514 The device should not depend on any packet headers beyond what is strictly
518 -------------
523 on TCP retransmissions to handle corner cases is not acceptable.
526 -------------------
531 offloads, old connections will remain active after flags are cleared.
538 Similarly, device-offloaded TLS decryption implies doing RXCSUM. If the user