From: Jiri Pirko <jiri@xxxxxxxxxxx> Date: Tue, 9 Apr 2024 16:41:10 +0200 > Tue, Apr 09, 2024 at 03:11:21PM CEST, aleksander.lobakin@xxxxxxxxx wrote: >> 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. > > IDK, why so many people in this thread are so focused on "buying" nic. > IDPF device is something I assume one may see on a VM hosted in some > cloud, isn't it? If yes, it is completely legit to have it in. Do I miss > something? Anyhow, we want the upstream Linux kernel to work out of box on most systems. Rejecting this driver basically encourages to still prefer OOT/proprietary crap. > > >> >>>>>> 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. > > So bottom line is, the unused driver *may* introduce some features and > *may* provide as an example of how to do things for other people. > Is this really that beneficial for the community that it overweights > the obvious cons (not going to repeat them)? > > Like with any other patch/set we merge in, we always look at the cons > and pros. I'm honestly surprised that so many people here > want to make exception for Meta's internal toy project. It's not me who wants to make an exception. I haven't ever seen a driver rejected due to "it can be used only somewhere where I can't go", so looks like it's you who wants to make an exception :> Thanks, Olek
