[LARTC] Re: PQ questions

[Christian Benvenuti]

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 at andyfurniss.entadsl.com]
> > Sent: Tuesday, June 19, 2007 6:17 PM
> > To: Tim Enos
> > Cc: 'Christian Benvenuti'; lartc at mailman.ds9a.nl
> > Subject: Re: [LARTC] 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.