From: "Andy Pyles" <apyles@telverse.com>
To: lartc@vger.kernel.org
Subject: RE: [LARTC] qdisc unbounding question
Date: Fri, 01 Jun 2001 19:14:34 +0000 [thread overview]
Message-ID: <marc-lartc-99142321807490@msgid-missing> (raw)
In-Reply-To: <marc-lartc-99140585213944@msgid-missing>
> -----Original Message-----
> From: Rodrigo Goya [mailto:rgoya@linuxcenter.com.mx]
> Sent: Friday, June 01, 2001 9:55 AM
> To: Linux Advanced Router & Traffic Control
> Subject: Re: [LARTC] qdisc unbounding question
>
>
> Hi,
>
> > > tc class add dev eth0 parent 1:170 classid 1:30 cbq
> bandwidth 200Kbit
> > > rate 30Kbit weight 3Kbit prio 6 allot 1514 cell 8
> maxburst 20 avpkt 1000
> >
> > Shouldn't the parent class be 1:1 instead of 1:170 ??
> >
> > I believe in the current scheme, 1:170 is child from 1:1
> and 1:30 a child
> > from 1:170. I think you want both 1:170 as 1:30 to be
> children from 1:1.
> >
>
> I agree with this.
>
> Also, shouldn't root qdisc 1:0 have full interface bandwidth?
> and then root
> class 1:1 have "bandwidth $TOTAL rate 200kbit bounded" ?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
< I'm throwing in the diagram again in for clarity >
<---- 170kbs 170kbs ------------>
if Dest. = 10.10.20.97 if Dest. = 10.10.30.3
(classid=170) (classid=171)
|------| |------
| eth0 | |eth1 |
| |-----| |
-------- -------
<------30kbs 30kbs --------------->
if Dest. = 10.10.20.95 if Dest. = 10.10.30.2
(classid=30) (classid=31)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ok.. I guess I could implement this. However, as it is now, I am
effectively keeping the
maximum bandwidth under 200kbs. So, I don't see a reason for it. Is
there one?
Let me clarify, I have been able to determine, through testing, that
these seperate classes are
indeed working. In other words, I am not able to exceed the bandwidth
limitations set in their seperate classes.
I.e. no more than 170kbs with dest ip= 10.10.20.97 AND no more than
30kbs if dest. ip = 10.10.20.95.
Now, the only problem I'm having is having is to allow class 30 to
borrow from it's parent class.
>
> Something else, isn't it necesary to have a qdisc for each
> interface? Right now
> it's 1:0 for eth0 and 1:0 for eth1, I don't know if this
> works, I've always
> done it using (for example) 1:0 for eth0 and 2:0 for eth1.
>
> If I'm off track please tell me =)
Ok. This definetly makes sense. I set this up. so that there is a new
qdisc classifier for each respective device
1:0 for eth0
2.0 for eth1
Unfortunately, I'm still back to square one. I Still can't seem to share
between classes.
Heres the latest revised output:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~
tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 200Kbit avpkt 1000
cell 8
tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 200Kbit rate
200Kbit weight 20Kbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000
tc qdisc add dev eth1 root handle 2:0 cbq bandwidth 200Kbit avpkt 1000
cell 8
tc class add dev eth1 parent 2:0 classid 2:1 cbq bandwidth 200Kbit rate
200Kbit weight 20Kbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000
tc class add dev eth0 parent 1:1 classid 1:170 cbq bandwidth 200Kbit
rate 170Kbit weight 17Kbit prio 5 allot 1514 cell 8 maxburst 20 avpkt
1000
tc qdisc add dev eth0 parent 1:170 tbf rate 170Kbit buffer 10Kb/8 limit
15Kb mtu 1500
tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst
10.10.20.97 flowid 1:170
tc class add dev eth1 parent 2:1 classid 2:171 cbq bandwidth 200Kbit
rate 170Kbit weight 17Kbit prio 5 allot 1514 cell 8 maxburst 20 avpkt
1000
tc qdisc add dev eth1 parent 2:171 tbf rate 170Kbit buffer 10Kb/8 limit
15Kb mtu 1500
tc filter add dev eth1 parent 2:0 protocol ip prio 100 u32 match ip dst
10.10.30.3 flowid 2:171
tc class add dev eth0 parent 1:1 classid 1:30 cbq bandwidth 200Kbit rate
30Kbit weight 3Kbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000
tc qdisc add dev eth0 parent 1:30 tbf rate 30Kbit buffer 10Kb/8 limit
15Kb mtu 1500
tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst
10.10.20.95 flowid 1:30
tc class add dev eth1 parent 2:1 classid 2:31 cbq bandwidth 200Kbit rate
30Kbit weight 3Kbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000
tc qdisc add dev eth1 parent 2:31 tbf rate 30Kbit buffer 10Kb/8 limit
15Kb mtu 1500
tc filter add dev eth1 parent 2:0 protocol ip prio 100 u32 match ip dst
10.10.30.2 flowid 2:31
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/
next prev parent reply other threads:[~2001-06-01 19:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-01 14:25 [LARTC] qdisc unbounding question Andy Pyles
2001-06-01 16:30 ` Wingtung.Leung
2001-06-01 16:55 ` Rodrigo Goya
2001-06-01 19:14 ` Andy Pyles [this message]
2001-06-07 7:11 ` Stef Coene
2001-06-07 7:11 ` Stef Coene
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=marc-lartc-99142321807490@msgid-missing \
--to=apyles@telverse.com \
--cc=lartc@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 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.