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 each 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´s the entering rate? What's the departing rate? The queue will be filled to a 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" = 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´s not posible to ask on PRIO for something 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 revised.
