From: Patrick McHardy <kaber@trash.net>
To: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@intel.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@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>
Subject: Re: [PATCH] NET: [UPDATED] Multiqueue network device support implementation.
Date: Tue, 10 Apr 2007 11:04:57 +0200 [thread overview]
Message-ID: <461B5339.50700@trash.net> (raw)
In-Reply-To: <D5C1322C3E673F459512FB59E0DDC329029E42C6@orsmsx414.amr.corp.intel.com>
Waskiewicz Jr, Peter P wrote:
> Thanks Pat for the initial feedback. I can post a set of patches to
> e1000 using the new API; I'll try to get them out asap (need to apply to
> this kernel tree).
Thanks.
> However, the PRIO qdisc still uses the priority in
> the bands for dequeueing priority, and will feed the queues on the NIC.
> The e1000, and any other multiqueue NIC, will schedule Tx based on how
> the PRIO qdisc feeds the queues. So the only priority here is the
> dequeuing priority from the kernel. The e1000 will use the new API for
> starting/stopping the individual queues based on the descriptors
> available, much like it does today for the global queue.
Packets will only be dequeued from a band if the associated subqueue
is active, which moves the decision from prio to the driver, no?
What policy does e1000 use for scheduling its internal queues?
next prev parent reply other threads:[~2007-04-10 9:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-10 0:32 [PATCH] NET: [UPDATED] Multiqueue network device support implementation Peter P Waskiewicz Jr
2007-04-10 0:28 ` Patrick McHardy
2007-04-10 1:40 ` Waskiewicz Jr, Peter P
2007-04-10 9:04 ` Patrick McHardy [this message]
2007-04-11 16:52 ` Waskiewicz Jr, Peter P
2007-04-11 17:03 ` Patrick McHardy
2007-04-12 5:24 ` Zhu Yi
2007-04-10 9:48 ` Patrick McHardy
2007-04-10 16:27 ` Waskiewicz Jr, Peter P
2007-04-11 5:47 ` Patrick McHardy
2007-04-11 15:40 ` Waskiewicz Jr, Peter P
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=461B5339.50700@trash.net \
--to=kaber@trash.net \
--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=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=peter.p.waskiewicz.jr@intel.com \
/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.