All of lore.kernel.org
 help / color / mirror / Atom feed
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 18:32:50 -0400	[thread overview]
Message-ID: <1216593170.4847.137.camel@localhost> (raw)
In-Reply-To: <20080720.102534.246150854.davem@davemloft.net>

On Sun, 2008-20-07 at 10:25 -0700, David Miller wrote:

> They tend to implement round-robin or some similar fairness algorithm
> amongst the queues, with zero concern about packet priorities.

pfifo_fast would be a bad choice in that case, but even a pfifo cannot
guarantee proper RR because it would present packets in a FIFO order
(and example the first 10 could go to hardware queue1 and the next to
hardware queue2).
 
My view: i think you need a software queue per hardware queue.
Maybe even these queues residing in the driver; that way you take care
of congestion and it doesnt matter if the hardware is RR or strict prio
(and you dont need the pfifo or pfifo_fast anymore).
The use case would be something along:
packets comes in, you classify find its for queue1, grab the
per-hardware-queue1 lock, find the hardware queue1 is overloaded and
stash it instead in s/ware queue1. If it wasnt congested, it would go on
hardware queue1.
When hardware queue1 becomes available and netif-woken, you pick first
from s/ware queue1 (and batching could apply cleanly here) and send them
to hardware queue.

> It really is just like a bunch of queues to the phsyical layer,
> fairly shared.

I am suprised prioritization is not an issue. [My understanding of the
intel/cisco datacentre cabal is they serve virtual machines using
virtual wires; i would think in such scenarios youd have some customers
who pay more than others].

> These things are built for parallelization, not prioritization.

Total parallelization happens in the ideal case. If X cpus classify
packets going to X different hardware queueus each CPU grabs only locks
for that hardware queue. In virtualization, where only one customer's
traffic is going to a specific hardware queue, things would work well.
Non-virtualization scenario may result in collision in which two or more
CPUs may contend for the same hardware queue (either transmitting or
netif-waking etc).
 
cheers,
jamal


WARNING: multiple messages have this Message-ID (diff)
From: jamal <hadi-fAAogVwAN2Kw5LPnMra/2Q@public.gmane.org>
To: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Cc: kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 20/31]: pkt_sched: Perform bulk of qdisc destruction in RCU.
Date: Sun, 20 Jul 2008 18:32:50 -0400	[thread overview]
Message-ID: <1216593170.4847.137.camel@localhost> (raw)
In-Reply-To: <20080720.102534.246150854.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>

On Sun, 2008-20-07 at 10:25 -0700, David Miller wrote:

> They tend to implement round-robin or some similar fairness algorithm
> amongst the queues, with zero concern about packet priorities.

pfifo_fast would be a bad choice in that case, but even a pfifo cannot
guarantee proper RR because it would present packets in a FIFO order
(and example the first 10 could go to hardware queue1 and the next to
hardware queue2).
 
My view: i think you need a software queue per hardware queue.
Maybe even these queues residing in the driver; that way you take care
of congestion and it doesnt matter if the hardware is RR or strict prio
(and you dont need the pfifo or pfifo_fast anymore).
The use case would be something along:
packets comes in, you classify find its for queue1, grab the
per-hardware-queue1 lock, find the hardware queue1 is overloaded and
stash it instead in s/ware queue1. If it wasnt congested, it would go on
hardware queue1.
When hardware queue1 becomes available and netif-woken, you pick first
from s/ware queue1 (and batching could apply cleanly here) and send them
to hardware queue.

> It really is just like a bunch of queues to the phsyical layer,
> fairly shared.

I am suprised prioritization is not an issue. [My understanding of the
intel/cisco datacentre cabal is they serve virtual machines using
virtual wires; i would think in such scenarios youd have some customers
who pay more than others].

> These things are built for parallelization, not prioritization.

Total parallelization happens in the ideal case. If X cpus classify
packets going to X different hardware queueus each CPU grabs only locks
for that hardware queue. In virtualization, where only one customer's
traffic is going to a specific hardware queue, things would work well.
Non-virtualization scenario may result in collision in which two or more
CPUs may contend for the same hardware queue (either transmitting or
netif-waking etc).
 
cheers,
jamal

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2008-07-20 22:32 UTC|newest]

Thread overview: 93+ 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
2008-07-17 12:17 ` David Miller
2008-07-17 13:03 ` Patrick McHardy
2008-07-17 13:03   ` Patrick McHardy
2008-07-17 13:12   ` David Miller
2008-07-17 13:12     ` David Miller
2008-07-17 13:48     ` Patrick McHardy
2008-07-17 22:36       ` David Miller
2008-07-17 22:36         ` David Miller
2008-07-17 23:58         ` Patrick McHardy
2008-07-17 23:58           ` Patrick McHardy
2008-07-17 13:35   ` jamal
2008-07-17 13:35     ` jamal
2008-07-17 14:02     ` Patrick McHardy
2008-07-17 22:24       ` David Miller
2008-07-17 22:24         ` David Miller
2008-07-17 23:48         ` Patrick McHardy
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-18 21:05                 ` David Miller
2008-07-20 15:16                 ` jamal
2008-07-20 17:25                   ` David Miller
2008-07-20 17:34                     ` Tomas Winkler
2008-07-20 17:34                       ` Tomas Winkler
2008-07-20 17:35                       ` David Miller
2008-07-20 17:35                         ` David Miller
2008-07-20 22:32                     ` jamal [this message]
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 11:20                             ` jamal
2008-07-21 16:45                             ` David Miller
2008-07-21 11:58                           ` Herbert Xu
2008-07-21 11:58                             ` Herbert Xu
2008-07-21 13:08                             ` jamal
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
2008-07-21 15:09                                     ` David Miller
2008-07-21 15:09                                       ` David Miller
2008-07-21 15:22                                       ` Herbert Xu
2008-07-21 15:22                                         ` Herbert Xu
2008-07-21 15:26                                         ` David Miller
2008-07-21 16:16                                           ` Herbert Xu
2008-07-21 16:16                                             ` Herbert Xu
2008-07-21 16:25                                             ` David Miller
2008-07-21 16:25                                               ` David Miller
2008-07-21 16:43                                               ` Herbert Xu
2008-07-21 16:51                                                 ` David Miller
2008-07-21 17:02                                                   ` Herbert Xu
2008-07-21 17:02                                                     ` Herbert Xu
2008-07-21 17:08                                                     ` David Miller
2008-07-21 17:08                                                       ` David Miller
2008-07-21 17:11                                                       ` Herbert Xu
2008-07-21 17:11                                                         ` Herbert Xu
2008-08-22  6:56                                                         ` Herbert Xu
2008-08-22  7:16                                                           ` David Miller
2008-08-22  7:41                                                             ` Herbert Xu
2008-08-22  7:41                                                               ` Herbert Xu
2008-08-22 10:42                                                               ` David Miller
2008-08-22 10:42                                                                 ` David Miller
2008-08-22 10:47                                                                 ` Herbert Xu
2008-08-22 10:47                                                                   ` Herbert Xu
2008-08-22 13:52                                                                 ` jamal
2008-08-22 13:52                                                                   ` jamal
2008-08-22 13:43                                                           ` jamal
2008-08-22 13:43                                                             ` jamal
2008-07-21 17:35                             ` David Miller
2008-07-21 17:35                               ` David Miller
2008-07-18 17:10             ` Roland Dreier
2008-07-18 17:10               ` Roland Dreier
2008-07-20 14:58               ` jamal
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
2008-07-20 14:20       ` Herbert Xu
2008-07-20 15:35       ` jamal
2008-07-20 15:35         ` jamal
2008-07-21  0:11         ` Herbert Xu
2008-07-21  2:33           ` jamal
2008-07-21  2:33             ` jamal
2008-07-21  3:17             ` Herbert Xu
2008-07-21  3:17               ` Herbert Xu
2008-07-21 11:14               ` jamal
2008-07-21 11:36                 ` Herbert Xu
2008-07-21 11:39                   ` jamal
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=1216593170.4847.137.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 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.