OSDN Git Service

net/sched: keep the max_frm_len information inside struct sched_gate_list
authorVladimir Oltean <vladimir.oltean@nxp.com>
Tue, 7 Feb 2023 13:54:37 +0000 (15:54 +0200)
committerDavid S. Miller <davem@davemloft.net>
Wed, 8 Feb 2023 09:48:53 +0000 (09:48 +0000)
commita878fd46fe43ec97f3f8664173fe1d23984c3453
treebddc47dcf86b4cb91c803c598e7514e4f287ca0c
parenta3d91b2c6f6b8ef88785bf8d2fba74916af6c7c5
net/sched: keep the max_frm_len information inside struct sched_gate_list

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 is based 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>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/sched/sch_taprio.c