Message-ID: <ZhPPjzEuOyne8qX7@nanopsycho>
Date: Mon, 8 Apr 2024 13:05:51 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: John Fastabend <john.fastabend@...il.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
	Alexander Duyck <alexander.duyck@...il.com>, 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

Thu, Apr 04, 2024 at 11:59:33PM CEST, john.fastabend@...il.com wrote:
>Jakub Kicinski wrote:
>> On Thu, 4 Apr 2024 12:22:02 -0700 Alexander Duyck wrote:
>> > The argument itself doesn't really hold water. The fact is the Meta
>> > data centers are not an insignificant consumer of Linux, 
>> 
>> customer or beneficiary ?
>> 
>> > so it isn't as if the driver isn't going to be used. This implies
>> > some lack of good faith from Meta.
>> 
>> "Good faith" is not a sufficient foundation for a community consisting
>> of volunteers, and commercial entities (with the xz debacle maybe even
>> less today than it was a month ago). As a maintainer I really don't want
>> to be in position of judging the "good faith" of corporate actors.
>> 
>> > I don't understand that as we are
>> > contributing across multiple areas in the kernel including networking
>> > and ebpf. Is Meta expected to start pulling time from our upstream
>> > maintainers to have them update out-of-tree kernel modules since the
>> > community isn't willing to let us maintain it in the kernel? Is the
>> > message that the kernel is expected to get value from Meta, but that
>> > value is not meant to be reciprocated? Would you really rather have
>> > us start maintaining our own internal kernel with our own
>> > "proprietary goodness", and ask other NIC vendors to have to maintain
>> > their drivers against yet another kernel if they want to be used in
>> > our data centers?
>> 
>> Please allow the community to make rational choices in the interest of
>> the project and more importantly the interest of its broader user base.
>> 
>> Google would also claim "good faith" -- undoubtedly is supports 
>> the kernel, and lets some of its best engineers contribute.
>> Did that make them stop trying to build Fuchsia? The "good faith" of
>> companies operates with the limits of margin of error of they consider
>> rational and beneficial.
>> 
>> I don't want to put my thumb on the scale (yet?), but (with my
>> maintainer hat on) please don't use the "Meta is good" argument, because
>> someone will send a similar driver from a less involved company later on
>> and we'll be accused of playing favorites :( Plus companies can change
>> their approach to open source from "inclusive" to "extractive" 
>> (to borrow the economic terminology) rather quickly.
>> 
>
>I'll throw my $.02 in. In this case you have a driver that I only scanned
>so far, but looks well done. Alex has written lots of drivers I trust he
>will not just abondon it. And if it does end up abondoned and no one
>supports it at some future point we can deprecate it same as any other
>driver in the networking tree. All the feedback is being answered and
>debate is happening so I expect will get a v2, v3 or so. All good signs
>in my point.
>
>Back to your point about faith in a company. I don't think we even need
>to care about whatever companies business plans. The author could have
>submitted with their personal address for what its worth and called it
>drivers/alexware/duyck.o Bit extreme and I would have called him on it,
>but hopefully the point is clear.
>
>We have lots of drivers in the tree that are hard to physically get ahold
>of. Or otherwise gated by paying some vendor for compute time, etc. to
>use. We even have some drivers where the hardware itself never made
>it out into the wild or only a single customer used it before sellers 
>burned it for commercial reasons or hw wasn't workable, team was cut, etc.
>
>I can't see how if I have a physical NIC for it on my desk here makes
>much difference one way or the other.
>
>The alternative is much worse someone builds a team of engineers locks
>them up they build some interesting pieces and we never get to see it
>because we tried to block someone from opensourcing their driver?
>Eventually they need some kernel changes and than we block those too
>because we didn't allow the driver that was the use case? This seems
>wrong to me.
>
>Anyways we have zero ways to enforce such a policy. Have vendors
>ship a NIC to somebody with the v0 of the patch set? Attach a picture? 

Come on. Are you kidding? Isn't this case crystal clear?


>Even if vendor X claims they will have a product in N months and
>than only sells it to qualified customers what to do we do then.
>Driver author could even believe the hardware will be available
>when they post the driver, but business may change out of hands
>of the developer.
>
>I'm 100% on letting this through assuming Alex is on top of feedback
>and the code is good. I think any other policy would be very ugly
>to enforce, prove, and even understand. Obviously code and architecture
>debates I'm all for. Ensuring we have a trusted, experienced person
>signed up to review code, address feedback, fix whatever syzbot finds
>and so on is also a must I think. I'm sure Alex will take care of
>it.

You are for some reason making this submission very personal on Alex.
Just to be clear, this has nothing to do with Alex.


>
>Thanks,
>John

Powered by blists - more mailing lists