On Mon, 2007-11-06 at 16:49 +0200, Patrick McHardy wrote: > Let me explain with some ASCII art :)
Ok ;-> > We have n empty HW queues with a maximum length of m packets per queue: > > [0] empty > [1] empty > [2] empty > .. > [n-1] empty > Asumming 0 i take it is higher prio than n-1. > Now we receive m - 1 packets for each all priorities >= 1 and < n - 1, > so we have: > > [0] empty > [1] m - 1 packets > [2] m - 1 packets > .. > [n-2] m - 1 packets > [n] empty > > Since no queue is completely full, the queue is still active. and packets are being fired on the wire by the driver etc ... > Now we receive m packets of priorty n: n-1 (i think?) > [0] empty > [1] m - 1 packets > [2] m - 1 packets > .. > [n-2] m - 1 packets > [n-1] m packets > > At this point the queue needs to be stopped since the highest > priority queue is entirely full. ok, so 0 is lower prio than n-1 > To start it again at least > one packet of queue n - 1 needs to be sent, following so far ... > which (assuming > strict priority) requires that queues 1 to n - 2 are serviced > first. Ok, so let me revert that; 0 is higher prio than n-1. > So any prio 0 packets arriving during this period will > sit in the qdisc and will not reach the device for a possibly > quite long time. "possibly long time" is where we diverge ;-> If you throw the burden to the driver (as i am recommending in all my arguements so far), it should open up sooner based on priorities. I didnt wanna bring this earlier because it may take the discussion in the wrong direction. So in your example if n-1 shuts down the driver, then it is upto to the driver to open it up if any higher prio packet makes it out. > With multiple queue states we'd know that > queue 0 can still take packets. And with what i described you dont make any such changes to the core; the burden is on the driver. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
