[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230714121633.18d19c4c@kernel.org>
Date: Fri, 14 Jul 2023 12:16:33 -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 21:40:13 +0300 Leon Romanovsky wrote:
> > > In theory, we support any order, but in real life I don't think that TC
> > > before IPsec is really valuable.
> >
> > I asked the question poorly. To clearer, you're saying that:
> >
> > a) host <-> TC <-> IPsec <-> "wire"/switch
> > or
> > b) host <-> IPsec <-> TC <-> "wire"/switch
> >
> > ?
>
> 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? So can we reject a) from happening? 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.
Powered by blists - more mailing lists