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. > 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 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 :|
