On Sat, 6 Apr 2024 09:05:01 -0700 Alexander Duyck wrote: > > I'm being very clear to say that there are some core changes should > > not be accepted due to the kernel's open source ideology. > > Okay, on core changes I 100% agree. That is one of the reasons why we > have the whole thing about any feature really needing to be enabled on > at least 2 different vendor devices. The "2 different vendor"/implementation thing came up before so I wanted to provide more context for the less initiated readers. We try to judge features in terms of how reasonable the APIs are, overall system design and how easy they will be to modify later (e.g. uAPI, depth of core changes). Risks are usually more pronounced for stack features like GSO partial, XDP or AF_XDP. Although my (faulty) memory is that we started with just mlx4 for XDP and other drivers quickly followed. But we did not wait for more than an ACK from other vendors. We almost never have a second implementation for HW-heavy features. TLS immediately comes to mind, and merging it was probably the right call given how many implementations were added since. For "full" IPsec offload we still only have one vendor. Existing TCP ZC Rx (page flipping) was presented as possible with two NICs but mlx5 was hacked up and still doesn't support real HDS. Most (if not all) of recent uAPI we added in netdev netlink were accepted with a single implementation (be it Intel's work + drivers or my work, and I often provide just a bnxt implementation). Summary -> the number of implementations we require is decided on case by case basis, depending on our level of confidence.. I don't know if this "2 implementations" rule is just a "mental ellipsis" everyone understands to be a more nuanced rule in practice. But to an outsider it would seem very selectively enforced. In worst case a fake rule to give us an excuse to nack stuff.
