netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jaume Catarineu <jaume.catarineu@upf.edu>
To: Dmitry Torokhov <dtor_core@ameritech.net>
Cc: hadi@cyberus.ca, "David S. Miller" <davem@redhat.com>,
	netdev@oss.sgi.com, Francois Romieu <romieu@fr.zoreil.com>
Subject: Re: Kernel BUG: Qos seg. fault
Date: Tue, 25 May 2004 02:06:25 +0000	[thread overview]
Message-ID: <40B2AA21.7080700@upf.edu> (raw)
In-Reply-To: <1085436571.1041.69.camel@jzny.localdomain>

Hi all,

After reading all your messages I share the Dmitry's point of view. It 
seems quite clear that implementing filters for TBF does not make sense. 
  However, if it is the case, it could be nice a warning message that 
informs the user about the weird command introduced.

Another option (a little more complicated) would be to "decay" 
automatically the filter to the TBF's child qdisc. That ougth to be 
announced to the user also and maybe it won't be allways possible (with 
the default noop_qdisc is useless, isn't it?).

I will take a tour into the source code :)

Actually, the original sequence must be rewrited to:
  tc qdisc add dev lo root handle 1: tbf rate 250kbit burst 5k limit 5k
  tc qdisc add dev lo parent 1: handle 20:  prio
  tc qdisc add dev lo parent 20:1 handle 210: sfq perturb 10
  tc qdisc add dev lo parent 20:2 handle 220: tbf rate 250kbit limit 5k 

  tc qdisc add dev lo parent 20:3 handle 230: sfq perturb 10

  tc filter add dev lo protocol ip parent 20: prio 1 handle 2 \
                                              fw flowid 20:3

The key is the "parent 20:" (not the original "parent 1:") in the filter 
line.

I must say that I got astonished viewing how quick you solved the quiz. 
Now I don't simply believe in free software, now I really TRUST in it.

Jaume,

  reply	other threads:[~2004-05-25  2:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-24 21:53 Kernel BUG: Qos seg. fault Dmitry Torokhov
2004-05-24 22:09 ` jamal
2004-05-25  2:06   ` Jaume Catarineu [this message]
2004-05-25  3:29   ` Kernel BUG: Qos seg. fault (part II) Jaume Catarineu
2004-05-25  2:08     ` jamal
2004-05-25 13:09       ` Jaume Catarineu
2004-05-25  7:07   ` Kernel BUG: Qos seg. fault Dmitry Torokhov
  -- strict thread matches above, loose matches on Subject: below --
2004-05-24 21:25 Dmitry Torokhov
2004-05-24 21:32 ` jamal
2004-05-24 21:42   ` jamal
2004-05-24 20:14 Dmitry Torokhov
2004-05-24 19:29 Dmitry Torokhov
2004-05-24 19:47 ` jamal
2004-05-24 11:57 Jaume Catarineu
2004-05-24 18:11 ` jamal
2004-05-24 19:19 ` Francois Romieu
2004-05-25  0:49   ` Jaume Catarineu

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=40B2AA21.7080700@upf.edu \
    --to=jaume.catarineu@upf.edu \
    --cc=davem@redhat.com \
    --cc=dtor_core@ameritech.net \
    --cc=hadi@cyberus.ca \
    --cc=netdev@oss.sgi.com \
    --cc=romieu@fr.zoreil.com \
    /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;
as well as URLs for NNTP newsgroup(s).