Message-ID: <ZhVThhwFSV0HgQ0B@nanopsycho>
Date: Tue, 9 Apr 2024 16:41:10 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Alexander Lobakin <aleksander.lobakin@...el.com>
Cc: John Fastabend <john.fastabend@...il.com>,
	Alexander Duyck <alexander.duyck@...il.com>,
	Jason Gunthorpe <jgg@...dia.com>, Paolo Abeni <pabeni@...hat.com>,
	Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
	bhelgaas@...gle.com, linux-pci@...r.kernel.org,
	Alexander Duyck <alexanderduyck@...com>, davem@...emloft.net,
	Christoph Hellwig <hch@....de>
Subject: Re: [net-next PATCH 00/15] eth: fbnic: Add network driver for Meta
 Platforms Host Network Interface

Tue, Apr 09, 2024 at 03:11:21PM CEST, aleksander.lobakin@...el.com wrote:
>From: Jiri Pirko <jiri@...nulli.us>
>Date: Tue, 9 Apr 2024 13:01:51 +0200
>
>> Mon, Apr 08, 2024 at 07:32:59PM CEST, john.fastabend@...il.com wrote:
>>> Jiri Pirko wrote:
>>>> Mon, Apr 08, 2024 at 05:46:35PM CEST, alexander.duyck@...il.com wrote:
>>>>> On Mon, Apr 8, 2024 at 4:51 AM Jiri Pirko <jiri@...nulli.us> wrote:
>>>>>>
>>>>>> Fri, Apr 05, 2024 at 08:38:25PM CEST, alexander.duyck@...il.com wrote:
>>>>>>> On Fri, Apr 5, 2024 at 8:17 AM Jason Gunthorpe <jgg@...dia.com> wrote:
>>>>>>>>
>>>>>>>> On Fri, Apr 05, 2024 at 07:24:32AM -0700, Alexander Duyck wrote:
>>>>>>>>>> Alex already indicated new features are coming, changes to the core
>>>>>>>>>> code will be proposed. How should those be evaluated? Hypothetically
>>>>>>>>>> should fbnic be allowed to be the first implementation of something
>>>>>>>>>> invasive like Mina's DMABUF work? Google published an open userspace
>>>>>>>>>> for NCCL that people can (in theory at least) actually run. Meta would
>>>>>>>>>> not be able to do that. I would say that clearly crosses the line and
>>>>>>>>>> should not be accepted.
>>>>>>>>>
>>>>>>>>> Why not? Just because we are not commercially selling it doesn't mean
>>>>>>>>> we couldn't look at other solutions such as QEMU. If we were to
>>>>>>>>> provide a github repo with an emulation of the NIC would that be
>>>>>>>>> enough to satisfy the "commercial" requirement?
>>>>>>>>
>>>>>>>> My test is not "commercial", it is enabling open source ecosystem vs
>>>>>>>> benefiting only proprietary software.
>>>>>>>
>>>>>>> Sorry, that was where this started where Jiri was stating that we had
>>>>>>> to be selling this.
>>>>>>
>>>>>> For the record, I never wrote that. Not sure why you repeat this over
>>>>>> this thread.
>>>>>
>>>>> Because you seem to be implying that the Meta NIC driver shouldn't be
>>>>> included simply since it isn't going to be available outside of Meta.
>
>BTW idpf is also not something you can go and buy in a store, but it's
>here in the kernel. Anyway, see below.

IDK, why so many people in this thread are so focused on "buying" nic.
IDPF device is something I assume one may see on a VM hosted in some
cloud, isn't it? If yes, it is completely legit to have it in. Do I miss
something?


>
>>>>> The fact is Meta employs a number of kernel developers and as a result
>>>>> of that there will be a number of kernel developers that will have
>>>>> access to this NIC and likely do development on systems containing it.
>
>[...]
>
>>> Vendors would happily spin up a NIC if a DC with scale like this
>>> would pay for it. They just don't advertise it in patch 0/X,
>>> "adding device for cloud provider foo".
>>>
>>> There is no difference here. We gain developers, we gain insights,
>>> learnings and Linux and OSS drivers are running on another big
>>> DC. They improve things and find bugs they upstream them its a win.
>>>
>>> The opposite is also true if we exclude a driver/NIC HW that is
>>> running on major DCs we lose a lot of insight, experience, value.
>> 
>> Could you please describe in details and examples what exactly is we
>> are about to loose? I don't see it.
>
>As long as driver A introduces new features / improvements / API /
>whatever to the core kernel, we benefit from this no matter whether I'm
>actually able to run this driver on my system.
>
>Some drivers even give us benefit by that they are of good quality (I
>don't speak for this driver, just some hypothetical) and/or have
>interesting design / code / API / etc. choices. The drivers I work on
>did gain a lot just from that I was reading new commits / lore threads
>and look at changes in other drivers.
>
>I saw enough situations when driver A started using/doing something the
>way it wasn't ever done anywhere before, and then more and more drivers
>stated doing the same thing and at the end it became sorta standard.

So bottom line is, the unused driver *may* introduce some features and
*may* provide as an example of how to do things for other people.
Is this really that beneficial for the community that it overweights
the obvious cons (not going to repeat them)?

Like with any other patch/set we merge in, we always look at the cons
and pros. I'm honestly surprised that so many people here
want to make exception for Meta's internal toy project.


>
>I didn't read this patchset and thus can't say if it will bring us good
>immediately or some time later, but I believe there's no reason to
>reject the driver only because you can't buy a board for it in your
>gadget store next door.

Again with "buying", uff.


>
>[...]
>
>Thanks,
>Olek

Powered by blists - more mailing lists