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