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

When deleting a queue-level shaper, the orchestrator is "returning" the 
ownership of the queue from the container to the host. If the container 
wants to move the queue around e.g. from:

q1 ----- \
q2 - \SP1/ RR1
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
 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.

That will implicitly also delete SP1.