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

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1181568598.4043.250.camel@localhost>
Date:	Mon, 11 Jun 2007 09:29:58 -0400
From:	jamal <hadi@...erus.ca>
To:	Patrick McHardy <kaber@...sh.net>
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.

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

-
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