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]

Date:   Tue, 14 Feb 2023 14:38:50 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Mark Bloch <mbloch@...dia.com>, Saeed Mahameed <saeed@...nel.org>,
        "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

Tue, Feb 14, 2023 at 03:02:46AM CET, kuba@...nel.org 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?
>Either way we need the expectation captured in the docs - 
>an "experimental" warning or examples of cases which behave differently.
>
>> 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)?
>
>I'm speaking under assumption that the document+deprecate plan is okay
>with Jiri.

I just talked with Mark. Makes sense to properly document and deprecate
as soon as possible. I don't see any other way. I can't wait when it is
done :)

so +1

Thanks!