RE: PQ questions

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Christian,

Good morning, and thank you for proving me correct about how professional
and responsive people on this list are (sincerely). Brief comments in-line:

> -----Original Message-----
> From: Christian Benvenuti [mailto:christian.benvenuti@xxxxxxxxx]
> Sent: Thursday, June 21, 2007 4:23 PM
> To: Tim Enos
> Cc: lists@xxxxxxxxxxxxxxxxxxxxxxx; lartc@xxxxxxxxxxxxxxx
> Subject: Re: PQ questions
> 
> 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?

I mean that when saying something like:

"qdisc add dev eth0 parent 1:1 handle 10: prio limit 2"

you will get the following error (at least I do):

" What is "limit"? Usage: ... prio bands NUMBER priomap P1 P2..."

Changing the line like so works (and no error messages are generated):

"qdisc add dev eth0 parent 1:1 handle 10: prio"

> 
> > 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 ...

Yes.

> 
> 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?

The idea is that within each of the four priority classes/queues there would
be two queues: one of some very small length (say 2) and another of some
larger length (whatever the default is). So the thinking is that the traffic
(having been marked by the application say) hits the top-level queue. If the
traffic is marked EF, it will go into the highest priority queue. Once in
that queue, it will hit the first pfifo (which in this model is 2 packets
long). It will then hit the second pfifo queue before heading out onto the
wire.

The ultimate concern is to know how many packets are in each of the priority
queues at any given time.

> 
> 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

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux