Re: [PATCH 0/8] Introduce fwctl subystem

[Jakub Kicinski <kuba@kernel.org>]

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