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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 8 Apr 2024 08:46:35 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Jiri Pirko <jiri@...nulli.us>
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

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

[...]

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