netdev - RE: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior

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: <1177594079.4077.37.camel@localhost>
Date:	Thu, 26 Apr 2007 09:27:59 -0400
From:	jamal <hadi@...erus.ca>
To:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
Cc:	Stephen Hemminger <shemminger@...ux-foundation.org>,
	netdev@...r.kernel.org, jgarzik@...ox.com,
	cramerj <cramerj@...el.com>,
	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>,
	"Leech, Christopher" <christopher.leech@...el.com>,
	davem@...emloft.net
Subject: RE: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior

On Wed, 2007-25-04 at 10:45 -0700, Waskiewicz Jr, Peter P wrote:
> > -----Original Message-----

> The previous version of my multiqueue patches I sent for consideration
> had feedback from Patrick McHardy asking that the user be able to
> configure the PRIO qdisc to run with multiqueue support or not.  That is
> why TC needed a modification, since I agreed with Patrick that this
> would be a useful option.

Patrick is a smart guy and I am almost sure he gave you that advice
based on how your kernel patches work. Since i havent looked at your
patches, I cant swear to that as a fact - hence the "almost"

> All the versions of multiqueue network device support I've sent for
> consideration had PRIO modified to support multiqueue devices, since it
> lends itself well for the model of multiple, independent flows.
> 

So it seems your approach is to make changes to every qdisc so you can
support device-multiq, no? This is what i suspected and was questioning
earlier, not the fact you had it in tc (which is a consequence).

My view is:
- the burden of the changes should be on the driver. A thin layer
between the qdisc and driver hw tx should help hide those changes from
the qdiscs; i.e i dont see why the kernel side qdisc needs to change.
The rest you leave to the user; if the user configures HTB for a
hardware that does multiq which is WRR, then that is their problem.
The driver should be configurable to be X num of queues via probably
ethtool. It should default to single ring to maintain old behavior.

> > BTW, is there any reason this is being cced to lkml?
> 
> Since this change affects how tc interacts with the qdisc layer, I cced
> lkml.

Ok, i see; none of those other intel people put you through the hazing
yet? ;-> This is a netdev matter - so i have taken off lkml

I will try to talk to the other gent to see if we can join into this
effort instead of a parallel one; the wireless cards have similar needs.
I plan to spend time looking at your approach (sorry, my brain likes to
work that way; otherwise i would have looked at it by now).

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