On Fri, 2 Aug 2024 18:15:32 +0200 Jiri Pirko wrote:

Thu, Aug 01, 2024 at 05:39:24PM CEST, kuba@kernel.org wrote:

quoted

On Thu, 1 Aug 2024 17:25:50 +0200 Paolo Abeni wrote:  

quoted

When deleting a queue-level shaper, the orchestrator is "returning" the 
ownership of the queue from the container to the host. If the container   

What do you meam by "orchestrator" and "container" here? I'm missing
these from the picture.

Container (as in docker) and orchestrator.

quoted

quoted

wants to move the queue around e.g. from:

q1 ----- \
q2 - \SP1/ RR1  

What "sp" and "rr" stand for. What are the "scopes" of these?

"scopes" I agree are confusing, but:

sp = strict priority
rr = round robin

quoted

quoted

q3 - /        \
     q4 - \ RR2 -> RR(root)
     q5 - /    /
     q6 - \ RR3
     q7 - /

to:

q1 ----- \
q2 ----- RR1
q3 ---- /   \
     q4 - \ RR2 -> RR(root)
     q5 - /    /
     q6 - \ RR3
     q7 - /

It can do it with a group() operation:

group(inputs:[q2,q3],output:[RR1])  

Isn't that a bit odd? The container was not supposed to know / care
about RR1's existence. We achieve this with group() by implicitly
inheriting the egress node if all grouped entities shared one.

Delete IMO should act here like a "ungroup" operation, meaning that:
1) we're deleting SP1, not q1, q2  

Does current code support removing SP1? I mean, if the scope is
detached, I don't think so.

that's my reading too, fwiw

quoted

2) inputs go "downstream" instead getting ejected into global level

Also, in the first example from the cover letter we "set" a shaper on
the queue, it feels a little ambiguous whether "delete queue" is
purely clearing such per-queue shaping, or also has implications 
for the hierarchy.

Coincidentally, others may disagree, but I'd point to tests in patch 
8 for examples of how the thing works, instead the cover letter samples.  

Examples in cover letter are generally beneficial. Don't remove them :)

They are beneficial, but if I was to order the following three forms of
documentation by priority:
 - ReST under Documentation/
 - clear selftests with comments
 - cover letter
I'm uncertain which will be first, but cover letter is definitely last
:(

With the examples in the cover letter its unclear what the expected
start and end state are. And where the values come from. I feel like
selftest would make it clearer.

But I don't feel strongly. Such newfangled ideas will take a while to
take root :)