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,
next prev parent 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).