[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