Hi Tim, Andy, On Wed, 2007-06-20 at 19:07 -0400, Tim Enos wrote: > It's PQ that is required. Here is what I have for config so far: > > tc qdisc add dev eth0 root handle 1: prio bands 4 priomap 0 1 2 3 Is "priomap 0 1 2 3" what you want/need or just a random mapping? (this is the default mapping that is used when none of the filters matches) > tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 match ip tos 0xb8 > 0xff flowid 1:1 > > tc filter add dev eth0 parent 1:0 prio 2 protocol ip u32 match ip tos 0x50 > 0xff flowid 1:2 > > tc filter add dev eth0 parent 1:0 prio 3 protocol ip u32 match ip tos 0x28 > 0xff flowid 1:3 > > tc filter add dev eth0 parent 1:0 prio 4 protocol ip u32 match ip tos 0x00 > 0xff flowid 1:4 > > > tc qdisc add dev eth0 parent 1:1 handle 10: pfifo limit 2 > > tc qdisc add dev eth0 parent 1:2 handle 11: pfifo limit 2 > > tc qdisc add dev eth0 parent 1:3 handle 12: pfifo limit 2 > > tc qdisc add dev eth0 parent 1:4 handle 13: pfifo limit 2 > > __________ > > The above config works fine. The last four qdisc lines (handles 10: - 13: > inclusive) also work as prio if you leave out the 'limit' part of course. What do you mean? > The remaining part is to set children for the last four qdiscs (one for > each). Said children qdiscs would have all the same attributes (as the > parents (limit is something I'd change; the '2' is just an example). Is this > possible? Do you mean something like this? tc qdisc add dev eth0 parent 10: handle 100: prio ... tc qdisc add dev eth0 parent 11: handle 110: prio ... tc qdisc add dev eth0 parent 12: handle 120: prio ... tc qdisc add dev eth0 parent 13: handle 130: prio ... Why would you need to put a pfifo qdisc between the two prio qdisc? Wouldn't it be better to have prio -> prio OR prio -> prio -> pfifo instead of prio -> pfifo -> prio ? What criteria are you going to use to assign the right priority to the packets in the nested (i.e., 2nd level) prio qdisc? Regards /Christian [ http://benve.info ] > > -----Original Message----- > > From: Andy Furniss [mailto:lists@xxxxxxxxxxxxxxxxxxxxxxx] > > Sent: Tuesday, June 19, 2007 6:17 PM > > To: Tim Enos > > Cc: 'Christian Benvenuti'; lartc@xxxxxxxxxxxxxxx > > Subject: Re: Re: PQ questions > > > > Tim Enos wrote: > > > Cool, > > > > > > Thanks Christian! I'm wishing that all of those same params showed up in > > the > > > output without having to run anything. No problem. Should it matter that > > I'm > > > using an emulated interface? > > > > Quite possibly - using prio on real devices still can appear not to work > > until you have filled up any buffer the driver uses. > > > > On my 100meg eth it would take 5/6 unscaled tcp connections to fill > > enough for prio to do anything. > > > > You can use prio as a child of hfsc/htb so that they set the rate. It > > may be nicer to use htb's own prio though, if you need a slow rate and > > care about latency. > > > > Andy. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
