netdev - Re: [PATCH v4 10/10] bnxt: Create an auxiliary device for fwctl

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: <Z6avI-tLNOecCT-4@x130>
Date: Fri, 7 Feb 2025 17:10:59 -0800
From: Saeed Mahameed <saeedm@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Andy Gospodarek <andrew.gospodarek@...adcom.com>,
	Jason Gunthorpe <jgg@...dia.com>,
	Aron Silverton <aron.silverton@...cle.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Dave Jiang <dave.jiang@...el.com>, David Ahern <dsahern@...nel.org>,
	Andy Gospodarek <gospo@...adcom.com>,
	Christoph Hellwig <hch@...radead.org>,
	Itay Avraham <itayavr@...dia.com>, Jiri Pirko <jiri@...dia.com>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	Leonid Bloch <lbloch@...dia.com>,
	Leon Romanovsky <leonro@...dia.com>, linux-cxl@...r.kernel.org,
	linux-rdma@...r.kernel.org, netdev@...r.kernel.org,
	"Nelson, Shannon" <shannon.nelson@....com>,
	Michael Chan <michael.chan@...adcom.com>
Subject: Re: [PATCH v4 10/10] bnxt: Create an auxiliary device for fwctl_bnxt

On 07 Feb 13:51, Jakub Kicinski wrote:
>On Fri, 7 Feb 2025 12:25:28 -0800 Saeed Mahameed wrote:
>> >nVidia is already refusing to add basic minoring features to their
>> >upstream driver, and keeps asking its customers to migrate to libdoca.
>>
>> nVidia is one of the top contributers to netdev,
>
>That's inaccurate. I can't think of a single meaningful contribution
>from nVidia's NIC team outside of your own driver in the last 2 years.
>

I can help refresh your memory.
Switchdev, devlink, XFRM, TLS, XDP (multi buff, meta data),
page pool, and I'm pretty sure much more.

I can also point out a lot of projects that are still stuck for many years
due to lack of agreements on design and communicated importance e.g:
PSP, TCP ZC, devlink params, and some more..

Maybe you mean meaningful to you, which is very hard to predict what is
meaningful to you without clear communication.

>> we submit patches on weekly bases and due to netdev mailing list
>> review backlog and policy we barely make quota,
>
>Luckily we have development statistics so we don't have to argue:
>
Yes we don't have to argue, thanks for sharing.

[...] snip top reviewers since it's not part of the discussion.
>Top authors (cs):                    Top authors (msg):
>   1 (   ) [9] RedHat                   1 (   ) [48] Intel
>   2 ( +2) [8] Google                   2 (   ) [42] RedHat
>   3 ( -1) [7] Intel                    3 ( +1) [39] Meta
>   4 ( -1) [7] Meta                     4 ( -1) [31] Huawei
>   5 ( +2) [5] nVidia                   5 (   ) [31] nVidia
                 ^^^^^^                                ^^^^^^

So we do contribute to netdev.. and we are not moving away from netdev
which was the whole point of your argument.

[...] snip Top scores, since doing reviews is not the issue here.
It's a separate topic. If you want we can discuss in a separate thread
since I got a lot of what to say on this.

>https://lore.kernel.org/all/20250121200710.19126f7d@kernel.org/
>
>nVidia has a negative review vs authorship score. It'd probably
>be much worse if it wasn't for the work of the switch team.
>

Irrelevant to FWCTL. And yes very important topic to discuss, we have
our own reasons and concerns. Let me know if you want to open this topic
for discussion in a separate thread.

>> so please elaborate on what features we are refusing to do ??
>
>nVidia likes to send these threads to my management so I need
>to be careful. An issue was discovered during new platform evaluation.
>That's all I'm gonna say.
>

I am not sure what you are talking about, but as one of the mlx5
maintainers I am 100% we are not refusing to do anything that we've been
asked, it is all about priorities, you have to sort this out with whoever
is reaching out to you :).

It's really hard to keep the discussion coherent and objective when you
are referring to private discussions I am not really part of, that we
can't discuss here, yet you brought them up.

>> As explained above, netdev doesn't need it, but netdev subsystem also
>> hosts the pci base drivers, so you are going to see fwctl patches the
>> same as you see rdma and other non netdev patches flowing through
>> netdev ML.
>
>Sure, but we're deadlocked here. It may be a slight inconvenience to
>redo the interface so that its not a standalone aux bus driver. But if
>you agree the netdev doesn't need it seems like a fairly straightforward
>way to unblock your progress.

Yes Aux needs some improvements and it must and can be abstracted out of
netdev relatively easily, to remove this unnecessary workload on netdev ML.

>
>I am glad that you at least agree now that nedev doesn't need it.

netdev can perfectly operate with all the standard tooling we got and we will
keep on developing them, TCP/IP configurability is well-established, that being
said, netdev is very bad at debug, and really really behind, the
few debugfs' and devlinks we have really don't cut it and will never be as
good as fwctl, so mlx5 fwctl has to run side by side with netdev,
I believe the same is true for all other vendors.