Re: [Codel] [PATCH v5] pkt_sched: codel: Controlled Delay AQM

[Dave Taht <dave.taht@gmail.com>]

On Sat, May 5, 2012 at 10:07 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sat, 2012-05-05 at 09:11 -0700, Dave Taht wrote:
>> Nice!
>>
>> Nits:
>>
>> 0) I figure you already have an iproute2 patch that you can send?
>>     I thought 5 hours ago I had almost, but not entirely grokked netlink.
>>     The way you just did it was not at all how I thought it worked. :/
>>     but I will read.
>
>
> I'll send it ( I am currently with friends ...), but you dont need it to
> use codel with default params :
>
> qdisc add dev $DEV parent 1:1 handle 10: est 1sec 4sec codel

yep.

>> 1) I take it if a limit is not specified or set here, sch->limit comes
>> from txqueuelen?
>
> No, you set a default limit of 1000 in your patch

If I didn't set that at all, where does it come from?

(never mind I can find it, enjoy your saturday!)

>
>>     I do kind of like infinite queues (and angels dancing on the heads of pins)
>> 2) I woke up with a mod that could do ecn. I'll do an rfc patch
>
> Not sure it can play, if all packets are ECN, you need to drop at some
> point.

Yea, that's where blue had a few ideas, but the right thing is to setup
some long rtts and see what happens.

>> .
>> 3) Tom's already on the list
> ok
>> 4) I'd like to play with this a lot (and have others do so too) before
>> it goes upstream,
>>     gain kathie and vans blessing, etc. Couple weeks? (see 2). In
>> particular I was
>>     hoping to see actual pings under load match the target setting.
>> I'll get this
>>     going on two boxes and see what happens... play with bql, htb, etc...
>
> Hey, you'll send the patch when ready.

ok!

>
>> 5) thought the * 16 could be efficiently implemented by the compiler,
>> and saves a mem
>>     access.
>
> Well, just see the code on x86_32, the ktime conversion is expensive.
> Access to memory is free since cache line is already in cpu cache.

on everything but the x86_32 (do people still use that? :)). I would think
on the x86_64 and mips (16 bit memory bus) would be cheaper...
but it's rather a nit regardless.

>
> By the way, I found the precalculated array of 64 values is not really
> useful, we have q->count > 64 most of the time with 2 flows.

yea, just noticed that. I figured 25 wasn't enough, didn't think 64 was
either. will get some data on various flows and find a better value.

>
>> 6) unless 2) happens we can kill q->flags
>
> Yes

Enjoy your saturday!
>
>
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net