Thu, Jun 06, 2024 at 04:18:11PM CEST, kuba@xxxxxxxxxx wrote: >On Wed, 5 Jun 2024 20:35:49 -0600 David Ahern wrote: >> Until a feature is standardized and/or commoditized, it does not make >> sense to create a uapi for every H/W vendor whim. > >This is not about non-standard features. I work with multiple vendors >as my day job. I ask them how to set basic link configuration and the >support person gives me a link to the vendor tools! I wish I could show >you the emails. Even without emails seen, I believe you. Well, isn't it just natural? I mean, it always takes a bigger (sometimes much bigger) effort to implement things properly introducing/extending apis/uapis. Implement things in vendor tool is easy, low hanging fruit, people naturally pick them. I've been around in netdev for better part of second decade. I think, for the sake of discussion, it is worth mentioning, that a big part of netdev success despite complexicity is that in the past, any attempt of kernel bypass (I recall few) was promptly rejected. There was always big push for proper abstracted solution. And I believe it helped a lot all over the place. Is this approach depleted? I don't know, maybe. (And yes, I'm aware not everything could be done this way). I understand the reason and motivation for this patchset and what it will solve, don't get me wrong. I kind of like it, it will help to remove all painful detours we currenly have. My concern is, it opens a pandora box for netdev *for sure*. It that desired and anticipated? Do the gains overweight the potential losses? Will it help the ecosystem? What is motivation for vendor to take the hard way of using proper api (even existing ones) after? Moreover, wouldn't this serve for vendors to go out of leash and start to introduce even more H/W vendor whims? I think these are serious questions we need to ask before this is merged. > >> All of them are attempting to solve real problems; some of them will >> stick. We know which features are valuable when customers use them, > >Yes, once customers deploy a feature implemented via a vendor API >they will definitely migrate to a different API. Customers like risk >and wasting their engineering resources reimplementing and redeploying >things? And we have so much success move users to new APIs in Linux! > >> ask for them and other vendors copy them. Until then it is a 1-off by >> a vendor basically proposing a solution. > >Certainly. Because... who exactly will ask the second vendor to >implement the common API? > >And the second vendor will most certainly not mind the extra delay and >inconvenience having their product shipped via the publicly reviewed, >and slow to deploy kernel, while the first one is happily selling >the same feature already. > >> Not all ideas are good ideas, and we do not need the burden of a uapi >> or the burden of out of tree drivers. > >This API gives user space SDKs a trivial way of implementing all >switching, routing, filtering, QoS offloads etc. >An argument can be made that given somewhat mixed switchdev experience Can you elaborabe a bit more what you mean by "mixed switchdev experience" please? >we should just stay out of the way and let that happen. But just make >that argument then, instead of pretending the use of this API will be >limited to custom very vendor specific things. > >Again, if someone needs this to ship their custom CXL/Infiniband >AI fabric magic, which is un-interoperable by design -- none of >my concern. But keep TCP/IP networking out of this :| >
