Re: [net-next 01/15] net/mlx5: Lag, Let user configure multiport eswitch

From: Mark Bloch <mbloch@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Saeed Mahameed <saeed@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	Saeed Mahameed <saeedm@nvidia.com>,
	netdev@vger.kernel.org, Tariq Toukan <tariqt@nvidia.com>,
	Roi Dayan <roid@nvidia.com>, Maor Dickman <maord@nvidia.com>
Subject: Re: [net-next 01/15] net/mlx5: Lag, Let user configure multiport eswitch
Date: Tue, 14 Feb 2023 09:31:10 +0200	[thread overview]
Message-ID: <b4300690-f9a3-5de6-08f8-0b3430db7fd8@nvidia.com> (raw)
In-Reply-To: <20230213180246.06ae4acd@kernel.org>

On 14/02/2023 4:02, Jakub Kicinski wrote:
> On Mon, 13 Feb 2023 21:00:16 +0200 Mark Bloch wrote:
>> I agree with you this definitely should be the default. That was
>> the plan in the beginning. Testing uncovered that making it the default
>> breaks users. It changes the look and feel of the driver when in switchdev
>> mode, the customers we've talked with are very afraid
>> it will break their software and actually, we've seen real breakages
>> and I fully expect more to pop up once this feature goes live.
> 
> Real breakages as in bugs that are subsequently addressed or inherent
> differences which customers may need to adjust their code for?

It will require changes to the code to deal with.

> Either way we need the expectation captured in the docs - 
> an "experimental" warning or examples of cases which behave differently.

Will talk with Roi and ask him to add proper documentation for this feature.

> 
>> We've started reaching out to customers and working with them on updating
>> their software but such a change takes time and honestly, we would like to
>> push this change out as soon as possible and start building
>> on top of this new mode. Once more features that are only possible in this
>> new mode are added it will be an even bigger incentive to move to it.
>>
>> We believe this parameter will allow customers to transition to the new
>> mode faster as we know this is a big change, let's start the transition
>> as soon as possible as we know delaying it will only make things worse.
>> Add a flag so we can control it and in the future, once all the software
>> is updated switch the flag to be the default and keep it for legacy
>> software where updating the logic isn't possible.
> 
> Oh, the "legacy software where updating the logic isn't possible"
> sounds concerning. Do we know what those cases are? Can we perhaps
> constrain them to run on a specific version of HW (say starting with
> CX8 the param will no longer be there and only the right behavior will
> be supported upstream)?

While I can encourage customers to update their software to deal with
this new mode it's up to them. As you already know, it's hard to change
customers infrastructure so quickly. These things take time. They plan
on running multiple hardware generations on top of the same software.
I'll keep pushing on making this mode the default one.

> 
> I'm speaking under assumption that the document+deprecate plan is okay
> with Jiri.

Will talk with Jiri and get his input.