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

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Apr 05, 2024 at 11:38:25AM -0700, Alexander Duyck wrote:

> > 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.
> 
> Well not too many will be able to afford getting the types of systems
> and hardware needed for this in the first place. Primarily just your
> large data center companies can afford it.
> 
> I never said this hardware is about enabling DMABUF.

I presented a hypothetical to be able to illustrate a scenario where
this driver should not be used to justify invasive core kernel
changes.

I have no idea what future things you have in mind, or if any will
reach a threshold where I would expect they should not be
included. You where the one saying a key reason you wanted this driver
was to push core changes and you said you imagine changes that are
unique to fbnic that "others might like to follow".

I'm being very clear to say that there are some core changes should
not be accepted due to the kernel's open source ideology.

> Right, nouveau is fully open source. That is what I am trying to do
> with fbnic. That is what I am getting at. This isn't connecting to
> some proprietary stack or engaging in any sort of bypass.

The basic driver presented here is not, a future driver that justifies
unknown changes to the core may be.

This is why my message was pretty clear. IMHO there is nothing wrong
with this series, but I do not expect you will get everything you want
in future due to this issue.

I said decide if you want to continue. I'm not NAKing anything on this
series.

> I'm trying to say that both those projects are essentially doing the
> same thing you are accusing fbnic of doing, 

Not even close. Both those projects support open source ecosystems,
have wide cross vendor participating. fbnic isn't even going to be
enabled in any distribution.

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

And GNIC's that run Mina's series are completely unavailable right
now. That is still a big different from a temporary issue to a
permanent structural intention of the manufacturer.

> > 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.
> 
> To quote Linus `I do not see open source as some big goody-goody
> "let's all sing kumbaya around the campfire and make the world a
> better place". No, open source only really works if everybody is
> contributing for their own selfish reasons.`[1]

I think that stance has evolved and the consensus position toward uapi
is stronger.

> different. Given enough time it is likely this will end up in the
> hands of those outside Meta anyway, at that point the argument would
> be moot.

Oh, I'm skeptical about that.

You seem to have taken my original email in a strange direction. I
said this series was fine but cautioned that if you proceed you should
be expecting an eventual feature rejection for idological reasons, and
gave a hypothetical example what that would look like.

If you want to continue or not is up to Meta, in my view.

Jason