From: Robert Olsson <Robert.Olsson@data.slu.se>
To: bert hubert <ahu@ds9a.nl>
Cc: Hyochang Nam <cannon@postech.ac.kr>, niv@us.ibm.com, netdev@oss.sgi.com
Subject: Re: [Question] SMP for Linux
Date: Thu, 17 Oct 2002 14:00:58 +0200 [thread overview]
Message-ID: <15790.42618.961289.506241@robur.slu.se> (raw)
In-Reply-To: <20021017100243.GA6569@outpost.ds9a.nl>
bert hubert writes:
> On Thu, Oct 17, 2002 at 11:29:28AM +0900, Hyochang Nam wrote:
> > Many people helped me to solve the interrupt distribution problem.
> > We tested the throughput of Layer 3 forwarding on a SMP machine
> > which equips two Zero proessor(2Ghz). This is our results:
> > -------------------------
> > SMP | No SMP
> > -------------------------
> > 230 Mbps | 330 Mbps
> > -------------------------
>
> There is something called 'irq affinity' which may be interesting for you.
> See here: http://www.dell.com/us/en/esg/topics/power_ps1q02-morse.htm
>
> /proc/irq/?/smp_affinity
Hello!
Not always good for routing... Were you still get the problem were one
interface is the output device from devices bound to different CPU's.
TX-ring can hold skb's from many CPU's so a lot of cache bouncing happens
when kfree and skb_headerinit is run.
I've played with some to code to re-route the skb freeing to the CPU
where it was processed this to minimize cache bouncing and I've seen
some good effects of this.
And to be fair with SMP you should compare multiple flows to see if you
can get any aggregated performance from SMP.
An experiment...
Single flow eth0->eth1 w. e1000 NAPI. 2.4.20-pre5. PIII @ 2x933 MHz
Bound = eth0, eth1 is bound to same CPU.
Split = eth0, eth1 is bound to differnt CPU's.
Free = unbound.
SMP routing performance
=======================
Bound Free Split "kfree-route"
---------------------------------
421 354 331 kpps
491 348 317 437 kpps w. skb recycling
UP routing performance
======================
494 kpps
593 kpps w. skb recycling
With SMP test "kfree-route" the interfaces are not bound to any CPU still
we now getting closer to "bound" (where both eth0, eth1 is bond to the same
CPU).
But yes UP is gives higher numbers in this single stream tests. Aggregated
throughput tests are to be done.
Cheers.
--ro
next prev parent reply other threads:[~2002-10-17 12:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-17 2:29 [Question] SMP for Linux Hyochang Nam
2002-10-17 10:02 ` bert hubert
2002-10-17 12:00 ` Robert Olsson [this message]
2002-10-17 17:28 ` Jon Fraser
2002-10-18 16:16 ` Robert Olsson
2002-10-18 23:29 ` Jon Fraser
2002-10-19 0:20 ` Nivedita Singhvi
2002-10-19 7:53 ` Robert Olsson
2002-10-24 21:00 ` Jon Fraser
2002-11-13 6:53 ` Eric Lemoine
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=15790.42618.961289.506241@robur.slu.se \
--to=robert.olsson@data.slu.se \
--cc=ahu@ds9a.nl \
--cc=cannon@postech.ac.kr \
--cc=netdev@oss.sgi.com \
--cc=niv@us.ibm.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 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).