netdev - Re: [net-next 14/15] net/mlx5: SRIOV, Add 802.1ad VST support

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:   Wed, 7 Dec 2022 09:25:17 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Saeed Mahameed <saeedm@...dia.com>
Cc:     Saeed Mahameed <saeed@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>, netdev@...r.kernel.org,
        Tariq Toukan <tariqt@...dia.com>,
        Moshe Shemesh <moshe@...dia.com>,
        Mark Bloch <mbloch@...dia.com>
Subject: Re: [net-next 14/15] net/mlx5: SRIOV, Add 802.1ad VST support

On Tue, 6 Dec 2022 21:20:54 -0800 Saeed Mahameed wrote:
>> I can't take this with clear conscience :( I started nacking any new use
>> of the legacy VF NDOs. You already have bridging offload implemented,
>> why can bridging be used?
> 
> I really tried, many customers aren't ready to make this leap yet.
> 
> I understand your point, my goal is to move as many customers to use
> upstream and step away from out of tree drivers, if it makes it any
> easier you can look at this as filling a small gap in mlx5 which will
> help me bring more users to the upstream driver, after all the feature
> is already implemented in mlx5, this is just a small gap we previously
> missed to upstream.

I recently nacked a new driver from AMD which was using legacy NDO, and
they can be somewhat rightfully miffed that those who got there earlier
can keep their support. If we let the older drivers also extend the
support the fairness will suffer even more.

We need to draw the line somewhere, so what do you propose as our
policy? Assuming we want people to move to new APIs and be fair 
to new vs old drivers.