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@andyfurniss.entadsl.com]
> > Sent: Tuesday, June 19, 2007 6:17 PM
> > To: Tim Enos
> > Cc: 'Christian Benvenuti'; lartc@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.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
|