mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Robert Olsson <Robert.Olsson@data.slu.se>
To: "Avery Fay" <avery_fay@symantec.com>
Cc: linux-kernel@vger.kernel.org
Subject: Gigabit/SMP performance problem
Date: Fri, 3 Jan 2003 22:20:03 +0100	[thread overview]
Message-ID: <15893.65155.49072.307843@robur.slu.se> (raw)
In-Reply-To: <OFC4D9AF0E.DA93F4D7-ON85256CA3.0058C567-85256CA3.00592873@symantec.com>


Avery Fay writes:
 > 
 > I'm working with a dual xeon platform with 4 dual e1000 cards on different 
 > pci-x buses. I'm having trouble getting better performance with the second 
 > cpu enabled (ht disabled). With a UP kernel (redhat's 2.4.18), I can route 
 > about 2.9 gigabits/s at around 90% cpu utilization. With a SMP kernel 
 > (redhat's 2.4.18), I can route about 2.8 gigabits/s with both cpus at 
 > around 90% utilization. This suggests to me that the network code is 
 > serialized. I would expect one of two things from my understanding of the 
 > 2.4.x networking improvements (softirqs allowing execution on more than 
 > one cpu):

 Well you have a gigabit router :-)

 How is your routing setup? Packet size?

 Also you'll never get increased performance of a single flow with SMP. 
 Aggregated performance possible at best. I've been fighting with for some 
 time too.

 You have some important data in /proc/net/softnet_stat which are per cpu
 packets received and "cpu collisions" should interest you.

 As far as I understand there no serialization in forwarding path except where
 it has to be -- when we add softirq's from different cpu into a single device.
 This seen in "cpu collisions"

 Also here we get into inherent SMP cache bouncing problem with TX interrupts
 When TX has skb's which are processed/created in different CPU's. Which CPU
 gonna take the interrupt? No matter how we do we run kfree we gona see a lot 
 of cache bouncing. For systems that have same in/out interface smp_affinity
 can be used. In practice this impossible for forwarding.

 And this bouncing hurts especially for small pakets....

 A litte TX test illustrates. Sender on cpu0.

 UP                      186 kpps
 SMP Aff to cpu0         160 kpps
 SMP Aff to cpu0, cpu1   124 kpps
 SMP Aff to cpu1         106 kpps

 We are playing some code that might decrease this problem.


 Cheers.
						--ro

  parent reply	other threads:[~2003-01-03 21:03 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-03 16:12 Avery Fay
2003-01-03 18:05 ` Martin J. Bligh
2003-01-03 21:49   ` Ron cooper
2003-01-03 21:47     ` Martin J. Bligh
2003-01-03 21:20 ` Robert Olsson [this message]
2003-01-04  3:33 ` Anton Blanchard
2003-01-06 19:43 ` Jon Fraser
2003-01-03 20:25 Avery Fay
2003-01-03 21:19 ` Arjan van de Ven
2003-01-03 21:36 ` Martin J. Bligh
2003-01-03 22:31   ` Andrew Theurer
     [not found] <b8ce5e32.0301040439.7bdaa903@posting.google.com>
2003-01-06 18:27 ` Bill Davidsen
2003-01-06 19:09   ` Daniel Blueman
2003-01-06 19:26     ` Brian Tinsley
2003-01-06 20:25 Avery Fay
2003-01-06 20:29 Avery Fay
2003-01-06 21:23 ` Martin J. Bligh
2003-01-07 17:19   ` Mike Black
2003-01-06 20:33 Avery Fay
2003-01-06 20:38 Avery Fay
2003-01-07 18:15 ` Robert Olsson
2003-01-08 12:17 Jon Burgess
2003-01-08 21:12 Feldman, Scott
2003-01-08 21:44 Ronciak, John
2003-01-09 12:49 ` Robert Olsson

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=15893.65155.49072.307843@robur.slu.se \
    --to=robert.olsson@data.slu.se \
    --cc=avery_fay@symantec.com \
    --cc=linux-kernel@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

all inboxes | Powered by JetHome®