Date: Tue, 4 Jun 2024 15:32:16 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Saeed Mahameed <saeed@...nel.org>
Cc: David Ahern <dsahern@...nel.org>, Jason Gunthorpe <jgg@...dia.com>,
 Jonathan Corbet <corbet@....net>, Itay Avraham <itayavr@...dia.com>, Leon
 Romanovsky <leon@...nel.org>, linux-doc@...r.kernel.org,
 linux-rdma@...r.kernel.org, netdev@...r.kernel.org, Paolo Abeni
 <pabeni@...hat.com>, Saeed Mahameed <saeedm@...dia.com>, Tariq Toukan
 <tariqt@...dia.com>, Andy Gospodarek <andrew.gospodarek@...adcom.com>, Aron
 Silverton <aron.silverton@...cle.com>, Dan Williams
 <dan.j.williams@...el.com>, Christoph Hellwig <hch@...radead.org>, Jiri
 Pirko <jiri@...dia.com>, Leonid Bloch <lbloch@...dia.com>, Leon Romanovsky
 <leonro@...dia.com>, linux-cxl@...r.kernel.org, patches@...ts.linux.dev
Subject: Re: [PATCH 0/8] Introduce fwctl subystem

On Tue, 4 Jun 2024 14:28:05 -0700 Saeed Mahameed wrote:
> On 04 Jun 07:04, Jakub Kicinski wrote:
> >On Mon, 3 Jun 2024 21:01:58 -0600 David Ahern wrote:  
> >> Seriously, Jakub, how is that in any way related to this patch set?  
> >
> >Whether they admit it or not, DOCA is a major reason nVidia wants
> >this to be standalone rather than part of RDMA.
> 
> No, DOCA isn't on the agenda for this new interface. But what is the point
> in arguing?

I'm not arguing any point, we argued enough. But you failed to disclose
that DOCA is very likely user of this interface. So whoever you're
planning to submit it to should know.

DOCA was top of mind for me because I noticed it has PSP support, and
I wanted to take a look at the implementation.

> Apparently the vendor is not credible enough in your opinion.

You're creating an interface where you depend on a pinky promise from
a black box that the RPC is not a write. I trust you personally not to
write a patch which abuses this interface. But this cannot possibly
extend to all developers, most of who just want to ship features.

> Which is an absolute outrageous grounds for a NAK.
> 
> Anyway I don't see your point in bringing up DOCA here, but obviously once 
> this interface is accepted, all developers are welcome to use it,
> including DOCA developers of course..

Of course.

> That being said, the why we need this is crystal clear in the 
> cover-letter and previous submission discussions, bringing random SDKs
> into this discussion is not objective and counter productive to the
> technical discussion.
> 
> >> You are basically suggesting that if any vendor ever has an out of tree
> >> option for its hardware every patch it sends should be considered a ruse
> >> to enable or simplify proprietary options.
> 
> It's apparent that you're attributing sinister agendas to patchsets when
> you fail to offer valid technical opinions regarding the NAK nature. Let's
> address this outside of this patchset, as this isn't the first occurrence.
> Consistency in evaluating patches is crucial;

Exactly :| Netdev people, including multiple prominent developers from
Mellanox/nVidia have been nacking SDK interfaces in Linux networking
for 20 years. How are we going to look to all the companies which have
been doing IPUs for over a decade if we change the rules for nVidia?

> some, like the fbnic and idpf, seem to go unquestioned, while others
> face scrutiny.

fbnic got a nack for any core changes or uAPI not used by other drivers.
idpf got a nack for pretending to be a standard.

You keep saying that I'm nacking your interface because I have some
hatred and distrust for you or nVidia. I really, really don't.
Any vendor posting this would get exactly the same nack from me.

If by "let's address this outside of this patchset" you mean that we
should have a discussion about maintainer favoritism, and subsystem
capture by vendors - you have my full support!

Powered by blists - more mailing lists