Message-ID: <66142a4b402d5_2cb7208ec@john.notmuch>
Date: Mon, 08 Apr 2024 10:32:59 -0700
From: John Fastabend <john.fastabend@...il.com>
To: Jiri Pirko <jiri@...nulli.us>, 
 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

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

The gain is the same as if company X makes a card and sells it
exclusively to datacenter provider Y. We know this happens.
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.
DCs are all starting to build their own hardware if we lose this
section of HW we lose those developers too. We are less likely
to get any advances they come up with. I think you have it backwards.
Eventually Linux networking becomes either commodity and irrelevant
for DC deployments.

So I strongly disagree we lose by excluding drivers and win by
bringing it in.

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

Huh?

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