Re: [PATCH net-next v3 4/5] net/sched: sch_taprio: cap the number of schedule entries

[netdev-bot+sashiko@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] sch_taprio: hardware capability regression for SJA1110 due to
  1024 entry cap

--

> diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
> --- a/net/sched/sch_taprio.c
> +++ b/net/sched/sch_taprio.c
> @@ -49,6 +49,13 @@ static struct static_key_false taprio_have_working_mqprio;
>   */
>  #define TAPRIO_PICOS_PER_BYTE_MIN 17
>  
> +/* Each entry is a separate 368-byte sched_entry and, in full offload, is
> + * also composed into a per-entry offload array. The u16 nla_len admits
> + * roughly 5460 minimal 12-byte entries, pinning ~2 MiB; 1024 matches the
> + * SJA1105 schedule-table capacity (SJA1110 provides 4096) and the act_gate cap.
> + */
> +#define TAPRIO_ENTRIES_MAX	1024U
> +
>  struct sched_entry {
>  	/* Durations between this GCL entry and the GCL entry where the
>  	 * respective traffic class gate closes

[Severity: Medium]
The commit message notes that the SJA1110 schedule table holds 4096
entries, but TAPRIO_ENTRIES_MAX is set to 1024.

Before this patch, a user could install and offload a taprio schedule
with anywhere from 1025 up to the SJA1110 hardware limit. With this
patch, parse_sched_list() fails those same configurations with -E2BIG
before the driver ever sees them. So a working full-offload setup on
SJA1110 stops installing after an upgrade. The commit message calls
this net-next hardening, but it is still a user-visible regression for
that hardware.

Why was 1024 chosen over 4096? Is it only to match the act_gate cap?
The allocation concern in the changelog would still be well bounded at
4096. Drivers that offload already have to check the entry count
against their own table size, so a software-side cap at the largest
known hardware capacity seems sufficient.

If 1024 is intentional, for example because schedules above roughly
900 entries cannot be dumped anyway, could the changelog say that
explicitly? It should state that SJA1110 users with more than 1024
entries will be broken by this change.

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/QDISC-H19Z.v3.r0.20261012193813%40mojatatu.com