On 8/2/24 18:15, 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.

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?

The scope is 'detached'

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.

The current code explicitly prevents the above. We can change such 
behavior, if there is agreement.

My understanding is that Donald is against such option.

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 :)

No problem to keep both examples and self-tests.

Thanks,

Paolo