Thread (153 messages) 153 messages, 21 authors, 2007-06-28

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

From: jamal <hidden>
Date: 2007-06-11 13:30:04

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. 
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help