Message-ID: <20240405151703.GF5383@nvidia.com>
Date: Fri, 5 Apr 2024 12:17:03 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Alexander Duyck <alexander.duyck@...il.com>
Cc: Paolo Abeni <pabeni@...hat.com>, Jakub Kicinski <kuba@...nel.org>,
	John Fastabend <john.fastabend@...il.com>,
	Jiri Pirko <jiri@...nulli.us>, 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 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.

In my hypothetical you'd need to do something like open source Meta's
implementation of the AI networking that the DMABUF patches enable,
and even then since nobody could run it at performance the thing is
pretty questionable.

IMHO publishing a qemu chip emulator would not advance the open source
ecosystem around building a DMABUF AI networking scheme.

> > So I think there should be an expectation that technically sound things
> > Meta may propose must not be accepted because they cross the
> > ideological red line into enabling only proprietary software.
> 
> That is a faulty argument. That is like saying we should kick out the
> nouveu driver out of Linux just because it supports Nvidia graphics
> cards that happen to also have a proprietary out-of-tree driver out
> there,

Huh? nouveau supports a fully open source mesa graphics stack in
Linux. How is that remotely similar to what I said? No issue.

> or maybe we need to kick all the Intel NIC drivers out for
> DPDK? 

DPDK is fully open source, again no issue.

You pointed at two things that I would consider to be exemplar open
source projects and said their existance somehow means we should be
purging drivers from the kernel???

I really don't understand what you are trying to say at all.

The kernel standard is that good quality open source *does* exist, we
tend to not care what proprietary things people create beyond that.

> I can't think of many NIC vendors that don't have their own
> out-of-tree drivers floating around with their own kernel bypass
> solutions to support proprietary software.

Most of those are also open source, and we can't say much about what
people do out of tree, obviously.

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

Why should someone working to improve only their proprietary
environment be welcomed in the same way as someone working to improve
the open source ecosystem? That has never been the kernel communities
position.

If you want to propose things to the kernel that can only be
meaningfully used by your proprietary software then you should not
expect to succeed. No one should be surprised to hear this.

Jason

Powered by blists - more mailing lists