netdev - Re: Not understand some in htb_do

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <478D2C85.2090008@cdi.cz>
Date:	Tue, 15 Jan 2008 22:58:29 +0100
From:	Martin Devera <devik@....cz>
To:	Patrick McHardy <kaber@...sh.net>
CC:	Badalian Vyacheslav <slavon@...telecom.ru>, netdev@...r.kernel.org
Subject: Re: Not understand some in htb_do_events function

> 
> So this was meant to protect against endless loops?
> 
>> We want way to smooth big burst of events over more dequeue invocations
>> in order to not slow dequeue too much. Constant 500 is max. allowed
>> "slowdown" of dequeue.
>> Any bright idea how to do it more elegant, Patrick ?
> 
> 
> Unfortunately not, but I believe simply removing the limit
> completely would be better than picking an arbitary value.

Grrr my comp crashed while I was writing this mail. Well the second
attempt.
When we allow unlimited events per dequeue, then there is case where
all N classes in qdisc can be in the event queue with the same target
time. Then they will all be acted on in the loop within single dequeue,
costing us say some milliseconds. Additionaly, it tends to repeat itself
then in cycles.
Maybe it is acceptable but it seemed to me as rather big latency.
Thus I wanted to do only limited work per dequeue call. One possibility
is to remove the limit and "see what happend in wild".

What do u think about to do limited no of transitions and then schedule
tasklet to do the rest (again in limited buckets) ?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html