From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leonardo Balliache Date: Wed, 09 Jul 2003 03:35:02 +0000 Subject: RE: [LARTC] Question on prio qdisc Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: lartc@vger.kernel.org Hi, Joseph: At 03:31 p.m. 08/07/03 -0400, you wrote: >I understand your point, but I have tried to determine >the answers to a couple of questions from the code >without success (I don't understand the source code >well enough). Maybe you could answer these: >1) If I specify a queue length for the interface >by configuring "txqueuelen" to some number (say 1000), then >does that mean that the 3 FIFO queues for the 3 bands >in either "prio" scheduler or the default "pfifo_fast" scheduler are set e= ach >to a size of 1000 packets? If this is the case, then I don't >see how my high priority queue can drop packets when the high >priority flow rate is well below what the link can support. >Can you think of any reason this should happen? Have a look to a previous e-mail I answered to Lars. Reason? What=B4s the=20 entering rate? What's the departing rate? The queue will be filled to a=20 rate defined by the difference between those rates. >2) My testing leads me to believe that there are 3 queues, >but the buffer allocated for a new packet enqueued to >any of the queues is allocated from a common pool of buffers >that might be of size equal to "txqueuelen" =3D 1000. Is it >possible that it is implemented this way? I could see >high priority packets being dropped if this was the >implementation? >****************************************** No, again, have a look to a previous e-mail I sent to Lars. Best regards, Leonardo Balliache Here you have a copy of Lars' e-mail: I'm not very sure if the total queue length is 100 or 300 because I was searching the code and I can't find any information that tell me what the real length is. Because "ip link" shows me that qlen is 100, I have to suppose that total length is 100. But anyway, PRIO queing discipline principle calls that each priority queue is independent, then we can't have the prio 0 queue full of prio 1 or 2 packets (being the filters working well). It goes against the PRIO queuing discipline principle. In "Differentiated Service on Linux HOWTO" (work in progress) I present a PRIO queuing discipline explanation using some documentation taken from Juniper Networks. Have a look at http://opalsoft.net/qos. Also if you read about Cisco PQ the principle is identical. If we don't respect the principle, then the queue can be any sort of queue, but certainly, not a PRIO queue. Then it=B4s not posible to ask on PRIO for som= ething that drops an already enqueue packet to make run for a new arriving one. I suggest that configurations and tests made to reach that conclusions were= =20 revised. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/