[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240801074015.33c7fdef@kernel.org>
Date: Thu, 1 Aug 2024 07:40:15 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, 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 02/12] netlink: spec: add shaper YAML spec
On Thu, 1 Aug 2024 15:10:50 +0200 Jiri Pirko wrote:
> >+ -
> >+ name: netdev
> >+ doc: The main shaper for the given network device.
> >+ -
> >+ name: queue
> >+ doc: The shaper is attached to the given device queue.
> >+ -
> >+ name: detached
> >+ doc: |
> >+ The shaper is not attached to any user-visible network
> >+ device component and allows nesting and grouping of
> >+ queues or others detached shapers.
>
> What is the purpose of the "detached" thing?
FWIW I also find the proposed model and naming confusing, but didn't
want to object too hard in case it was just me. The model conflates
attachment points with shapers themselves, and (which perhaps is more
subjective) shapers with mux nodes.
This is already visible in the first example of the cover letter:
./tools/net/ynl/cli.py --spec Documentation/netlink/specs/shaper.yaml \
--do set --json '{"ifindex":'$IFINDEX',
"shaper": {"handle":
{"scope": "queue", "id":'$QUEUEID' },
"bw-max": 2000000 }}'
We are "set"ting a shaper on a queue, not "add"ing it, because
all attachment points implicitly have shapers(?) In my mind attachment
points is where traffic comes from or goes to, shapers must be created
to exist. And _every_ shaper has an ingress and egress, not just the
ones in the middle (i.e. which aren't directly next to an attachment
point) :(
Powered by blists - more mailing lists