From: Jiri Pirko <jiri@xxxxxxxxxxx> Date: Tue, 9 Apr 2024 13:01:51 +0200 > Mon, Apr 08, 2024 at 07:32:59PM CEST, john.fastabend@xxxxxxxxx wrote: >> Jiri Pirko wrote: >>> 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. BTW idpf is also not something you can go and buy in a store, but it's here in the kernel. Anyway, see below. >>>> 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. [...] >> Vendors would happily spin up a NIC if a DC with scale like this >> would pay for it. They just don't advertise it in patch 0/X, >> "adding device for cloud provider foo". >> >> There is no difference here. We gain developers, we gain insights, >> learnings and Linux and OSS drivers are running on another big >> DC. They improve things and find bugs they upstream them its a win. >> >> The opposite is also true if we exclude a driver/NIC HW that is >> running on major DCs we lose a lot of insight, experience, value. > > Could you please describe in details and examples what exactly is we > are about to loose? I don't see it. As long as driver A introduces new features / improvements / API / whatever to the core kernel, we benefit from this no matter whether I'm actually able to run this driver on my system. Some drivers even give us benefit by that they are of good quality (I don't speak for this driver, just some hypothetical) and/or have interesting design / code / API / etc. choices. The drivers I work on did gain a lot just from that I was reading new commits / lore threads and look at changes in other drivers. I saw enough situations when driver A started using/doing something the way it wasn't ever done anywhere before, and then more and more drivers stated doing the same thing and at the end it became sorta standard. I didn't read this patchset and thus can't say if it will bring us good immediately or some time later, but I believe there's no reason to reject the driver only because you can't buy a board for it in your gadget store next door. [...] Thanks, Olek
