Message-ID: <CAM0EoMnUm497YUZYbrYeqecF6JYzFbjauV8ACf-h8pjgOd2jdg@mail.gmail.com>
Date: Thu, 5 Feb 2026 16:30:06 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Paul Moses <p@....org>, netdev@...r.kernel.org, xiyou.wangcong@...il.com, 
	jiri@...nulli.us, davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, 
	pabeni@...hat.com, horms@...nel.org, linux-kernel@...r.kernel.org, 
	stable@...r.kernel.org, Vinicius Costa Gomes <vinicius.gomes@...el.com>
Subject: Re: [PATCH net] net: sched: act_api: size RTM_GETACTION reply by fill size

On Thu, Feb 5, 2026 at 3:36 PM Vladimir Oltean <vladimir.oltean@....com> wrote:
>
> On Thu, Feb 05, 2026 at 02:23:00PM -0500, Jamal Hadi Salim wrote:
> > On Thu, Feb 5, 2026 at 10:13 AM Paul Moses <p@....org> wrote:
> > >
> > > Looks like pedit might also affected. Hopefully this makes it more clear. Going to wait on more input before doing anything else with this.
> > >
> > > NLMSG_GOODSIZE = SKB_WITH_OVERHEAD(min(PAGE_SIZE, 8192))
> > > SKB_WITH_OVERHEAD(X) = X - SKB_DATA_ALIGN(sizeof(struct skb_shared_info))
> > > nla_total_size(payload) = NLA_ALIGN(NLA_HDRLEN + payload), with NLA_HDRLEN = 4 and 4 byte alignment
> > >
> > > Per entry size for the gate list:
> > >
> > > Each entry is a nested TCA_GATE_ONE_ENTRY plus five attributes:
> > >
> > > TCA_GATE_ONE_ENTRY (nest, no payload) -> 4
> > > INDEX (u32) -> 8
> > > GATE (flag, no payload) -> 4
> > > INTERVAL (u32) -> 8
> > > MAX_OCTETS (s32) -> 8
> > > IPV (s32) -> 8
> > >
> > > So one entry is:
> > >
> > > entry_sz = 4 + 8 + 4 + 8 + 8 + 8 = 40 bytes
> > >
> > > Fixed overhead for one act_gate dump:
> > >
> > > 1. Action wrapper (RTM_GETACTION):
> > >
> > > NLMSG_HDRLEN + sizeof(struct tcamsg) + nla_total_size(0)
> > > = 16 + 4 + 4 = 24 bytes
> > >
> > > 2. Action shared attributes emitted by tcf_action_dump_1, baseline only
> > >    (no cookie, no HW stats, no flags):
> > >
> > > TCA_ACT_KIND (IFNAMSIZ) = 20
> > > TCA_ACT_STATS nest = 4
> > > TCA_STATS_BASIC = 20
> > > TCA_STATS_PKT64 = 12
> > > TCA_STATS_QUEUE = 24
> > > TCA_ACT_OPTIONS nest = 4
> > > TCA_GACT_TM = 36
> > > TCA_ACT_IN_HW_COUNT = 8
> > > action number nest = 4
> > >
> > > Total shared baseline = 156 bytes
> > >
> > > Optional shared attributes, only if present:
> > >
> > > TCA_ACT_HW_STATS = +12
> > > TCA_ACT_USED_HW_STATS = +12
> > > TCA_ACT_FLAGS = +12
> > > TCA_ACT_COOKIE = +nla_total_size(cookie_len)
> > >
> > > 3. Gate specific attributes inside options, fixed part including TM:
> > >
> > > TCA_GATE_PARMS = 24
> > > BASE_TIME = 12
> > > CYCLE_TIME = 12
> > > CYCLE_TIME_EXT = 12
> > > CLOCKID = 8
> > > FLAGS = 8
> > > PRIORITY = 8
> > > ENTRY_LIST nest = 4
> > > TCA_GATE_TM = 36
> > >
> > > Total gate baseline = 124 bytes
> > >
> > > 4. 64 bit alignment padding, only when
> > >    !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> > >
> > > There are 7 attributes that trigger the 64 bit padding:
> > > -three stats blocks, three time values and the gate TM
> > > -Each adds 4 bytes, so add 28 bytes in that case
> > >
> > > Putting it together:
> > >
> > > fixed = 24 (wrapper) + 156 (shared baseline) + 124 (gate baseline)
> > > fixed = 304 bytes
> > >
> > > opt = nla_total_size(cookie_len)
> > > + 12 for each of HW_STATS, USED_HW_STATS and FLAGS if present
> > > + 28 if unaligned access padding is required
> > >
> > > The maximum number of entries that fit in a single skb is:
> > >
> > > Nmax = floor((NLMSG_GOODSIZE - fixed - opt) / 40)
> > >
> > > If PAGE_SIZE = 4096 and sizeof(struct skb_shared_info) = 320:
> > >
> > > NLMSG_GOODSIZE = 4096 - 320 = 3776
> > > Nmax = floor((3776 - 304) / 40) = 86
> > >
> > > 8192:
> > >
> > > NLMSG_GOODSIZE = 8192 - 320 = 7872
> > > Nmax = floor((7872 - 304) / 40) = 189
> > >
> >
> > Seems arbitrary and I was hoping you dont have to change iproute2
> > which restricts the total size to 1KB.
> > Earlier, unless i misread, you said you are looking at IEEE - what
> > does the spec say?
> > If i am not mistaken, the spec is   IEEE 802.1Qbv which unfortunately
> > is behind a paywall.
> > The closest i could find was a vendor talking about it here:
> > https://onlinedocs.microchip.com/oxy/GUID-82119957-1E11-4B69-84AC-EF0EA08F5595-en-US-5/GUID-7E7509A4-351E-4D82-8266-967681BA2644.html
> >
> > And they seem to indicate you can only have _one_ off and one timer
> > per queue, for a max of 8 queues.
> > Since Po is AWOL, +Cc the taprio folks (Vinicius, Vladmir).
> >
> > cheers,
> > jamal
>
> Sorry, I haven't been following this thread, I don't know what the
> question to me is?
>
> The tc-gate action corresponds to a feature which can be identified by
> the "stream gate" keyword in standard IEEE 802.1Q (-2018 or later).
> It is a sub-function of clause 8.6.5.1 Per-stream filtering and policing
> (PSFP).
>
> This is different from what you reference above as taprio / IEEE 802.1Qbv
> (old/obsolete name for workgroup which later became merged into standard
> 802.1Q as clause 8.6.8.4 Enhancements for scheduled traffic).
>
> The tc-gate is not defined per queue, but rather a standalone object
> that streams (tc filters) point to. The schedule (or "gate control list")
> size, translatable into the number of TCA_GATE_ONE_ENTRY elements, is
> arbitrary as far as the standard is concerned.
>
> We at NXP have hardware today which supports up to 256 gates in a single
> stream gate control list.

Yes, this kinda answers the question: we are looking for something
that serves as an upper bound for the control list.
Does the standard explicitly specify that it is arbitrary - or is that
deduced by lack of mention of an upper bound.
Either way imo  we need to have a "reasonable" upper bound in the code.

cheers,
jamal


> I'm not sure I understand the reference to the [number of] timers.

Powered by blists - more mailing lists