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 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 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 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 drivers added for devices that were for purely emulated devices with no actual customers such as rocker. Should the switch vendors at the 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 arbitrary and capricious, especially given that most drivers have to 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 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.
