public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Werner Almesberger <wa@almesberger.net>
To: ashwani kumar mehra <ashwani_mehra@rediffmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: CBQ implementation issues on linux
Date: Sun, 15 Sep 2002 03:16:33 -0300	[thread overview]
Message-ID: <20020915031633.C3352@almesberger.net> (raw)
In-Reply-To: <20020819141916.15289.qmail@webmail27.rediffmail.com>; from ashwani_mehra@rediffmail.com on Mon, Aug 19, 2002 at 02:19:16PM -0000

ashwani kumar mehra wrote:
> iii) A late 1999 doc that i found on the web says the  dequeue 
> code is also invoked via qdisc_run_queues (in sch_generic.c), thru 
> a bottom half handler(net_bh). but am unable to locate it in the 
> 2.4.18 code. am i missing something obvious or has the same been 
> reimplemented using tasklets/soft interrupts? maybe a call to 
> qdisc_restart?

This has changed a little. You may want to have a look at the
updated yet unfinished version of that ancient document:

ftp://icaftp.epfl.ch/pub/people/almesber/junk/tc-04FEB2001-0.tar.gz
(file tc/tc.ps)

Be warned that this "updated version" is for 2.4.0, so it's not
all that up to date anymore. But then, the traffic control code
hasn't changed very much in 2.4.

> 1. buffering at driver level: large buffering at driver level may 
> negate the effect of the scheduler by delaying higher priority 
> packets. ALTQ uses a token bucket regulator after the scheduler to 
> counter this problem. however i've been unable to find something 
> similar or any comment on this issue with regards to linux.

You could use something acting as a shaper (i.e. CBQ or HTB)
as the root qdisc, then cram all the other queuing inside it.

> 2. timer granularity issues: a driver will only interrupt after 
> its buffer gets emptied. however the scheduler may be invoked in 
> between by trigerring it on events like packet enqueue, expiry of 
> watchdog timers, etc. In case of timer expiry events, the timer 
> granularity remains 10 ms, so wont this lead to a bursty dequeue 
> on the next timer tick?

Yes, it does :-( Increasing HZ helps a little, and so do the
opportunistic checks (i.e. trying to dequeue whenever we're
handling an interrupt anyway). Unfortunately, the latter don't
improve worst-case burstiness, which is an issue if the next
network element in the path happens to be particularly picky.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/

      reply	other threads:[~2002-09-16  1:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-19 14:19 CBQ implementation issues on linux ashwani kumar mehra
2002-09-15  6:16 ` Werner Almesberger [this message]

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=20020915031633.C3352@almesberger.net \
    --to=wa@almesberger.net \
    --cc=ashwani_mehra@rediffmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox