Re: [RFC] HW TX Rate Limiting Driver API

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 11 Apr 2024 17:58:59 +0200 Paolo Abeni wrote:
> > In this contrived example we have VF1 which limited itself to 35G.
> > VF2 limited each queue to 100G and 200G (ignored, eswitch limit is lower)
> > and set strict priority between queues.
> > PF limits each of its queues, and VFs to 50G, no rate limit on the port.
> > 
> > "x" means we cross domains, "=" purely splices one hierarchy with another.
> > 
> > The hierarchy for netdevs always starts with a queue and ends in a netdev.
> > The hierarchy for eswitch has just netdevs at each end (hierarchy is
> > shared by all netdevs with the same switchdev id).
> > 
> > If the eswitch implementation is not capable of having a proper repr for PFs
> > the PF queues feed directly into the port.
> > 
> > The final RR node may be implicit (if hierarchy has loose ends, the are
> > assumed to RR at the last possible point before egress).  
> 
> Let me try to wrap-up all the changes suggested above:
> 
> - we need to clearly define the initial/default status (possibly no b/w
> limits and all the objects on the same level doing RR)
> 
> - The hierarchy controlled by the API should shown only non
> default/user-configured nodes
> 
> - We need to drop the references to privileged VFs.
> 
> - The core should maintain the full status of the user-provided
> configuration changes (say, the 'delta' hierarchy )
> 
> Am I missing something?

LG

> Also it's not 110% clear to me the implication of:
> 
> > consider netdev/queue node as "exit points" of the tree, 
> > to which a layer of actual scheduling nodes can be attached  
> 
> could you please rephrase a bit?
> 
> I have the feeling the the points above should not require significant
> changes to the API defined here, mainly more clear documentation, but
> I'll have a better look.

They don't have to be nodes. They can appear as parent or child of 
a real node, but they don't themselves carry any configuration.

IOW you can represent them as a special encoding of the ID field,
rather than a real node.