[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241107115031.GK5006@unreal>
Date: Thu, 7 Nov 2024 13:50:31 +0200
From: Leon Romanovsky <leon@...nel.org>
To: Antony Antony <antony.antony@...unet.com>
Cc: Feng Wang <wangfe@...gle.com>, netdev@...r.kernel.org,
steffen.klassert@...unet.com
Subject: Re: [PATCH 1/2] xfrm: add SA information to the offloaded packet
On Thu, Nov 07, 2024 at 09:52:09AM +0100, Antony Antony wrote:
> On Wed, Nov 06, 2024 at 16:14:36 -0800, Feng Wang wrote:
> > Antony brought out an important function xfrm_lookup_with_ifid(), this
> > function returns the next dst_entry.
> >
> > The xfrm_lookup_with_ifid() function utilizes xfrm_sk_policy_lookup()
>
> would the output packet, looked up using xfrm_lookup_with_ifid ,
> match xfrm policy with "offload packet" set?
According to my understanding, no.
> When lookup is in the xfrm device.
>
> ip xfrm policy .... offload packet dev <if-name>
>
>
> > to find a matching policy based on the given if_id. The if_id checking
> > is handled in it.
> > Once the policy is found, xfrm_resolve_and_create_bundle() determines
> > the correct Security Association (SA) and associates it with the
> > destination entry (dst->xfrm).
>
> If the output packet got this far, dst is set in skb?
> And when the packet reach the driver dst = skb_dst(skb);
> dst->xfrm is the state?
> If this is the case why add state to skb as your patch proose?
> May be I am missing something in the packet path.
>
> > This SA information is then passed directly to the driver. Since the
> > kernel has already performed the necessary if_id checks for policy,
> > there's no need for the driver to duplicate this effort.
>
> Is this how packet offload would work? My guess was in packet offload
> policy look happens in the driver.
You are right, this is not how packet offload works.
The expectation is that HW sees and catches same selectors as SW.
It ensures that if SW finds policy/SA, HW will find the same.
Thanks
Powered by blists - more mailing lists