Wed, Jul 13, 2022 at 07:52:55PM CEST, kuba@kernel.org wrote:

On Wed, 13 Jul 2022 07:04:04 +0200 Jiri Pirko wrote:

quoted

Wed, Jul 13, 2022 at 02:13:41AM CEST, kuba@kernel.org wrote:

quoted

quoted

I don't think this has anything to do with netdev model. 
It is actually out of the scope of it, therefore there cannot be any mudding of it.  

You should have decided that rate limiting was out of scope for netdev
before we added tc qdisc and tc police support. Now those offloads are
there, used by people and it's too late.

If you want to create a common way to rate limit functions you must
provide plumbing for the existing methods (at least tc police,
preferably legacy NDO as well) to automatically populate the new API.  

Even if there is no netdevice to hook it to, because it does not exist?
I have to be missing something, sorry :/

What I'm saying is that we can treat the devlink rate API as a "lower
layer interface". A layer under the netdevs. That seems sensible and
removes the API duplication which otherwise annoys me.

We want drivers to only have to implement one API.

So when user calls the legacy NDO API it should check if the device has
devlink rate support, first, and try to translate the legacy request
into devlink rate.

Same for TC police as installed by the OvS offload feature that Simon
knows far more about than I do. IIRC we use a combination of matchall
and police to do shaping.

That way drivers don't have to implement all three APIs, only devlink
rate (four APIs if we count TC qdisc but I think only NFP uses that
one and it has RED etc so that's too much).

Does this help or am I still not making sense?

I think I got it now. But in our case, there is no change for the user,
as the netdev does not exist. So user still uses devlink rate uapi as
proposed by this patchset. Only internal kernel changes requested.
Correct?