Re: [RFC PATCH net-next v4 2/6] devlink: Extend devlink-rate api with queues and new parameters

On Wed, 28 Sep 2022 14:02:57 +0200 Wilczynski, Michal wrote:

quoted

AFAIU you only want to cater to simple cases where the VF and PF
are in the same control domain, which is not normal, outside of
running DPDK apps. Sooner or later someone will ask for queuing
control from the VFs and you're have to redesign the whole thing.  

Hmm, so I guess the queue part of this patch is not well liked.
I wonder if I should re-send this patch with just the implementation
of devlink-rate, and minor changes in devlink, like exposing functions,
so the driver can export initial configurations. This still brings some 
value,
cause the user would still be able to modify at least the upper part of the
tree.

Sounds good to me. I don't think we ever had a general discussion
about what should the driver do in terms of exposing the initial
configuration. I can't think of a reason why we wouldn't do that
so please repost and let's see what others think!

We can still discuss how the final solution should look like, but i'm 
out of ideas when it comes for a inside VF interface, (like we
discussed tc-htb in current form doesn't really work for us).