All of lore.kernel.org
 help / color / mirror / Atom feed
From: jamal <hadi@cyberus.ca>
To: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>,
	netdev@vger.kernel.org, jgarzik@pobox.com,
	cramerj <cramerj@intel.com>,
	"Kok, Auke-jan H" <auke-jan.h.kok@intel.com>,
	"Leech, Christopher" <christopher.leech@intel.com>,
	davem@davemloft.net
Subject: RE: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior
Date: Thu, 26 Apr 2007 09:27:59 -0400	[thread overview]
Message-ID: <1177594079.4077.37.camel@localhost> (raw)
In-Reply-To: <D5C1322C3E673F459512FB59E0DDC32902B96813@orsmsx414.amr.corp.intel.com>

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 



  reply	other threads:[~2007-04-26 13:28 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-25  1:39 [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior Peter P Waskiewicz Jr
2007-04-25  4:05 ` Stephen Hemminger
2007-04-25 11:36   ` jamal
2007-04-25 17:45     ` Waskiewicz Jr, Peter P
2007-04-26 13:27       ` jamal [this message]
2007-04-26 15:57         ` Patrick McHardy
2007-04-26 16:30           ` Waskiewicz Jr, Peter P
2007-04-26 16:44             ` Patrick McHardy
2007-04-26 16:50               ` Waskiewicz Jr, Peter P
2007-04-27 15:09             ` jamal
2007-04-27 15:45               ` Waskiewicz Jr, Peter P
2007-04-30 12:56                 ` jamal
2007-05-01 18:27                   ` Waskiewicz Jr, Peter P
2007-05-01 22:11                     ` jamal
2007-05-01 23:04                       ` Waskiewicz Jr, Peter P
2007-05-02 12:43                         ` jamal
2007-05-03 21:03                           ` Waskiewicz Jr, Peter P
2007-05-03 23:54                             ` jamal
2007-05-04 15:48                               ` Waskiewicz Jr, Peter P
2007-05-04 20:01                             ` Stephen Hemminger
2007-05-04 20:06                               ` David Miller
2007-05-04 20:43                               ` Waskiewicz Jr, Peter P
2007-05-04 21:00                                 ` David Miller
2007-05-04 21:22                                 ` Johannes Berg
2007-05-08  9:33                                   ` Zhu Yi
2007-05-08  9:45                                     ` Johannes Berg
2007-05-08 13:28                                       ` jamal
2007-05-08 15:35                                         ` Waskiewicz Jr, Peter P
2007-05-08 23:28                                           ` jamal
2007-05-10  3:02                                             ` Zhu Yi
2007-05-10 12:35                                               ` jamal
2007-05-11  1:58                                                 ` Zhu Yi
2007-05-11  2:23                                                   ` jamal
2007-05-10 18:22                                             ` Waskiewicz Jr, Peter P
2007-05-10 20:00                                               ` jamal
2007-05-09 14:16                                         ` Johannes Berg
2007-04-27 14:58           ` jamal
2007-04-27 15:43             ` Jeff Garzik
2007-04-27 15:46               ` Waskiewicz Jr, Peter P
2007-04-26 18:49       ` Jan Engelhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1177594079.4077.37.camel@localhost \
    --to=hadi@cyberus.ca \
    --cc=auke-jan.h.kok@intel.com \
    --cc=christopher.leech@intel.com \
    --cc=cramerj@intel.com \
    --cc=davem@davemloft.net \
    --cc=jgarzik@pobox.com \
    --cc=netdev@vger.kernel.org \
    --cc=peter.p.waskiewicz.jr@intel.com \
    --cc=shemminger@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.