From: Jason Gunthorpe <jgg@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Saeed Mahameed <saeed@kernel.org>,
David Ahern <dsahern@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Itay Avraham <itayavr@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
linux-doc@vger.kernel.org, linux-rdma@vger.kernel.org,
netdev@vger.kernel.org, Paolo Abeni <pabeni@redhat.com>,
Saeed Mahameed <saeedm@nvidia.com>,
Tariq Toukan <tariqt@nvidia.com>,
Andy Gospodarek <andrew.gospodarek@broadcom.com>,
Aron Silverton <aron.silverton@oracle.com>,
Dan Williams <dan.j.williams@intel.com>,
Christoph Hellwig <hch@infradead.org>,
Jiri Pirko <jiri@nvidia.com>, Leonid Bloch <lbloch@nvidia.com>,
Leon Romanovsky <leonro@nvidia.com>,
linux-cxl@vger.kernel.org, patches@lists.linux.dev
Subject: Re: [PATCH 0/8] Introduce fwctl subystem
Date: Wed, 5 Jun 2024 11:50:39 -0300 [thread overview]
Message-ID: <20240605145039.GU19897@nvidia.com> (raw)
In-Reply-To: <20240604153216.1977bd90@kernel.org>
On Tue, Jun 04, 2024 at 03:32:16PM -0700, Jakub Kicinski wrote:
> 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.
This is getting ridiculous. Did you disclose in your PSP cover letter
that all that work and new kernel uAPI is to support Meta's propritary
user space, even to the point that NO open source implementation even
exists yet? Let me check. Nope.
So why this made up double standard for Saeed? Especially after he
already said DOCA isn't on the agenda for mlx5's fwctl?
> > >> 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?
That is a bleak way of painting things. fwctl is a developing
consensus on how to solve this class of problems. We get to have a
consensus that is different than the past because Linux dos actually
evolve. All your long suffering IPU comanpies are welcome to use fwctl
with their products going forward just as equally to nvidia/etc.
Amazingly, "rules" are not set in stone in Linux!
> 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!
This vendor bashing needs to stop. You could have easially used the
word companies and been much more accurate. At this point the
hyperscale companies - your so-called "users" - are much more guilty
of "subsytem capture" than any vendor is, and it certainly has changed
the culture of Linux.
There are many legitimate complaints all around of maintainers being
capricious - it doesn't matter who employees them.
Jason
next prev parent reply other threads:[~2024-06-05 14:50 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-03 15:53 [PATCH 0/8] Introduce fwctl subystem Jason Gunthorpe
2024-06-03 15:53 ` [PATCH 1/8] fwctl: Add basic structure for a class subsystem with a cdev Jason Gunthorpe
2024-06-04 9:32 ` Leon Romanovsky
2024-06-04 15:50 ` Jason Gunthorpe
2024-06-04 17:05 ` Jonathan Cameron
2024-06-04 18:52 ` Jason Gunthorpe
2024-06-05 11:08 ` Jonathan Cameron
2024-06-04 16:42 ` Randy Dunlap
2024-06-04 16:44 ` Jason Gunthorpe
2024-06-03 15:53 ` [PATCH 2/8] fwctl: Basic ioctl dispatch for the character device Jason Gunthorpe
2024-06-04 12:16 ` Zhu Yanjun
2024-06-04 12:22 ` Leon Romanovsky
2024-06-04 16:50 ` Jonathan Cameron
2024-06-04 16:58 ` Jason Gunthorpe
2024-06-05 11:07 ` Jonathan Cameron
2024-06-05 18:27 ` Jason Gunthorpe
2024-06-06 13:34 ` Jonathan Cameron
2024-06-06 15:37 ` Randy Dunlap
2024-06-05 15:42 ` Przemek Kitszel
2024-06-05 15:49 ` Jason Gunthorpe
2024-06-03 15:53 ` [PATCH 3/8] fwctl: FWCTL_INFO to return basic information about the device Jason Gunthorpe
2024-06-13 23:32 ` Dave Jiang
2024-06-13 23:40 ` Jason Gunthorpe
2024-06-14 16:37 ` Dave Jiang
2024-06-03 15:53 ` [PATCH 4/8] taint: Add TAINT_FWCTL Jason Gunthorpe
2024-06-03 15:53 ` [PATCH 5/8] fwctl: FWCTL_RPC to execute a Remote Procedure Call to device firmware Jason Gunthorpe
2024-06-03 15:53 ` [PATCH 6/8] fwctl: Add documentation Jason Gunthorpe
2024-06-05 2:31 ` Randy Dunlap
2024-06-05 16:03 ` Jason Gunthorpe
2024-06-05 20:14 ` Randy Dunlap
2024-06-03 15:53 ` [PATCH 7/8] fwctl/mlx5: Support for communicating with mlx5 fw Jason Gunthorpe
2024-06-03 15:53 ` [PATCH 8/8] mlx5: Create an auxiliary device for fwctl_mlx5 Jason Gunthorpe
2024-06-03 18:42 ` [PATCH 0/8] Introduce fwctl subystem Jakub Kicinski
2024-06-04 3:01 ` David Ahern
2024-06-04 14:04 ` Jakub Kicinski
2024-06-04 21:28 ` Saeed Mahameed
2024-06-04 22:32 ` Jakub Kicinski
2024-06-05 14:50 ` Jason Gunthorpe [this message]
2024-06-05 15:41 ` Jakub Kicinski
2024-06-04 23:56 ` Dan Williams
2024-06-05 3:05 ` Jakub Kicinski
2024-06-05 11:19 ` Jonathan Cameron
2024-06-05 13:59 ` Jason Gunthorpe
2024-06-06 2:35 ` David Ahern
2024-06-06 14:18 ` Jakub Kicinski
2024-06-06 14:48 ` Jason Gunthorpe
2024-06-06 15:05 ` Jakub Kicinski
2024-06-06 17:47 ` David Ahern
2024-06-07 6:48 ` Jiri Pirko
2024-06-07 14:50 ` David Ahern
2024-06-07 15:14 ` Jason Gunthorpe
2024-06-07 15:50 ` Jiri Pirko
2024-06-07 17:24 ` Jason Gunthorpe
2024-06-07 7:34 ` Jiri Pirko
2024-06-07 12:49 ` Andrew Lunn
2024-06-07 13:34 ` Jiri Pirko
2024-06-08 1:43 ` Jakub Kicinski
2024-06-06 4:56 ` Dan Williams
2024-06-06 8:50 ` Leon Romanovsky
2024-06-06 22:11 ` Dan Williams
2024-06-07 0:02 ` Jason Gunthorpe
2024-06-07 13:12 ` Leon Romanovsky
2024-06-06 14:41 ` Jason Gunthorpe
2024-06-06 14:58 ` Jakub Kicinski
2024-06-06 17:24 ` Dan Williams
2024-06-07 0:25 ` Jason Gunthorpe
2024-06-07 10:47 ` Przemek Kitszel
2024-06-11 15:36 ` Daniel Vetter
2024-06-11 16:17 ` Jason Gunthorpe
2024-06-11 16:54 ` Daniel Vetter
2024-06-06 1:58 ` David Ahern
2024-06-05 3:11 ` Jakub Kicinski
2024-06-05 12:06 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240605145039.GU19897@nvidia.com \
--to=jgg@nvidia.com \
--cc=andrew.gospodarek@broadcom.com \
--cc=aron.silverton@oracle.com \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=dsahern@kernel.org \
--cc=hch@infradead.org \
--cc=itayavr@nvidia.com \
--cc=jiri@nvidia.com \
--cc=kuba@kernel.org \
--cc=lbloch@nvidia.com \
--cc=leon@kernel.org \
--cc=leonro@nvidia.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=patches@lists.linux.dev \
--cc=saeed@kernel.org \
--cc=saeedm@nvidia.com \
--cc=tariqt@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).