lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 11 Jun 2007 15:03:11 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	hadi@...erus.ca
CC:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
	davem@...emloft.net, netdev@...r.kernel.org, jeff@...zik.org,
	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>
Subject: Re: [PATCH] NET: Multiqueue network device support.

jamal wrote:
> On Mon, 2007-11-06 at 14:39 +0200, Patrick McHardy wrote:
> 
>>>Sure. Packets stashed on the any DMA ring are considered "gone to the
>>>wire". That is a very valid assumption to make.
>>
>>
>>I disagree, its obviously not true 
> 
> 
> Patrick, you are making too strong a statement.


Well, its not.

> 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.

>>and leads to the behaviour I
>>described. If it were true there would be no reason to use multiple
>>HW TX queues to begin with.
> 
> 
> In the general case, they are totaly useless.
> They are  useful when theres contention/congestion. Even in a shared
> media like wireless. 


The same is true for any work-conserving queue, software or hardware.

> 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 avoid synchronizing on a single queue lock for
  multiple TX queues
- it is desirable to keep all queues full
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists