Re: [PATCH xfrm-next v7 6/8] xfrm: speed-up lookup of HW policies

[Leon Romanovsky <leon@kernel.org>]

On Mon, Nov 21, 2022 at 10:44:04AM +0100, Steffen Klassert wrote:
> On Sun, Nov 20, 2022 at 09:17:02PM +0200, Leon Romanovsky wrote:
> > On Fri, Nov 18, 2022 at 11:49:07AM +0100, Steffen Klassert wrote:
> > > On Thu, Nov 17, 2022 at 02:51:33PM +0200, Leon Romanovsky wrote:
> > > > On Thu, Nov 17, 2022 at 01:12:43PM +0100, Steffen Klassert wrote:
> > > > > On Wed, Nov 09, 2022 at 02:54:34PM +0200, Leon Romanovsky wrote:
> > > > > > From: Leon Romanovsky <leonro@nvidia.com>
> > > > 
> > > > > So this raises the question how to handle acquires with this packet
> > > > > offload. 
> > > > 
> > > > We handle acquires as SW policies and don't offload them.
> > > 
> > > We trigger acquires with states, not policies. The thing is,
> > > we might match a HW policy but create a SW acquire state.
> > > This will not match anymore as soon as the lookup is
> > > implemented correctly.
> > 
> > For now, all such packets will be dropped as we have offlaoded
> > policy but not SA.
> 
> I think you missed my point. If the HW policy does not match
> the SW acquire state, then each packet will geneate a new
> acquire. So you need to make sure that policy and acquire
> state will match to send the acquire just once to userspace.

I think that I'm still missing the point.

We require both policy and SA to be offloaded. It means that once
we hit HW policy, we must hit SA too (at least this is how mlx5 part
is implemented).

If it doesn't hit HW policy, it means that whole path is not offloaded,
so no harm will be if we create SW SA for this path.

> 
> > > > It is not different from any other kernel code, bugs will be fixed.
> > > 
> > > The thing that is different here is, that the concept is already
> > > broken. We can't split the datapath to be partially handled in
> > > SW and HW in any sane way, this becomes clearer and clearer.
> > > 
> > > The full protocol offload simply does not fit well into HW,
> > > but we try to make it fit with a hammer. This is the problem
> > > why I do not really like this, and is also the reason why this
> > > is still not merged. We might be much better of by doing a
> > > HW frindly redesign of the protocol and offload this then.
> > > But, yes that takes time and will have issues too.
> > 
> > When you say "protocol", what do you mean? Many users, who have
> > deployed IPsec solutions, just want to have same look and feel
> > but much faster.
> > 
> > I truly believe that this packet offload fits SW model and the
> > (small) amount of changes supports it. There are almost no changes
> > to the stack to natively support this offload.
> > 
> > As long as HW involved, you will never have solution without issues,
> > and like you said even redesign "will have issues".
> 
> Things would be much easier, if we don't need to add HW policies
> and states to SW databases. But yes, a redesign might have issues
> too. That's why we are still working on the current soluion :)
> 

There will be PSP for that, but it is not IPsec.

Thanks