[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240801083924.708c00be@kernel.org>
Date: Thu, 1 Aug 2024 08:39:24 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, Jiri Pirko <jiri@...nulli.us>, Madhu Chittim
<madhu.chittim@...el.com>, Sridhar Samudrala <sridhar.samudrala@...el.com>,
Simon Horman <horms@...nel.org>, John Fastabend <john.fastabend@...il.com>,
Sunil Kovvuri Goutham <sgoutham@...vell.com>, Jamal Hadi Salim
<jhs@...atatu.com>
Subject: Re: [PATCH v3 04/12] net-shapers: implement NL set and delete
operations
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.
Powered by blists - more mailing lists