netdev - Re: [RFC] HW TX Rate Limiting Driver API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240411090325.185c8127@kernel.org>
Date: Thu, 11 Apr 2024 09:03:25 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Simon Horman <horms@...nel.org>, netdev@...r.kernel.org, Jiri Pirko
 <jiri@...nulli.us>, Madhu Chittim <madhu.chittim@...el.com>, Sridhar
 Samudrala <sridhar.samudrala@...el.com>
Subject: Re: [RFC] HW TX Rate Limiting Driver API

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.