[Bloat] Measuring CoDel

[Bloat] Measuring CoDel

[Hal Murray]

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

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.

-- 
These are my opinions.  I hate spam.

Re: [Bloat] Measuring CoDel

[Toke Høiland-Jørgensen]

Hal Murray <hmurray@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

Re: [Bloat] Measuring CoDel

[Jesper Dangaard Brouer]

On Sat, 23 Jan 2021 01:34:19 +0100
Toke Høiland-Jørgensen via Bloat <bloat@lists.bufferbloat.net> wrote:

> Hal Murray <hmurray@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'? :)

Yes, but the 'perf' tool (mostly) uses sampling.

I assume you want to catch latency outliers, right?

I would probably recommend that you play with bpftrace[1], for
processing all the events to catch the outliers.

 [1] https://github.com/iovisor/bpftrace

As an example look at this bpftrace script[2], that I used for
detecting latency issues, network hardIRQ-to-softirq latency.

 [2] https://github.com/xdp-project/xdp-project/blob/master/areas/latency/softirq_net_latency.bt
-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer