Message-ID: <CAKgT0Ufc0Zx6-UwCNbwtEahdbCv=eVqJKoDuoQdz6QMD2tv-ww@mail.gmail.com>
Date: Tue, 9 Apr 2024 11:38:59 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Leon Romanovsky <leon@...nel.org>, Jakub Kicinski <kuba@...nel.org>, 
	John Fastabend <john.fastabend@...il.com>, Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org, 
	bhelgaas@...gle.com, linux-pci@...r.kernel.org, 
	Alexander Duyck <alexanderduyck@...com>, davem@...emloft.net, pabeni@...hat.com
Subject: Re: [net-next PATCH 00/15] eth: fbnic: Add network driver for Meta
 Platforms Host Network Interface

On Tue, Apr 9, 2024 at 10:12 AM Jason Gunthorpe <jgg@...dia.com> wrote:
>
> On Tue, Apr 09, 2024 at 09:31:06AM -0700, Alexander Duyck wrote:
>
> > > expectation is generally things like:
> > >
> > >  - The bug is fixed immediately because the issue is obvious to the
> > >    author
> > >  - Iteration and rapid progress is seen toward enlightening the author
> > >  - The patch is reverted, often rapidly, try again later with a good
> > >    patch
> >
> > When working on a development branch that shouldn't be the
> > expectation. I suspect that is why the revert was pushed back on
> > initially. The developer wanted a chance to try to debug and resolve
> > the issue with root cause.
>
> Even mm-unstable drops patches on a hair trigger, as an example.
>
> You can't have an orderly development process if your development tree
> is broken in your CI.. Personally I'm grateful for the people who test
> linux-next (or the various constituent sub trees), it really helps.
>
> > Well much of it has to do with the fact that this is supposed to be a
> > community. Generally I help you, you help me and together we both make
> > progress. So within the community people tend to build up what we
> > could call karma. Generally I think some of the messages sent seemed
> > to make it come across that the Mellanox/Nvidia folks felt it "wasn't
> > their problem" so they elicited a bit of frustration from the other
> > maintainers and built up some negative karma.
>
> How could it be NVIDIA folks problem? They are not experts in TCP and
> can't debug it. The engineer running the CI systems did what he was
> asked by Eric from what I can tell.

No, I get your message. I wasn't saying it was your problem. All that
can be asked for is such cooperation. Like I said I think some of the
problem was the messaging more than the process.

> > phenomenon where if we even brushed against block of upstream code
> > that wasn't being well maintained we would be asked to fix it up and
> > address existing issues before we could upstream any patches.
>
> Well, Intel has it's own karma problems in the kernel community. :(

Oh, I know. I resisted the urge to push out the driver as "idgaf:
Internal Device Generated at Facebook" on April 1st instead of "fbnic"
to poke fun at the presentation they did at Netdev 0x16 where they
were trying to say all the vendors should be implementing "idpf" since
they made it a standard.

> > > In my view the vendor/!vendor distinction is really toxic and should
> > > stop.
> >
> > I agree. However that was essentially what started all this when Jiri
> > pointed out that we weren't selling the NIC to anyone else. That made
> > this all about vendor vs !vendor,
>
> That is not how I would sum up Jiri's position.
>
> By my read he is saying that contributing code to the kernel that only
> Meta can actually use is purely extractive. It is not about vendor or
> !vendor, it is taking-free-forwardporting or not. You have argued,
> and I would agree, that there is a grey scale between
> extractive/collaborative - but I also agree with Jiri that fbnic is
> undeniably far toward the extractive side.
>
> If being extractive is a problem in this case or not is another
> question, but I would say Jiri's objection is definitely not about
> selling or vendor vs !vendor.
>
> Jason

It all depends on your definition of being extractive. I would assume
a "consumer" that is running a large number of systems and is capable
of providing sophisticated feedback on issues found within the kernel,
in many cases providing fixes for said issues, or working with
maintainers on resolution of said issues, is not extractive.

The fact that said "consumer" decides to then produce their own device
becoming a "prosumer" means they are now able to more accurately and
quickly diagnose issues when they see them. They can design things
such that there isn't some black box of firmware, or a third party
driver, in the datapath that prevents them from quickly diagnosing the
issue. So if anything I would think that is a net positive for the
community as it allows the "prosumer" to provide much more quick and
useful feedback on issues found in the kernel rather than having to
wait on a third party vendor to provide additional input.

Note I am not going after any particular vendor with my comments. This
applies to all vendors. The problem as a customer is that you are
limited on what you can do once you find an issue. Quite often you are
at the mercy of the vendor in such cases, especially when there seems
to be either firmware or "security" issues involved.

Thanks,

- Alex

Powered by blists - more mailing lists