Message-ID: <ZhQgmrH-QGu6HP-k@nanopsycho>
Date: Mon, 8 Apr 2024 18:51:38 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Alexander Duyck <alexander.duyck@...il.com>
Cc: Jason Gunthorpe <jgg@...dia.com>, Paolo Abeni <pabeni@...hat.com>,
	Jakub Kicinski <kuba@...nel.org>,
	John Fastabend <john.fastabend@...il.com>, 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

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.
>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.
>In addition simply due to the size of the datacenters that we will be
>populating there is actually a strong likelihood that there will be
>more instances of this NIC running on Linux than there are of some
>other vendor devices that have been allowed to have drivers in the
>kernel.

So? The gain for community is still 0. No matter how many instances is
private hw you privately have. Just have a private driver.


>
>So from what I can tell the only difference is if we are manufacturing
>this for sale, or for personal use. Thus why I mention "commercial"
>since the only difference from my perspective is the fact that we are
>making it for our own use instead of selling it.

Give it for free.


>
>[...]
>
>> >> > I agree. We need a consistent set of standards. I just strongly
>> >> > believe commercial availability shouldn't be one of them.
>> >>
>> >> I never said commercial availability. I talked about open source vs
>> >> proprietary userspace. This is very standard kernel stuff.
>> >>
>> >> You have an unavailable NIC, so we know it is only ever operated with
>> >> Meta's proprietary kernel fork, supporting Meta's proprietary
>> >> userspace software. Where exactly is the open source?
>> >
>> >It depends on your definition of "unavailable". I could argue that for
>> >many most of the Mellanox NICs are also have limited availability as
>> >they aren't exactly easy to get a hold of without paying a hefty
>> >ransom.
>>
>> Sorry, but I have to say this is ridiculous argument, really Alex.
>> Apples and oranges.
>
>Really? So would you be making the same argument if it was
>Nvidia/Mellanox pushing the driver and they were exclusively making it
>just for Meta, Google, or some other big cloud provider? I suspect

Heh, what ifs :) Anyway, chance that happens is very close to 0.


>not. If nothing else they likely wouldn't disclose the plan for
>exclusive sales to get around this sort of thing. The fact is I know
>many of the vendors make proprietary spins of their firmware and
>hardware for specific customers. The way I see it this patchset is
>being rejected as I was too honest about the general plan and use case
>for it.
>
>This is what I am getting at. It just seems like we are playing games
>with semantics where if it is a vendor making the arrangement then it
>is okay for them to make hardware that is inaccessible to most, but if
>it is Meta then somehow it isn't.

Powered by blists - more mailing lists