From: Eric Dumazet <eric.dumazet@gmail.com>
To: Wei Gu <wei.gu@ericsson.com>
Cc: Alexander Duyck <alexander.h.duyck@intel.com>,
netdev <netdev@vger.kernel.org>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>
Subject: RE: Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel
Date: Fri, 08 Apr 2011 17:07:03 +0200 [thread overview]
Message-ID: <1302275223.4409.36.camel@edumazet-laptop> (raw)
In-Reply-To: <D12839161ADD3A4B8DA63D1A134D084026E48BA682@ESGSCCMS0001.eapac.ericsson.se>
Le vendredi 08 avril 2011 à 22:10 +0800, Wei Gu a écrit :
> Hi,
> Got you mean.
> But as I decribed before, I start the eth10 with 8 rx queues and 8 tx
> queues, and then I binding these 8 tx&rx queue each to CPU core 24-32
> (NUMA3), which I think could gain the best performance in my case
> (It's true on Linux 2.6.32)
> single queue ->single CPU
Try with other cpus ? Maybe a mix.
Maybe your thinking is not good, and you chose the cpus that were not
the best candidates. This was OK in 2.6.32 because you were lucky.
Using cpus from an unique NUMA node is not very good, since only one
NUMA node is going to be used, and other NUMA nodes are idle.
NUMA binding is tricky. Linux try to use local node, hoping that all
cpus are running and use local memory. In the end, global throughput is
better.
But if your workload use cpus from one single node, then it means you
lose part of the memory bandwidth.
> Then I can descibe a little bit with packet generator, I config the
> IXIA to continues increase the dest ip address towards the test
> server, so the packet was evenly distributed to each receving queues
> of the eth10. And according the IXIA tools the transmit sharp was
> really good, no too much peaks
>
> What I observed on Linux 2.6.38 during the test, there is no softqd
> was stressed (< 03% on SI for each core(24-31)) while the packet lost
> happens, so we are not really stress the CPU:), It looks like we are
> limited on some memory bandwidth (DMA) on this release
That would mean you chose the wrong cpus to handle this load.
>
> And with same test case on 2.6.32, no such problem at all. It running
> pretty stable > 2Mpps without rx_missing_error. There is no HW
> limitation on this DL580
>
>
> BTW what is these "swapper"
> + 0.80% swapper [ixgbe] [k]
> ixgbe_poll
> + 0.79% perf [ixgbe] [k]
> ixgbe_poll
> Why the ixgbe_poll was on swapper/perf?
>
softirq are run behalf the current interrupted thread, unless you enter
ksoftirqd if load is high.
It can be "idle task" or the "perf" task, or another ones...
next prev parent reply other threads:[~2011-04-08 15:07 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <D12839161ADD3A4B8DA63D1A134D084026E48B9BEB@ESGSCCMS0001.eapac.ericsson.se>
2011-04-07 4:58 ` Question on "net: allocate skbs on local node" Eric Dumazet
2011-04-07 5:16 ` Eric Dumazet
2011-04-07 6:16 ` Eric Dumazet
2011-04-07 7:22 ` Low performance Intel 10GE NIC (3.2.10) on 2.6.38 Kernel Wei Gu
2011-04-07 8:07 ` Eric Dumazet
2011-04-07 8:39 ` Wei Gu
2011-04-07 9:06 ` Eric Dumazet
2011-04-07 11:15 ` Wei Gu
2011-04-07 11:46 ` Eric Dumazet
2011-04-07 13:41 ` Eric Dumazet
2011-04-07 15:58 ` Alexander Duyck
2011-04-07 16:03 ` Eric Dumazet
2011-04-07 16:20 ` Alexander Duyck
2011-04-07 16:37 ` Eric Dumazet
2011-04-08 8:59 ` Wei Gu
2011-04-08 9:07 ` Eric Dumazet
2011-04-08 9:15 ` Wei Gu
2011-04-08 9:49 ` Eric Dumazet
2011-04-08 9:59 ` Wei Gu
2011-04-08 9:41 ` Wei Gu
2011-04-08 12:19 ` Wei Gu
2011-04-08 12:56 ` Eric Dumazet
2011-04-08 14:10 ` Wei Gu
2011-04-08 14:49 ` Stephen Hemminger
2011-04-09 3:51 ` Wei Gu
2011-04-08 15:07 ` Eric Dumazet [this message]
2011-04-09 3:27 ` Wei Gu
2011-04-09 6:36 ` Eric Dumazet
2011-04-10 7:02 ` Wei Gu
2011-04-11 14:50 ` Alexander Duyck
2011-04-11 15:00 ` Wei Gu
2011-04-11 15:14 ` Wei Gu
2011-04-11 15:42 ` Eric Dumazet
2011-04-12 1:22 ` Wei Gu
2011-04-12 4:40 ` Wei Gu
2011-04-12 4:56 ` Eric Dumazet
2011-04-12 5:18 ` Wei Gu
2011-04-14 5:42 ` Wei Gu
2011-04-14 6:07 ` Eric Dumazet
2011-04-14 6:33 ` Eric Dumazet
2011-04-14 6:58 ` Wei Gu
2011-04-14 16:42 ` Alexander Duyck
2011-04-14 16:45 ` Eric Dumazet
2011-04-14 16:56 ` Peter Zijlstra
2011-04-14 16:57 ` Eric Dumazet
2011-04-14 17:49 ` Eric Dumazet
2011-04-14 19:08 ` Alexander Duyck
2011-04-15 2:10 ` Wei Gu
2011-04-15 8:57 ` Peter Zijlstra
2011-04-15 9:14 ` Wei Gu
2011-04-18 21:12 ` Jesse Brandeburg
2011-04-19 4:09 ` Wei Gu
2011-04-21 2:57 ` Wei Gu
2011-04-21 3:25 ` Wei Gu
2011-04-08 16:22 ` Alexander Duyck
2011-04-09 3:36 ` Wei Gu
2011-04-09 4:40 ` Alexander H Duyck
2011-04-09 6:12 ` Wei Gu
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=1302275223.4409.36.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=alexander.h.duyck@intel.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=netdev@vger.kernel.org \
--cc=wei.gu@ericsson.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