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]

Message-ID: <Y5GgNlYbZOiH3H6t@x130>
Date:   Thu, 8 Dec 2022 00:28:38 -0800
From:   Saeed Mahameed <saeedm@...dia.com>
To:     Jakub Kicinski <kuba@...nel.org>
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 07 Dec 09:25, Jakub Kicinski wrote:
>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.

You put me in a tough spot ! 
You know where we stand at nVidia in all of this, we are advocating only
for switchdev mode, and we are 100% behind your decision to not extending
legacy support.

So if the part in this series of adding support for 802.1ad, falls under that
policy, then i must agree with you. I will drop it.

But another part in this series is fixing a critical bug were we drop VF tagged
packets when vst in ON, we will strip that part out and send it as a
bug fix, it is really critical, mlx5 vst basically doesn't work upstream for
tagged traffic.