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
