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

On Tue, 12 Jul 2022 08:03:40 +0200 Jiri Pirko wrote:

quoted

quoted

AFAIU the problem is that you want to control endpoints which are not
ndevs with this API. Is that the main or only reason? Can we agree that
it's legitimate but will result in muddying the netdev model (which in
itself is good and complete)?  

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