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: <0c1528838ebafdbe275ad69febb24b056895f94a.camel@redhat.com>
Date: Fri, 19 Apr 2024 13:53:53 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>
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, 2024-04-11 at 09:03 -0700, Jakub Kicinski wrote:
> On Thu, 11 Apr 2024 17:58:59 +0200 Paolo Abeni wrote:
> > 
> > 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.

I'm sorry for the latency, I got distracted elsewhere. 

It's not clear the benefit of introducing this 'attach points' concept.

With the current proposal, configuring a queue shaper would be:

info.bw_min = ...
dev->shaper_ops->set(dev, SHAPER_LOOKUP_BY_QUEUE, queue_id, &info, &ack);

and restoring the default could be either:

info.bw_min = 0;
dev->shaper_ops->set(dev, SHAPER_LOOKUP_BY_QUEUE, queue_id, &info, &ack);

or:

dev->shaper_ops->delete(dev, SHAPER_LOOKUP_BY_QUEUE, queue_id, &info, &ack);

With the 'attach points' I guess it will be something alike the
following (am not defining a different node type here just to keep the
example short):

# configure a queue shaper
struct shaper_info attach_info;
dev->shaper_ops->get(dev, SHAPER_LOOKUP_BY_QUEUE, queue_id, &attach_info, &ack);
info.parent_id = attach_info.id;
info.bw_min = ...
new_node_id = dev->shaper_ops->add(dev, &info, &ack);

# restore defaults:
dev->shaper_ops->delete(dev, SHAPER_LOOKUP_BY_TREE_ID, new_node_id, &info, &ack);

likely some additional operation would be needed to traverse/fetch
directly the actual shaper present at the attach points???

I think the operations will be simpler without the 'attach points', am
I missing something? 

A clear conventions/definition about the semantic of deleting shapers
at specific locations (e.g. restoring the default behaviour) should
suffice, together with the current schema.

Thanks,

Paolo