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

[jamal <hadi@cyberus.ca>]

On Mon, 2007-11-06 at 15:03 +0200, Patrick McHardy wrote:
> jamal wrote:

> Well, its not.

I dont wanna go into those old style debates again; so lets drop this
point. 

> > Take a step back:
> > When you put a packet on the DMA ring, are you ever going to take it
> > away at some point before it goes to the wire? 
> 
> 
> No, 
> but its nevertheless not on the wire yet and the HW scheduler
> controls when it will get there. 
>
> It might in theory even never get
> there if higher priority queues are continously active.

Sure - but what is wrong with that? 
What would be wrong is in the case of contention for a resource like a
wire between a less important packet and a more important packet, the
more important packet gets favored.
Nothing like that ever happens in what i described.
Remember there is no issue if there is no congestion or contention for
local resources.

> > And if there is contention, the qdisc scheduler will do the right thing.
> 
> 
> That ignores a few points that were raised in this thread,
> 
> - you can treat each HW queue as an indivdual network device

You can treat a pair of tx/rx as a netdev. In which case none of this is
important. You instantiate a different netdev and it only holds the
appropriate locks.

> - you can avoid synchronizing on a single queue lock for
>   multiple TX queues

Unneeded if you do what i described. Zero changes to the qdisc code.

> - it is desirable to keep all queues full

It is desirable to keep resources fully utilized. Sometimes that is
achieved by keeping _all_ queues full. If i fill up a single queue full
and transmit at wire rate, there is no issue.

cheers,
jamal