Re: [net-next PATCH 00/15] eth: fbnic: Add network driver for Meta Platforms Host Network Interface

[Alexander Lobakin <aleksander.lobakin@intel.com>]

From: Jiri Pirko <jiri@resnulli.us>
Date: Tue, 9 Apr 2024 16:41:10 +0200

> Tue, Apr 09, 2024 at 03:11:21PM CEST, aleksander.lobakin@intel.com wrote:
>> From: Jiri Pirko <jiri@resnulli.us>
>> Date: Tue, 9 Apr 2024 13:01:51 +0200
>>
>>> Mon, Apr 08, 2024 at 07:32:59PM CEST, john.fastabend@gmail.com wrote:
>>>> Jiri Pirko wrote:
>>>>> Mon, Apr 08, 2024 at 05:46:35PM CEST, alexander.duyck@gmail.com wrote:
>>>>>> On Mon, Apr 8, 2024 at 4:51 AM Jiri Pirko <jiri@resnulli.us> wrote:
>>>>>>>
>>>>>>> Fri, Apr 05, 2024 at 08:38:25PM CEST, alexander.duyck@gmail.com wrote:
>>>>>>>> On Fri, Apr 5, 2024 at 8:17 AM Jason Gunthorpe <jgg@nvidia.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?

Anyhow, we want the upstream Linux kernel to work out of box on most
systems. Rejecting this driver basically encourages to still prefer
OOT/proprietary crap.

> 
> 
>>
>>>>>> 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.

It's not me who wants to make an exception. I haven't ever seen a driver
rejected due to "it can be used only somewhere where I can't go", so
looks like it's you who wants to make an exception :>

Thanks,
Olek