From: Patrick McHardy <kaber@trash.net>
To: Martin Devera <devik@cdi.cz>
Cc: Badalian Vyacheslav <slavon@bigtelecom.ru>, netdev@vger.kernel.org
Subject: Re: Not understand some in htb_do_events function
Date: Wed, 16 Jan 2008 06:15:34 +0100 [thread overview]
Message-ID: <478D92F6.6070201@trash.net> (raw)
In-Reply-To: <478D2C85.2090008@cdi.cz>
Martin Devera wrote:
>>
>> 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.
I see.
> 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) ?
Alternatively we could just remove the printk and do what you
suggested first, return q->now + 1 to immediately continue
processing, but send out a packet first.
next prev parent reply other threads:[~2008-01-16 5:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-15 10:11 Not understand some in htb_do_events function Badalian Vyacheslav
2008-01-15 10:15 ` Patrick McHardy
2008-01-15 11:59 ` Martin Devera
2008-01-15 13:51 ` Badalian Vyacheslav
2008-01-15 13:54 ` Martin Devera
2008-01-15 15:54 ` Patrick McHardy
2008-01-15 21:58 ` Martin Devera
2008-01-16 5:15 ` Patrick McHardy [this message]
2008-01-16 5:07 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=478D92F6.6070201@trash.net \
--to=kaber@trash.net \
--cc=devik@cdi.cz \
--cc=netdev@vger.kernel.org \
--cc=slavon@bigtelecom.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.