netdev - Re: [RFC PATCH net-next 12/15] net/sched: keep the max_frm_len information inside struct sched_gate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87zga2ualr.fsf@kurt>
Date:   Sat, 28 Jan 2023 13:06:40 +0100
From:   Kurt Kanzenbach <kurt@...utronix.de>
To:     Vladimir Oltean <vladimir.oltean@....com>, netdev@...r.kernel.org
Cc:     Vinicius Costa Gomes <vinicius.gomes@...el.com>
Subject: Re: [RFC PATCH net-next 12/15] net/sched: keep the max_frm_len
 information inside struct sched_gate_list

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@....com>

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

Download attachment "signature.asc" of type "application/pgp-signature" (862 bytes)