On Mon, Apr 8, 2024 at 4:51 AM Jiri Pirko <jiri@xxxxxxxxxxx> wrote: > > Fri, Apr 05, 2024 at 08:38:25PM CEST, alexander.duyck@xxxxxxxxx wrote: > >On Fri, Apr 5, 2024 at 8:17 AM Jason Gunthorpe <jgg@xxxxxxxxxx> 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.
