Wed, Apr 10, 2024 at 01:45:54PM CEST, aleksander.lobakin@xxxxxxxxx wrote: >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. Totally true. Out of the box on as many systems as possible. This is not the case. Can you show me an example of a person outside-of-Meta can benefit from using this driver out-of-box? > >> >> >>> >>>>>>> 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 :> Could you please point me to some other existing driver for device that does not exist (/exist only at some person's backyard)? > >Thanks, >Olek
