[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZtVs2KwxY8VkvoEr@gauss3.secunet.de>
Date: Mon, 2 Sep 2024 09:44:24 +0200
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Leon Romanovsky <leon@...nel.org>
CC: Feng Wang <wangfe@...gle.com>, <netdev@...r.kernel.org>,
<antony.antony@...unet.com>
Subject: Re: [PATCH] xfrm: add SA information to the offloaded packet
Sorry for the delay. I'm on vacation, so responses will take a bit
longer during the next two weeks.
On Sat, Aug 31, 2024 at 08:39:34PM +0300, Leon Romanovsky wrote:
> On Wed, Aug 28, 2024 at 07:32:47AM +0200, Steffen Klassert wrote:
> > On Thu, Aug 22, 2024 at 01:02:52PM -0700, Feng Wang wrote:
> > > From: wangfe <wangfe@...gle.com>
> > >
> > > In packet offload mode, append Security Association (SA) information
> > > to each packet, replicating the crypto offload implementation.
> > > The XFRM_XMIT flag is set to enable packet to be returned immediately
> > > from the validate_xmit_xfrm function, thus aligning with the existing
> > > code path for packet offload mode.
> > >
> > > This SA info helps HW offload match packets to their correct security
> > > policies. The XFRM interface ID is included, which is crucial in setups
> > > with multiple XFRM interfaces where source/destination addresses alone
> > > can't pinpoint the right policy.
> > >
> > > Signed-off-by: wangfe <wangfe@...gle.com>
> >
> > Applied to ipsec-next, thanks Feng!
>
> Steffen,
>
> What is your position on this patch?
> It is the same patch (logically) as the one that was rejected before?
> https://lore.kernel.org/all/ZfpnCIv+8eYd7CpO@gauss3.secunet.de/
This is an infrastructure patch to support routing based IPsec
with xfrm interfaces. I just did not notice it because it was not
mentioned in the commit message of the first patchset. This should have
been included into the packet offload API patchset, but I overlooked
that xfrm interfaces can't work with packet offload mode. The stack
infrastructure should be complete, so that drivers can implement
that without the need to fix the stack before.
In case the patch has issues, we should fix it.
Powered by blists - more mailing lists