Thu, Apr 04, 2024 at 09:22:02PM CEST, alexander.duyck@xxxxxxxxx wrote: >On Thu, Apr 4, 2024 at 8:36 AM Jiri Pirko <jiri@xxxxxxxxxxx> wrote: >> >> Thu, Apr 04, 2024 at 04:45:14PM CEST, alexander.duyck@xxxxxxxxx wrote: >> >On Thu, Apr 4, 2024 at 4:37 AM Jiri Pirko <jiri@xxxxxxxxxxx> wrote: >> >> >> >> Wed, Apr 03, 2024 at 10:08:24PM CEST, alexander.duyck@xxxxxxxxx wrote: > ><...> > >> >> Could you please shed some light for the motivation to introduce this >> >> driver in the community kernel? Is this device something people can >> >> obtain in a shop, or is it rather something to be seen in Meta >> >> datacenter only? If the second is the case, why exactly would we need >> >> this driver? >> > >> >For now this is Meta only. However there are several reasons for >> >wanting to include this in the upstream kernel. >> > >> >First is the fact that from a maintenance standpoint it is easier to >> >avoid drifting from the upstream APIs and such if we are in the kernel >> >it makes things much easier to maintain as we can just pull in patches >> >without having to add onto that work by having to craft backports >> >around code that isn't already in upstream. >> >> That is making life easier for you, making it harder for the community. >> O relevance. >> >> >> > >> >Second is the fact that as we introduce new features with our driver >> >it is much easier to show a proof of concept with the driver being in >> >the kernel than not. It makes it much harder to work with the >> >community on offloads and such if we don't have a good vehicle to use >> >for that. What this driver will provide is an opportunity to push >> >changes that would be beneficial to us, and likely the rest of the >> >community without being constrained by what vendors decide they want >> >to enable or not. The general idea is that if we can show benefit with >> >our NIC then other vendors would be more likely to follow in our path. >> >> Yeah, so not even we would have to maintain driver nobody (outside Meta) >> uses or cares about, you say that we will likely maintain more of a dead >> code related to that. I think that in Linux kernel, there any many >> examples of similarly dead code that causes a lot of headaches to >> maintain. >> >> You just want to make your life easier here again. Don't drag community >> into this please. > >The argument itself doesn't really hold water. The fact is the Meta >data centers are not an insignificant consumer of Linux, so it isn't >as if the driver isn't going to be used. This implies some lack of Used by one user. Consider a person creating some custom proprietary FPGA based pet project for himself, trying to add driver for it to the mainline kernel. Why? Nobody else will ever see the device, why the community should be involved at all? Does not make sense. Have the driver for your internal cook-ups internal. >good faith from Meta. I don't understand that as we are contributing >across multiple areas in the kernel including networking and ebpf. Is >Meta expected to start pulling time from our upstream maintainers to >have them update out-of-tree kernel modules since the community isn't >willing to let us maintain it in the kernel? Is the message that the If Meta contributes whatever may be useful for somebody else, it is completely fine. This driver is not useful for anyone, except Meta. >kernel is expected to get value from Meta, but that value is not meant >to be reciprocated? Would you really rather have us start maintaining >our own internal kernel with our own "proprietary goodness", and ask I don't care, maintain whatever you want internally. Totally up to you. Just try to understand my POV. I may believe you have good faith and everything. But still, I think that community has to be selfish. >other NIC vendors to have to maintain their drivers against yet >another kernel if they want to be used in our data centers? > >As pointed out by Andew we aren't the first data center to push a >driver for our own proprietary device. The fact is there have been If you proprietary device is used by other people running virtual machines on your systems, that is completely fine. But that is incorrect analogy to your nic, no outside-Meta person will ever see it! >drivers added for devices that were for purely emulated devices with >no actual customers such as rocker. Should the switch vendors at the This is completely fault analogy. Rocker was introduced to solve chicken-egg problem to ass switch device support into kernel. It served the purpose quite well. Let it rot now. >time have pushed back on it stating it wasn't a real "for sale" >device? The whole argument seems counter to what is expected. When a >vendor creates a new device and will likely be enabling new kernel >features my understanding is that it is better to be in the kernel >than not. > >Putting a criteria on it that it must be "for sale" seems rather Not "for sale", but "available to the outside person". >arbitrary and capricious, especially given that most drivers have to Not capricious at all, I sorry you feel that way. You proceed your company goals, my position here is to defend the community and the unnecessary and pointless burden you are putting on it. >be pushed out long before they are available in the market in order to >meet deadlines to get the driver into OSV releases such as Redhat when >it hits the market. By that logic should we block all future drivers >until we can find them for sale somewhere? That way we don't run the That is or course obviously complete fault analogy again. You never plan to introduce your device to public. Big difference. Don't you see it? >risk of adding a vendor driver for a product that might be scrapped >due to a last minute bug that will cause it to never be released.
