On Sat Jan 28 2023, Vladimir Oltean wrote:
> I have one practical reason for doing this and one concerning correctness.
>
> The practical reason has to do with a follow-up patch, which aims to mix
> 2 sources of max_sdu (one coming from the user and the other automatically
> calculated based on TC gate durations @current link speed). Among those
> 2 sources of input, we must always select the smaller max_sdu value, but
> this can change at various link speeds. So the max_sdu coming from the
> user must be kept separated from the value that is operationally used
> (the minimum of the 2), because otherwise we overwrite it and forget
> what the user asked us to do.
>
> To solve that, this patch proposes that struct sched_gate_list contains
> the operationally active max_frm_len, and q->max_sdu contains just what
> was requested by the user.
>
> The reason having to do with correctness lies on the following
> observation: the admin sched_gate_list becomes operational at a given
> base_time in the future. Until then, it is inactive and applies no
> shaping, all gates are open, etc. So the queueMaxSDU dropping shouldn't
> apply either (this is a mechanism to ensure that packets smaller than
> the largest gate duration for that TC don't hang the port; clearly it
> makes little sense if the gates are always open).
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

Reviewed-by: Kurt Kanzenbach <kurt@linutronix.de>