From: Radu Rendec <radu.rendec@ines.ro>
To: Calin Velea <vcalinus@gemenii.ro>
Cc: Jarek Poplawski <jarkao2@gmail.com>,
Jesper Dangaard Brouer <hawk@diku.dk>,
Denys Fedoryschenko <denys@visp.net.lb>,
netdev <netdev@vger.kernel.org>
Subject: Re: htb parallelism on multi-core platforms
Date: Thu, 30 Apr 2009 14:19:36 +0300 [thread overview]
Message-ID: <1241090376.6554.404.camel@blade.ines.ro> (raw)
In-Reply-To: <395864833.20090430014946@gemenii.ro>
On Thu, 2009-04-30 at 01:49 +0300, Calin Velea wrote:
> I tested with e1000 only, on a single quad-core CPU - the L2 cache was
> shared between the cores.
>
> For 8 cores I suppose you have 2 quad-core CPUs. If the cores actually
> used belong to different physical CPUs, L2 cache sharing does not occur -
> maybe this could explain the performance drop in your case.
> Or there may be other explanation...
It is correct, I have 2 quad-core CPUs. If adjacent kernel-identified
CPUs are on the same physical CPU (e.g. CPU0, CPU1, CPU2 and CPU3) - and
it is very probable - then I think the L2 cache was actually shared.
That's because the used CPUs where either 0-3 or 4-7 but never a mix of
them. So perhaps there is another explanation (maybe driver/hardware).
> It could be the only way to get more power is to increase the number
> of devices where you are shaping. You could split the IP space into 4 groups
> and direct the trafic to 4 IMQ devices with 4 iptables rules -
>
> -d 0.0.0.0/2 -j IMQ --todev imq0,
> -d 64.0.0.0/2 -j IMQ --todev imq1, etc...
Yes, but what if let's say 10.0.0.0/24 and 70.0.0.0/24 need to share
bandwidth? 10.a.b.c goes to imq0 qdisc, and 70.x.y.z goes to imq1 qdisc,
and the two qdiscs (HTB sets) are independent. This will result in a
maximum of double the allocated bandwidth (if HTB sets are identical and
traffic is equally distributed).
> The performance gained through parallelism might be a lot higher than the
> added overhead of iptables and/or ipset nethash match. Anyway - this is more of
> a "hack" than a clean solution :)
>
> p.s.: latest IMQ at http://www.linuximq.net/ is for 2.6.26 so you will need to try with that
Yes, the performance gained through parallelism is expected to be higher
than the loss of the additional overhead. That's why I asked for
parallel HTB in the first place, but got very disappointed after David
Miller's reply :)
Thanks a lot for all the hints and for the imq link. Imq is very
interesting regardless of whether it proves to be useful for this
project of mine or not.
Radu Rendec
next prev parent reply other threads:[~2009-04-30 11:19 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-17 10:40 htb parallelism on multi-core platforms Radu Rendec
2009-04-17 11:31 ` David Miller
2009-04-17 11:33 ` Badalian Vyacheslav
2009-04-17 22:41 ` Jarek Poplawski
2009-04-18 0:21 ` Denys Fedoryschenko
2009-04-18 7:56 ` Jarek Poplawski
2009-04-22 14:02 ` Radu Rendec
2009-04-22 21:29 ` Jesper Dangaard Brouer
2009-04-23 8:20 ` Jarek Poplawski
2009-04-23 13:56 ` Radu Rendec
2009-04-23 18:19 ` Jarek Poplawski
2009-04-23 20:19 ` Jesper Dangaard Brouer
2009-04-24 9:42 ` Radu Rendec
2009-04-28 10:15 ` Jesper Dangaard Brouer
2009-04-29 10:21 ` Radu Rendec
2009-04-29 10:31 ` Jesper Dangaard Brouer
2009-04-29 11:03 ` Radu Rendec
2009-04-29 12:23 ` Jarek Poplawski
2009-04-29 13:15 ` Radu Rendec
2009-04-29 13:38 ` Jarek Poplawski
2009-04-29 16:21 ` Radu Rendec
2009-04-29 22:49 ` Calin Velea
2009-04-29 23:00 ` Re[2]: " Calin Velea
2009-04-30 11:19 ` Radu Rendec [this message]
2009-04-30 11:44 ` Jesper Dangaard Brouer
2009-04-30 14:04 ` Re[2]: " Calin Velea
2009-05-08 10:15 ` Paweł Staszewski
2009-05-08 17:55 ` Vladimir Ivashchenko
2009-05-08 18:07 ` Denys Fedoryschenko
2009-04-23 12:31 ` Radu Rendec
2009-04-23 18:43 ` Jarek Poplawski
2009-04-23 19:06 ` Jesper Dangaard Brouer
2009-04-23 19:14 ` Jarek Poplawski
2009-04-23 19:47 ` Jesper Dangaard Brouer
2009-04-23 20:00 ` Jarek Poplawski
2009-04-23 20:09 ` Jeff King
2009-04-24 6:01 ` Jarek Poplawski
[not found] ` <1039493214.20090424135024@gemenii.ro>
2009-04-24 11:19 ` Jarek Poplawski
2009-04-24 11:35 ` Re[2]: " Calin Velea
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=1241090376.6554.404.camel@blade.ines.ro \
--to=radu.rendec@ines.ro \
--cc=denys@visp.net.lb \
--cc=hawk@diku.dk \
--cc=jarkao2@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=vcalinus@gemenii.ro \
/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).