Message-ID: <CAKgT0UdZz3fKpkTRnq5ZO2nW3NQcQ_DWahHMyddODjmNDLSaZQ@mail.gmail.com>
Date: Sat, 6 Apr 2024 09:05:01 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Jason Gunthorpe <jgg@...dia.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 5, 2024 at 12:02 PM Jason Gunthorpe <jgg@...dia.com> wrote:
>
> 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.

Okay, on core changes I 100% agree. That is one of the reasons why we
have the whole thing about any feature really needing to be enabled on
at least 2 different vendor devices.

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

My apologies. I had interpreted your statement as essentially agreeing
with Jiri and NAKing the patches simply for not being commercially
available.

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

I can't say for certain if that will be the case going forward or not.
I know we haven't reached out to any distros and currently don't need
to. With that said though, having the driver available as a module
shouldn't cause any harm either so I don't really have a strong
opinion about it either way.

Seeing as how we arne't in the NIC business I am not sure how
restrictive we would be about licensing out the IP. I could see Meta
potentially trying to open up the specs just to take the manufacturing
burden off of us and enable more competition, though I am on the
engineering side and not so much sourcing so I am just speculating.

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

I'm assuming it is some sort of firmware functionality that is needed
to enable it? One thing with our design is that the firmware actually
has minimal functionality. Basically it is the liaison between the
BMC, Host, and the MAC. Otherwise it has no role to play in the
control path so when the driver is loaded it is running the show.

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

I assume you are talking about the need to have an open source
consumer for any exposed uapi? That makes sense from the test and
development standpoint as you need to have some way to exercise and
test any interface that is available in the kernel.

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

I didn't say how widely or when. I got my introduction to Linux by
buying used server systems and trying to get something maintainable in
terms of OS on them. From my experience you end up with all sorts of
odd-ball proprietary parts that eventually end up leaking out to the
public. Though back then it was more likely to be a proprietary spin
of some known silicon with a few tweaks that had to be accounted for.

> 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

Yeah, I think I had misunderstood your original comment as being in
support of Jiri's position. I hadn't fully grokked that you were doing
more of a "yes, but" versus an "yes, and".

For this driver I don't see there being too much in the way of
complications as there shouldn't be much in the way of any sort of
kernel-bypass that would be applicable to this driver uniquely.

Thanks,

- Alex

Powered by blists - more mailing lists