Mon, Apr 08, 2024 at 05:46:35PM CEST, alexander.duyck@xxxxxxxxx wrote: >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? The gain for community is still 0. No matter how many instances is private hw you privately have. Just have a private driver. > >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. Give it for free. > >[...] > >> >> > 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 Heh, what ifs :) Anyway, chance that happens is very close to 0. >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.
