[Bloat] Measuring CoDel
Toke Høiland-Jørgensen
toke at toke.dk
Fri Jan 22 19:34:19 EST 2021
Hal Murray <hmurray at megapathdsl.net> writes:
> Toke said:
>> Yeah, the overhead of CoDel itself (and even FQ-CoDel) is basically nil (as
>> in, we have not been able to measure it), when otherwise doing forwarding
>> using the regular Linux stack.
>
> I may be able to help with that.
>
> Are you familiar with Dick Sites' KUtrace?
> Stanford Seminar - KUtrace 2020
> https://www.youtube.com/watch?v=2HE7tSZGna0
Nope - but from a quick glance it looks similar to what you can do with
'perf'? :)
> The catch is that I've never used CoDel so somebody will have to teach
> me how to setup a test environment, and then show me the chunks in the
> kernel you want to measure.
To measure the CoDel algorithm, I guess the thing to measure would be
codel_dequeue():
https://elixir.bootlin.com/linux/latest/source/include/net/codel_impl.h#L142
However, that has loops in it that depend on flow state, so its
execution time will vary some. For fq_codel it would be the
fq_codel_enqueue() and fq_codel_dequeue() functions, but they have a
similar problem:
https://elixir.bootlin.com/linux/latest/source/net/sched/sch_fq_codel.c
Also, the larger problem is that the overhead of these drown in all the
other processing the kernel does for each packet (none of the
queueing-related functions even register on a 'perf' report when
forwarding packets. Still, might be interesting to see, who knows? So
feel free to take a stab at it :)
-Toke
More information about the Bloat
mailing list