ACK: [G/master-next] net/mlx5e: backport kTLS RX support from Linux 5.9

Andrea Righi andrea.righi at canonical.com
Mon Sep 28 13:19:34 UTC 2020


On Mon, Sep 28, 2020 at 11:40:08AM +0200, Paolo Pisati wrote:
> BugLink: https://bugs.launchpad.net/bugs/1895947
> 
> All patches come from linux-next and apply cleanly on top of
> groovy/master-next / v5.8.11 (except for "4517c79f8895 net/mlx5e: kTLS, Add kTLS
> RX HW offload support" that required some context change in one hunk).
> 
> The code changes are limited to the mellanox/mlx5 driver except for these 2 commits
> that apply to net/tls code (in reverse order):
> 
> 1) 0ffec9d5375c 'Revert "net/tls: Add force_resync for driver resync"'
> 
> This commit reverts some opt-in code specifically written for net/mlx5e (quoting
> the commit msg of the reverted commit):
> 
>     This patch adds a field to the tls rx offload context which enables
>     drivers to force a send_resync call.
>     
>     This field can be used by drivers to request a resync at the next
>     possible tls record.
>     ...
>     A following series for mlx5e ConnectX-6DX TLS RX offload support will
>     use this mechanism.
> 
> but since it was never really used, it was reverted upstream and replaced by the
> following commit:
> 
> 2) e4c708607522 'net/tls: Add asynchronous resync'
> 
> that adds a driver asynchronous mechanism to request a resync and is only
> exploited by net/mlx5e - unless a driver is patched to use it, it won't be be
> exercised.

As mentioned by Colin, it is a quite large set of changes. But even with
the 2 net/tls changes, it is all limited to the mellanox driver, so I
don't see any risk of regression. Therefore:

Acked-by: Andrea Righi <andrea.righi at canonical.com>



More information about the kernel-team mailing list