[v3,net-next,00/19] TLS offload rx, netdev & mlx5

Hi,

The following series provides TLS RX inline crypto offload.

v2->v3:
    - Fix typo
    - Adjust cover letter
    - Fix bug in zero copy flows
    - Use network byte order for the record number in resync
    - Adjust the sequence provided in resync

v1->v2:
    - Fix bisectability problems due to variable name changes
    - Fix potential uninitialized return value

This series completes the generic infrastructure to offload TLS crypto to
a network devices. It enables the kernel TLS socket to skip decryption and
authentication operations for SKBs marked as decrypted on the receive
side of the data path. Leaving those computationally expensive operations
to the NIC.

This infrastructure doesn't require a TCP offload engine. Instead, the
NIC decrypts a packet's payload if the packet contains the expected TCP
sequence number. The TLS record authentication tag remains unmodified
regardless of decryption. If the packet is decrypted successfully and it
contains an authentication tag, then the authentication check has passed.
Otherwise, if the authentication fails, then the packet is provided
unmodified and the KTLS layer is responsible for handling it.
Out-Of-Order TCP packets are provided unmodified. As a result,
in the slow path some of the SKBs are decrypted while others remain as
ciphertext.

The GRO and TCP layers must not coalesce decrypted and non-decrypted SKBs. 
At the worst case a received TLS record consists of both plaintext
and ciphertext packets. These partially decrypted records must be
reencrypted, only to be decrypted.

The notable differences between SW KTLS and NIC offloaded TLS
implementations are as follows:
1. Partial decryption - Software must handle the case of a TLS record
that was only partially decrypted by HW. This can happen due to packet
reordering.
2. Resynchronization - tls_read_size calls the device driver to
resynchronize HW whenever it lost track of the TLS record framing in
the TCP stream.

The infrastructure should be extendable to support various NIC offload
implementations.  However it is currently written with the
implementation below in mind:
The NIC identifies packets that should be offloaded according to
the 5-tuple and the TCP sequence number. If these match and the
packet is decrypted and authenticated successfully, then a syndrome
is provided to software. Otherwise, the packet is unmodified.
Decrypted and non-decrypted packets aren't coalesced by the network stack,
and the KTLS layer decrypts and authenticates partially decrypted records.
The NIC provides an indication whenever a resync is required. The resync
operation is triggered by the KTLS layer while parsing TLS record headers.

Finally, we measure the performance obtained by running single stream
iperf with two Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz machines connected
back-to-back with Innova TLS (40Gbps) NICs. We compare TCP (upper bound)
and KTLS-Offload running both in Tx and Rx. The results show that the
performance of offload is comparable to TCP.

                          | Bandwidth (Gbps) | CPU Tx (%) | CPU rx (%)
TCP                       | 28.8             | 5          | 12
KTLS-Offload-Tx-Rx 	  | 28.6	     | 7          | 14

Paper: https://netdevconf.org/2.2/papers/pismenny-tlscrypto-talk.pdf



Boris Pismenny (18):
  net: Add decrypted field to skb
  net: Add TLS rx resync NDO
  tcp: Don't coalesce decrypted and encrypted SKBs
  tls: Refactor tls_offload variable names
  tls: Split decrypt_skb to two functions
  tls: Split tls_sw_release_resources_rx
  tls: Fill software context without allocation
  tls: Add rx inline crypto offload
  tls: Fix zerocopy_from_iter iov handling
  net/mlx5e: TLS, refactor variable names
  net/mlx5: Accel, add TLS rx offload routines
  net/mlx5e: TLS, add innova rx support
  net/mlx5e: TLS, add Innova TLS rx data path
  net/mlx5e: TLS, add software statistics
  net/mlx5e: TLS, build TLS netdev from capabilities
  net/mlx5: Accel, add common metadata functions
  net/mlx5e: IPsec, fix byte count in CQE
  net/mlx5e: Kconfig, mutually exclude compilation of TLS and IPsec
    accel

Ilya Lesokhin (1):
  net: Add TLS RX offload feature

 drivers/net/ethernet/mellanox/mlx5/core/Kconfig    |   1 +
 .../net/ethernet/mellanox/mlx5/core/accel/accel.h  |  37 +++
 .../net/ethernet/mellanox/mlx5/core/accel/tls.c    |  23 +-
 .../net/ethernet/mellanox/mlx5/core/accel/tls.h    |  26 +-
 .../mellanox/mlx5/core/en_accel/ipsec_rxtx.c       |  20 +-
 .../mellanox/mlx5/core/en_accel/ipsec_rxtx.h       |   2 +-
 .../net/ethernet/mellanox/mlx5/core/en_accel/tls.c |  69 +++--
 .../net/ethernet/mellanox/mlx5/core/en_accel/tls.h |  33 ++-
 .../mellanox/mlx5/core/en_accel/tls_rxtx.c         | 117 +++++++-
 .../mellanox/mlx5/core/en_accel/tls_rxtx.h         |   3 +
 drivers/net/ethernet/mellanox/mlx5/core/en_rx.c    |   8 +-
 drivers/net/ethernet/mellanox/mlx5/core/fpga/tls.c | 113 ++++++--
 drivers/net/ethernet/mellanox/mlx5/core/fpga/tls.h |  18 +-
 include/linux/mlx5/mlx5_ifc_fpga.h                 |   1 +
 include/linux/netdev_features.h                    |   2 +
 include/linux/netdevice.h                          |   2 +
 include/linux/skbuff.h                             |   7 +-
 include/net/tls.h                                  |  82 +++++-
 net/core/ethtool.c                                 |   1 +
 net/core/skbuff.c                                  |   6 +
 net/ipv4/tcp_input.c                               |  12 +
 net/ipv4/tcp_offload.c                             |   3 +
 net/tls/tls_device.c                               | 301 ++++++++++++++++++---
 net/tls/tls_device_fallback.c                      |   9 +-
 net/tls/tls_main.c                                 |  32 ++-
 net/tls/tls_sw.c                                   | 103 ++++---
 26 files changed, 843 insertions(+), 188 deletions(-)
 create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/accel/accel.h

On 07/11/18 10:54 PM, Boris Pismenny wrote:
> Hi,
> 
> The following series provides TLS RX inline crypto offload.

All the tls patches look good to me except #10

"tls: Fix zerocopy_from_iter iov handling"

which seems to break the non-device zerocopy flow. 

The integration is very clean, thanks!

> 
> v2->v3:
>     - Fix typo
>     - Adjust cover letter
>     - Fix bug in zero copy flows
>     - Use network byte order for the record number in resync
>     - Adjust the sequence provided in resync
> 
> v1->v2:
>     - Fix bisectability problems due to variable name changes
>     - Fix potential uninitialized return value
>

Hi Dave,

On 7/12/2018 12:54 PM, Dave Watson wrote:
> On 07/11/18 10:54 PM, Boris Pismenny wrote:
>> Hi,
>>
>> The following series provides TLS RX inline crypto offload.
> 
> All the tls patches look good to me except #10
> 
> "tls: Fix zerocopy_from_iter iov handling"
> 
> which seems to break the non-device zerocopy flow.

Thanks for reviewing!

Sorry, it seems to break the zerocopy send flow, and I've tested only 
with the receive flow offload disabled.

I'll fix it in v4. I think that adding a flag to indicate whether a 
revert is needed should do the trick. In the receive flow the revert is 
needed to handle potential errors, while in the transmit flow it needs 
to be removed.

> 
> The integration is very clean, thanks!	
> 
>>
>> v2->v3:
>>      - Fix typo
>>      - Adjust cover letter
>>      - Fix bug in zero copy flows
>>      - Use network byte order for the record number in resync
>>      - Adjust the sequence provided in resync
>>
>> v1->v2:
>>      - Fix bisectability problems due to variable name changes
>>      - Fix potential uninitialized return value
>>