Re: [PATCH] NET: Multiqueue network device support.

[jamal <hadi@cyberus.ca>]

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