[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230714203032.7f1bf5f7@kernel.org>
Date: Fri, 14 Jul 2023 20:30:32 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Leon Romanovsky <leon@...nel.org>
Cc: Saeed Mahameed <saeedm@...dia.com>, Jianbo Liu <jianbol@...dia.com>,
Eric Dumazet <edumazet@...gle.com>, Mark Bloch <mbloch@...dia.com>,
netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>, "David S . Miller"
<davem@...emloft.net>, Simon Horman <simon.horman@...igine.com>
Subject: Re: [PATCH net-next 09/12] net/mlx5: Compare with old_dest param to
modify rule destination
On Fri, 14 Jul 2023 23:32:58 +0300 Leon Romanovsky wrote:
> On Fri, Jul 14, 2023 at 12:16:33PM -0700, Jakub Kicinski wrote:
> > On Fri, 14 Jul 2023 21:40:13 +0300 Leon Romanovsky wrote:
> > > It depends on configuration order, if user configures TC first, it will
> > > be a), if he/she configures IPsec first, it will be b).
> > >
> > > I just think that option b) is really matters.
> >
> > And only b) matches what happens in the kernel with policy based IPsec,
> > right?
>
> Can you please clarify what do you mean "policy based IPsec"?
I mean without a separate xfrm netdev on which you can install TC
rules of its own.
> > IIUC what you're saying -
> > the result depending on order of configuration may be a major source
> > of surprises / hard to debug problems for the user.
>
> When I reviewed patches, I came exactly to an opposite conclusion :)
>
> My rationale was that users who configure IPsec and TC are advanced
> users who knows their data flow and if they find a) option valuable,
> they can do it.
>
> For example, a) allows to limit amount of data sent to IPsec engine.
>
> I believe both a) and b) should be supported.
What does it take to switch between the modes?
Even if we want both modes we should have an explicit switch, I reckon.
Or at least a way to read back what mode we ended up in.
Powered by blists - more mailing lists