Re: [PATCH v3 04/12] net-shapers: implement NL set and delete operations

[Jakub Kicinski <kuba@kernel.org>]

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:
> >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   
> 
> What do you meam by "orchestrator" and "container" here? I'm missing
> these from the picture.

Container (as in docker) and orchestrator.

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

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

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