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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <db85436e-67a3-4236-dcb5-590cf3c9eafa@nvidia.com>
Date:   Mon, 13 Feb 2023 21:00:16 +0200
From:   Mark Bloch <mbloch@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>, Saeed Mahameed <saeed@...nel.org>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Saeed Mahameed <saeedm@...dia.com>, netdev@...r.kernel.org,
        Tariq Toukan <tariqt@...dia.com>, Roi Dayan <roid@...dia.com>,
        Maor Dickman <maord@...dia.com>
Subject: Re: [net-next 01/15] net/mlx5: Lag, Let user configure multiport
 eswitch

On 11/02/2023 6:03, Jakub Kicinski wrote:
> On Fri, 10 Feb 2023 14:18:07 -0800 Saeed Mahameed wrote:
>> From: Roi Dayan <roid@...dia.com>
>>
>> Instead of activating multiport eswitch dynamically through
>> adding a TC rule and meeting certain conditions, allow the user
>> to activate it through devlink.
>> This will remove the forced requirement of using TC.
>> e.g. Bridge offload.
>>
>> Example:
>>     $ devlink dev param set pci/0000:00:0b.0 name esw_multiport value 1 \
>>                   cmode runtime
> 
> The PR message has way better description of what's going on here.
> 
>> +   * - ``esw_multiport``
>> +     - Boolean
>> +     - runtime
>> +     - Set the E-Switch lag mode to multiport.
> 
> This is just spelling out the name, not real documentation :(
> 
> IIUC the new mode is how devices _should_ work in switchdev mode,
> so why not make this the default already? What's the cut-off point?

Hi Jakub,

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.

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.

I've been dealing with LAG / E-Switch code for the past few years, which is
a very big pain for me. I would like to move forward and have a software
model that makes sense and simplifies the logic inside mlx5 and this is the
best way we have right now.