From: jamal <hadi@cyberus.ca>
To: David Miller <davem@davemloft.net>
Cc: kaber@trash.net, netdev@vger.kernel.org,
johannes@sipsolutions.net, linux-wireless@vger.kernel.org
Subject: Re: [PATCH 20/31]: pkt_sched: Perform bulk of qdisc destruction in RCU.
Date: Sun, 20 Jul 2008 11:16:03 -0400 [thread overview]
Message-ID: <1216566963.4847.81.camel@localhost> (raw)
In-Reply-To: <20080718.140539.122169028.davem@davemloft.net>
On Fri, 2008-18-07 at 14:05 -0700, David Miller wrote:
> The fundamental issue is what we believe qdiscs schedule, do they
> schedule a device, or do they schedule what their namesake implies,
> "queues"?
In the simple case of a single hardware queue/ring, the mapping between
a hardware queue and "physical wire" is one-to-one.
So in that case one could argue the root qdiscs are scheduling a device.
> Logically once we have multiple queues, we schedule queues.
> Therefore what probably makes sense is that for mostly stateless
> priority queueing such as pfifo_fast, doing prioritization at the
> queue level is OK.
IMO, in the case of multiple hardware queues per physical wire,
and such a netdevice already has a built-in hardware scheduler (they all
seem to have this feature) then if we can feed the hardware queues
directly, theres no need for any intermediate buffer(s).
In such a case, to compare with qdisc arch, its like the root qdisc is
in hardware.
The only need for intermediate s/ware queues is for cases of congestion.
If you could have a single software queue for each hardware queue, then
you still have the obligation of correctness to make sure higher prio
hardware rings get fed with packets first (depending on the hardwares
scheduling capability).
> But where non-trivial classification occurs, we have to either:
>
> 1) Make the queue selection match what the classifiers would do
> exactly.
>
> OR
>
> 2) Point all the queues at a single device global qdisc.
>
> What we have now implements #2. Later on we can try to do something
> as sophisticated as #1.
sure; i think you could achieve the goals by using the single queue with
a software pfifo_fast which maps skb->prio to hardware queues. such a
pfifo_fast may even sit in the driver. This queue will always be empty
unless you have congestion. The other thing is to make sure there is an
upper bound to the size of this queue; otherwise a remote bug could
cause it to grow infinitely and consume all memory.
cheers,
jamal
next prev parent reply other threads:[~2008-07-20 15:16 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-17 12:17 [PATCH 20/31]: pkt_sched: Perform bulk of qdisc destruction in RCU David Miller
[not found] ` <20080717.051726.226040470.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2008-07-17 13:03 ` Patrick McHardy
[not found] ` <487F4327.1000107-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
2008-07-17 13:12 ` David Miller
2008-07-17 13:48 ` Patrick McHardy
[not found] ` <487F4DA6.6010009-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
2008-07-17 22:36 ` David Miller
[not found] ` <20080717.153609.142867331.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2008-07-17 23:58 ` Patrick McHardy
2008-07-17 13:35 ` jamal
2008-07-17 14:02 ` Patrick McHardy
[not found] ` <487F50EC.80008-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
2008-07-17 22:24 ` David Miller
[not found] ` <20080717.152447.89672084.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2008-07-17 23:48 ` Patrick McHardy
2008-07-18 13:10 ` jamal
2008-07-18 13:27 ` jamal
2008-07-18 21:05 ` David Miller
2008-07-20 15:16 ` jamal [this message]
2008-07-20 17:25 ` David Miller
[not found] ` <20080720.102534.246150854.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2008-07-20 17:34 ` Tomas Winkler
[not found] ` <1ba2fa240807201034u1fbe3343tdcc858f7772d2b39-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-07-20 17:35 ` David Miller
2008-07-20 22:32 ` jamal
2008-07-20 23:59 ` David Miller
2008-07-21 2:20 ` jamal
2008-07-21 11:20 ` jamal
2008-07-21 16:45 ` David Miller
2008-07-21 11:58 ` Herbert Xu
[not found] ` <E1KKu2D-0002kd-00-XQvu0L+U/CjiRBuR/1fSEKKkPtS2pBon@public.gmane.org>
2008-07-21 13:08 ` jamal
2008-07-21 13:19 ` Herbert Xu
2008-07-21 13:56 ` jamal
2008-07-21 13:58 ` Herbert Xu
[not found] ` <20080721135846.GA11543-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2008-07-21 15:09 ` David Miller
[not found] ` <20080721.080901.214889979.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2008-07-21 15:22 ` Herbert Xu
2008-07-21 15:26 ` David Miller
[not found] ` <20080721.082627.128593651.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2008-07-21 16:16 ` Herbert Xu
[not found] ` <20080721161616.GA12938-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2008-07-21 16:25 ` David Miller
2008-07-21 16:43 ` Herbert Xu
2008-07-21 16:51 ` David Miller
[not found] ` <20080721.095124.89249903.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2008-07-21 17:02 ` Herbert Xu
[not found] ` <20080721170233.GA13417-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2008-07-21 17:08 ` David Miller
[not found] ` <20080721.100821.38432201.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2008-07-21 17:11 ` Herbert Xu
2008-08-22 6:56 ` Herbert Xu
2008-08-22 7:16 ` David Miller
[not found] ` <20080822.001620.141235108.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2008-08-22 7:41 ` Herbert Xu
[not found] ` <20080822074115.GB25615-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2008-08-22 10:42 ` David Miller
[not found] ` <20080822.034217.135152551.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2008-08-22 10:47 ` Herbert Xu
2008-08-22 13:52 ` jamal
[not found] ` <20080822065655.GA18471-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2008-08-22 13:43 ` jamal
2008-07-21 17:35 ` David Miller
2008-07-18 17:10 ` Roland Dreier
[not found] ` <adaljzz6ruq.fsf-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
2008-07-20 14:58 ` jamal
2008-07-20 14:32 ` Herbert Xu
2008-07-20 17:20 ` David Miller
2008-07-20 14:20 ` Herbert Xu
[not found] ` <E1KKZmE-0000ty-00-XQvu0L+U/CjiRBuR/1fSEKKkPtS2pBon@public.gmane.org>
2008-07-20 15:35 ` jamal
2008-07-21 0:11 ` Herbert Xu
[not found] ` <20080721001119.GA6515-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2008-07-21 2:33 ` jamal
2008-07-21 3:17 ` Herbert Xu
2008-07-21 11:14 ` jamal
2008-07-21 11:36 ` Herbert Xu
[not found] ` <20080721113600.GA10322-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2008-07-21 11:39 ` jamal
2008-07-19 3:59 ` David Miller
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=1216566963.4847.81.camel@localhost \
--to=hadi@cyberus.ca \
--cc=davem@davemloft.net \
--cc=johannes@sipsolutions.net \
--cc=kaber@trash.net \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).