Re: [PATCH net-next 09/12] net/mlx5: Compare with old_dest param to modify rule destination

[Leon Romanovsky <leon@kernel.org>]

On Thu, Jul 13, 2023 at 11:05:56AM -0700, Jakub Kicinski wrote:
> On Thu, 13 Jul 2023 20:43:17 +0300 Leon Romanovsky wrote:
> > > Reads like "can't be triggered with current code", in which case 
> > > the right thing to do is to add "can't be triggered with current
> > > code" to the commit message, rather than the Fixes tag.  
> > 
> > The code is wrong, so comes Fixes line, but I can remove it.
> 
> Yes, perhaps after death we will inhabit a world with clear,
> non-conflicting rules, where law can be followed to the letter
> and "truth" and "good" are clearly and objectively defined.
> 
> Until the sweat release, tho, let's apply common sense, and 
> not add Fixes tags to patches which can't possibly be of interest 
> to backporters.
> 
> Please and thank you...

Sure

> 
> > > I had a look thru the series yesterday, and it looks good to me
> > > (tho I'm no ipsec expert). Thanks for putting in the work!
> > > 
> > > Could you add some info about how the code in the series can be
> > > exercised / example configurations? And please CC Simon, it'd be
> > > great to get him / someone at Corigine to review.
> > > 
> > > And obviously Steffen, why did you not CC Steffen?! :o  
> > 
> > It works exactly like "regular" IPsec, nothing special, except
> > now users can switch to switchdev before adding IPsec rules.
> > 
> >  devlink dev eswitch set pci/0000:06:00.0 mode switchdev
> > 
> > Same configurations as here:
> > https://lore.kernel.org/netdev/cover.1670005543.git.leonro@nvidia.com/
> > Packet offload mode:
> >   ip xfrm state offload packet dev <if-name> dir <in|out>
> >   ip xfrm policy .... offload packet dev <if-name>
> > Crypto offload mode:
> >   ip xfrm state offload crypto dev <if-name> dir <in|out>
> > or (backward compatibility)
> >   ip xfrm state offload dev <if-name> dir <in|out>
> 
> I see, so all policy based IPsec?

Yes, it is.

> Does the order of processing in the device match the kernel?

Yes and this it why this fix was needed to make sure that we update
destinations properly.

> TC packet rewrites or IPsec comes first?

In theory, we support any order, but in real life I don't think that TC
before IPsec is really valuable.

> 
> > I didn't add Steffen as it is more flow steering magic series
> > and not IPsec :).
> > 
> > I'll resubmit on Sunday.
> 
> Thanks!