From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id E868939D
	for <netdev@vger.kernel.org>; Sat, 15 Jul 2023 03:30:34 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id F22F8C433C7;
	Sat, 15 Jul 2023 03:30:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1689391834;
	bh=DWsqbFGqlQkWiN3wTuwoj3FiFB1c6adxvrlx+u0V9z8=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=mNx4QujSl1BRlFLz86XYN+lZFZ1RJfm3CJ4qdWhjyD0wdExI0133VxDyDpYeU9MY6
	 aCmaf9rYvtHd5ChAXGA1ED6l460ByFQLX6HRPVYJmQrNSM84mTebXzAtmzP0y/Qmps
	 jGpjnfaNI9qAqHq++HQDVJN3uDyrbAeCpE6I/LGl2eZdLFKqjGe5FsjiH8vIduQB6S
	 3SeTL1RFM8HTLZxUzHUztp4yf06EdYbqCfmfG3ArSlnlW37xwqnAMtTD2hWD7btu2H
	 2AudLBYoRiXGTo2diKAkh9ktrBqSH9+5koEIxqV8XYgdSMt8Lhz0/6ToTAzi5Y4rsv
	 jWkauD3Ez6Khg==
Date: Fri, 14 Jul 2023 20:30:32 -0700
From: Jakub Kicinski <kuba@kernel.org>
To: Leon Romanovsky <leon@kernel.org>
Cc: Saeed Mahameed <saeedm@nvidia.com>, Jianbo Liu <jianbol@nvidia.com>,
 Eric Dumazet <edumazet@google.com>, Mark Bloch <mbloch@nvidia.com>,
 netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>, "David S . Miller"
 <davem@davemloft.net>, Simon Horman <simon.horman@corigine.com>
Subject: Re: [PATCH net-next 09/12] net/mlx5: Compare with old_dest param to
 modify rule destination
Message-ID: <20230714203032.7f1bf5f7@kernel.org>
In-Reply-To: <20230714203258.GL41919@unreal>
References: <5fd15672173653d6904333ef197b605b0644e205.1689064922.git.leonro@nvidia.com>
	<20230712173259.4756fe08@kernel.org>
	<20230713063345.GG41919@unreal>
	<20230713100401.5fe0fa77@kernel.org>
	<20230713174317.GH41919@unreal>
	<20230713110556.682d21ba@kernel.org>
	<20230713185833.GI41919@unreal>
	<20230713201727.6dfe7549@kernel.org>
	<20230714184013.GJ41919@unreal>
	<20230714121633.18d19c4c@kernel.org>
	<20230714203258.GL41919@unreal>
Precedence: bulk
X-Mailing-List: netdev@vger.kernel.org
List-Id: <netdev.vger.kernel.org>
List-Subscribe: <mailto:netdev+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:netdev+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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.