netdev - Re: [RFC] [PATCH] Don't run __qdisc

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: <20090727.192844.163233275.davem@davemloft.net>
Date:	Mon, 27 Jul 2009 19:28:44 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	herbert@...dor.apana.org.au
Cc:	krkumar2@...ibm.com, jarkao2@...il.com, netdev@...r.kernel.org
Subject: Re: [RFC] [PATCH] Don't run __qdisc_run() on a stopped TX queue

From: Herbert Xu <herbert@...dor.apana.org.au>
Date: Sat, 25 Jul 2009 11:24:36 +0800

> Dave, remember our discussion about the benefits of using multiqueue
> TX just for the sake of enarlging the TX queues? How about just
> going back to using a single queue for non-default qdiscs (at
> least until such a time when non-default qdiscs start doing
> multiple queues internally)?
> 
> Yes it would mean potentially smaller queues for those non-default
> qdisc users, but they're usually the same people who want the
> hardware to queue as little as possible in order to enforce whatever
> it is that their qdisc is designed to enforce.

There is a locking benefit even for non-default qdiscs.

Instead of two choke points (qdisc lock and queue lock) there
is now only one (qdisc lock) and consdiering the cost of
things like setting up IOMMU mappings and hitting chip
registers the qdisc lock is the shortest held of the two.

So going to one queue would be a serious regression.
--
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