---------- Forwarded message ---------
From: Toke Høiland-Jørgensen <t...@redhat.com>
Dave Taht <dave.t...@gmail.com> writes:
> Is it a delusional dream to want to poll tc -s qdisc show of 40k
> instances of cake on a htb tree every 10ms?
>
> presently 10k takes about 290us (locked to one cpu), and I have no
> idea what to look for while doing that.
So that's dumping all of them sequentially? In a single dump call from
the root, or multiple calls? Assuming sequentially, that works out to 29
nanoseconds per instance, which I'd say that was pretty good...
Looks like Eric already optimised the stat dumping in:
edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in
qdisc/class stats dump")
So it doesn't take the qdisc lock at all, unless you're also dumping the
class (per-flow) stats in the case of sch_cake.
As a side note, this may mean that the cake stats can suffer from
load tearing on 32-bit systems, since it's just doing a regular
unprotected read of everything, including the 64-bit counters...
-Toke
--
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC
_______________________________________________
LibreQoS mailing list
LibreQoS@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/libreqos
