netdev - Re: [RFC PATCH net-next 06/15] net/sched: taprio: calculate tc gate durations

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]

Date:   Sat, 28 Jan 2023 13:05:09 +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 06/15] net/sched: taprio: calculate tc gate
 durations

On Sat Jan 28 2023, Vladimir Oltean wrote:
> Current taprio code operates on a very simplistic (and incorrect)
> assumption: that egress scheduling for a traffic class can only take
> place for the duration of the current interval, or i.o.w., it assumes
> that at the end of each schedule entry, there is a "gate close" event
> for all traffic classes.
>
> As an example, traffic sent with the schedule below will be jumpy, even
> though all 8 TC gates are open, so there is absolutely no "gate close"
> event (effectively a transition from BIT(tc)==1 to BIT(tc)==0 in
> consecutive schedule entries):
>
> tc qdisc replace dev veth0 parent root taprio \
> 	num_tc 2 \
> 	map 0 1 \
> 	queues 1@0 1@1 \
> 	base-time 0 \
> 	sched-entry S 0xff 4000000000 \
> 	clockid CLOCK_TAI \
> 	flags 0x0
>
> This qdisc simply does not have what it takes in terms of logic to
> *actually* compute the durations of traffic classes. Also, it does not
> recognize the need to use this information on a per-traffic-class basis:
> it always looks at entry->interval and entry->close_time.
>
> This change proposes that each schedule entry has an array called
> tc_gate_duration[tc]. This holds the information: "for how long will
> this traffic class gate remain open, starting from *this* schedule
> entry". If the traffic class gate is always open, that value is equal to
> the cycle time of the schedule.
>
> We'll also need to keep track, for the purpose of queueMaxSDU[tc]
> calculation, what is the maximum time duration for a traffic class
> having an open gate. This gives us directly what is the maximum sized
> packet that this traffic class will have to accept. For everything else
> it has to qdisc_drop() it in qdisc_enqueue().
>
> 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)