public inbox for linux-wireless@vger.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


  parent reply	other threads:[~2008-07-20 22:32 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
2008-07-17 13:03 ` Patrick McHardy
2008-07-17 13:12   ` David Miller
2008-07-17 13:48     ` Patrick McHardy
2008-07-17 22:36       ` David Miller
2008-07-17 23:58         ` Patrick McHardy
2008-07-17 13:35   ` jamal
2008-07-17 14:02     ` Patrick McHardy
2008-07-17 22:24       ` David Miller
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
2008-07-20 17:25                   ` David Miller
2008-07-20 17:34                     ` Tomas Winkler
2008-07-20 17:35                       ` David Miller
2008-07-20 22:32                     ` jamal [this message]
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
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:22                                       ` Herbert Xu
2008-07-21 15:26                                         ` David Miller
2008-07-21 16:16                                           ` Herbert Xu
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:08                                                     ` David Miller
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 10:42                                                               ` David Miller
2008-08-22 10:47                                                                 ` Herbert Xu
2008-08-22 13:52                                                                 ` jamal
2008-08-22 13:43                                                           ` jamal
2008-07-21 17:35                             ` David Miller
2008-07-18 17:10             ` Roland Dreier
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 15:35       ` jamal
2008-07-21  0:11         ` Herbert Xu
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
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox