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

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 28 Sep 2022 14:02:57 +0200 Wilczynski, Michal wrote:
> > 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).