From: Leon Romanovsky <leonro@nvidia.com>
To: Chiachang Wang <chiachangwang@google.com>
Cc: <netdev@vger.kernel.org>, <stanleyjhu@google.com>,
<steffen.klassert@secunet.com>, <yumike@google.com>
Subject: Re: [PATCH ipsec v2 1/1] xfrm: Migrate offload configuration
Date: Sun, 23 Feb 2025 13:21:02 +0200 [thread overview]
Message-ID: <20250223112102.GY53094@unreal> (raw)
In-Reply-To: <20250220073515.3177296-2-chiachangwang@google.com>
On Thu, Feb 20, 2025 at 07:35:15AM +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.
>
> 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"
Please, put changelogs after --- marking, fix kbuild error and resend
the patch as standalone one and not as reply-to previous version.
Thanks
next prev parent reply other threads:[~2025-02-23 11:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-22 12:09 [PATCH ipsec v1 0/2] Update offload configuration with SA Chiachang Wang
2025-01-22 12:09 ` [PATCH ipsec v1 1/2] xfrm: Update offload configuration during SA updates Chiachang Wang
2025-01-22 13:07 ` Leon Romanovsky
2025-01-22 13:08 ` Simon Horman
2025-02-20 7:35 ` [PATCH ipsec v2 0/1] Update offload configuration with SA Chiachang Wang
2025-02-20 7:35 ` [PATCH ipsec v2 1/1] xfrm: Migrate offload configuration Chiachang Wang
2025-02-21 11:02 ` kernel test robot
2025-02-23 11:21 ` Leon Romanovsky [this message]
2025-01-22 12:09 ` [PATCH ipsec v1 2/2] " Chiachang Wang
2025-01-22 13:05 ` Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250223112102.GY53094@unreal \
--to=leonro@nvidia.com \
--cc=chiachangwang@google.com \
--cc=netdev@vger.kernel.org \
--cc=stanleyjhu@google.com \
--cc=steffen.klassert@secunet.com \
--cc=yumike@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.