Lines Matching +full:virtual +full:- +full:wire +full:- +full:mode
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.
24 * Packet-based NIC offload mode (``TLS_HW``) - the NIC handles crypto
26 This mode integrates best with the kernel stack and is described in detail
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 --
43 mode) and then hands the modified scatter list to the TCP layer. From this
46 In ``TLS_HW`` mode the encryption is not performed in the TLS ULP.
52 --
63 .. kernel-figure:: tls-offload-layers.svg
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 --
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)
200 added to the device table and are in TLS_HW mode. For example,
206 --
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
245 .. code-block:: c
253 .. code-block:: c
263 --
269 .. kernel-figure:: tls-offload-reorder-good.svg
270 :alt: reorder of non-header segment
273 Reorder of non-header segment
276 as received on wire, red stripes mark start of new records.
294 .. kernel-figure:: tls-offload-reorder-bad.svg
323 and counting all records since the just-confirmed one, it adds the number
331 restart scan. Given how unlikely falsely-matching stream is, however,
338 Stack-driven resynchronization
343 If the connection is configured in this mode the stack automatically
358 --
374 --
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 -------------------------------
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
480 or virtual networking. However, many packet transformations performed
482 any intermediate software device, therefore a 5-tuple match may
488 ------------
495 ---------------
502 -----------------------------------------------------
506 in packets as seen on the wire.
509 ----------------------------
518 -------------
526 -------------------
538 Similarly, device-offloaded TLS decryption implies doing RXCSUM. If the user