netdev - Re: [PATCH 3/3] pkt_sched: restore multiqueue prio scheduler

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]

Date:	Sun, 24 Aug 2008 09:39:23 -0400
From:	jamal <hadi@...erus.ca>
To:	Jarek Poplawski <jarkao2@...il.com>
Cc:	Alexander Duyck <alexander.duyck@...il.com>,
	David Miller <davem@...emloft.net>,
	jeffrey.t.kirsher@...el.com, jeff@...zik.org,
	netdev@...r.kernel.org, alexander.h.duyck@...el.com
Subject: Re: [PATCH 3/3] pkt_sched: restore multiqueue prio scheduler

On Sun, 2008-24-08 at 09:53 +0200, Jarek Poplawski wrote:
> On Sat, Aug 23, 2008 at 12:09:42PM -0700, Alexander Duyck wrote:
 
> > I think you missed the email from Dave earlier, either that or I am
> > not understanding something and if I am feel free to explain.  My
> > understanding is that when we assign a new qdisc via tc the
> > qdisc/transmit queues end up with a configuration kind of like what
> > Dave has on slide 7 at
> > (http://vger.kernel.org/~davem/davem_seattle08.pdf).  Adding more
> > queues doesn't resolve anything since I am still going through the
> > same qdisc regardless of how many queues I have.  The changes to the
> > dequeue portion of this qdisc are the most important part for this
> > change since I need them to keep the qdisc from jamming up in a
> > dequeue/requeue loop if the packet at the head of the qdisc needs to
> > go to a stopped hardware transmit queue.
> 
> I guess, Jamal meant additional, backup queues, 

right; in the driver - but even that may be unnecessary.
With current controls being per qdisc instead of per netdevice,
the hol fear is unfounded. 
You send and when hw cant keep up, you block just the one hwqueue.
While hwqueue is blocked, you can accumulate packets in the prio qdisc
(hence my statement it may not be necessary to accumulate packets in
driver).
On tx completion when hwqueue has more space, you check your backup
queues; and send those first before opening up path from above. 

And to your other statement; if you use basic skb->priority to hwqueue
mapping, then you wouldnt need an extra action. 

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