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: <1219510193.4732.26.camel@localhost>
Date:	Sat, 23 Aug 2008 12:49:53 -0400
From:	jamal <hadi@...erus.ca>
To:	Alexander Duyck <alexander.duyck@...il.com>
Cc:	Jarek Poplawski <jarkao2@...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 Sat, 2008-23-08 at 09:31 -0700, Alexander Duyck wrote:

> Actually in this new multiple tx queue kernel this qdisc could serve a
> very specific but needed purpose which just became apparent to me.
> This qdisc resolves one very specific issue, head-of-line blocking if
> one of the hardware queues is full.  What if I reversed things a bit
> in prio_classify so that skb->queue_mapping determined the band
> instead of the other way around in the case of the multiqueue option
> being enabled?  I would think that in this configuration the qdisc
> would prove to be pretty useful for purposes other than QOS since it
> would allow a classful qdisc per transmit queue instead of per device.
> 

i think thats whats Dave is saying not in so many words.

prio_classify calls classifiers.
dont modify the qdisc; rather do a classification which when matched
sets skb->queue_mapping to a value your policy likes it to be.  
you dont need a new classifier, u32 would do for example. or ematch if
you want to do some funky things. you will need a new action which sets
the skb->queue_mapping.

> I could then create a select_queue for the device that returns 0 when
> in DCB/EEDC mode for our drivers, implement the tc action to set the
> queue mapping, and have essentially the same result as I had before.
> 

put overflow queues in your driver. With the new multiq approach the
controls are per-queue not per driver.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ