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:   Mon, 13 Feb 2023 18:02:46 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Mark Bloch <mbloch@...dia.com>
Cc:     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

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.