Re: [PATCH ipsec-next v4 1/2] xfrm: Migrate offload configuration

[Leon Romanovsky <leon@kernel.org>]

On Mon, Mar 10, 2025 at 09:16:19AM +0000, Chiachang Wang wrote:
> Add hardware offload configuration to XFRM_MSG_MIGRATE
> using an option netlink attribute XFRMA_OFFLOAD_DEV.
> 
> In the existing xfrm_state_migrate(), the xfrm_init_state()
> is called assuming no hardware offload by default. Even the
> original xfrm_state is configured with offload, the setting will
> be reset. If the device is configured with hardware offload,
> it's reasonable to allow the device to maintain its hardware
> offload mode. But the device will end up with offload disabled
> after receiving a migration event when the device migrates the
> connection from one netdev to another one.
> 
> The devices that support migration may work with different
> underlying networks, such as mobile devices. The hardware setting
> should be forwarded to the different netdev based on the
> migration configuration. This change provides the capability
> for user space to migrate from one netdev to another.
> 
> Test: Tested with kernel test in the Android tree located
>       in https://android.googlesource.com/kernel/tests/
>       The xfrm_tunnel_test.py under the tests folder in
>       particular.
> Signed-off-by: Chiachang Wang <chiachangwang@google.com>
> ---
>  v3 -> v4:
>  - Change the target tree to ipsec-next
>  - Rebase commit to adopt updated xfrm_init_state()
>  - Remove redundant variable to rely on validiaty of pointer
>  v2 -> v3:
>  - Modify af_key to fix kbuild error
>  v1 -> v2:
>  - Address review feedback to correct the logic in the
>    xfrm_state_migrate in the migration offload configuration
>    change
>  - Revise the commit message for "xfrm: Migrate offload configuration"
> ---
>  include/net/xfrm.h     |  8 ++++++--
>  net/key/af_key.c       |  2 +-
>  net/xfrm/xfrm_policy.c |  4 ++--
>  net/xfrm/xfrm_state.c  |  9 ++++++++-
>  net/xfrm/xfrm_user.c   | 15 ++++++++++++---
>  5 files changed, 29 insertions(+), 9 deletions(-)
> 

Thanks,
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>