All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rick Jones <rick.jones2@hp.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Benjamin LaHaise <ben.lahaise@neterion.com>,
	David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org
Subject: Re: [0/14] GRO: Lots of microoptimisations
Date: Wed, 17 Jun 2009 13:14:33 -0700	[thread overview]
Message-ID: <4A394EA9.20503@hp.com> (raw)
In-Reply-To: <20090617080847.GA24504@gondor.apana.org.au>

Herbert Xu wrote:
> On Wed, Jun 17, 2009 at 04:07:30PM +0800, Herbert Xu wrote:
> 
>>On Wed, Jun 17, 2009 at 02:38:56AM +1000, Herbert Xu wrote:
>>
>>>I'm hoping to get onto this tomorrow.  I think there's definitely
>>>something broken because there's no way GRO should be slower than
>>>GRO off.  Slightly slower than LRO perhaps but surely not worse than
>>>not merging at all :)
>>
>>OK, I'm seeing the opposite :)
> 
> 
> Can you check your sender to see whether it's maxed out? That
> can play havoc when benchmarking the receiver.

Realted to that, and dealing with the inaccuracy of what classic netperf reports 
for thesocket buffers (your previous message) and wanting to know about the CPUs 
on either side, if one grabs netperf 2.4.5  and ./configure --enable-omni on both 
sides, a command like:

netperf -H 172.17.10.22 -c -C -t omni -- -m 16K -O foo

where the contents of the file foo are:

LSS_SIZE_END,RSR_SIZE_END,LOCAL_SEND_SIZE,ELAPSED_TIME,THROUGHPUT,THROUGHPUT_UNITS
LOCAL_CPU_UTIL,LOCAL_SD,LOCAL_CPU_COUNT,LOCAL_CPU_PEAK_UTIL,LOCAL_CPU_PEAK_ID
REMOTE_CPU_UTIL,REMOTE_SD,REMOTE_CPU_COUNT,REMOTE_CPU_PEAK_UTIL,REMOTE_CPU_PEAK_ID
LOCAL_CPU_MODEL,LOCAL_CPU_FREQUENCY,REMOTE_CPU_MODEL,REMOTE_CPU_FREQUENCY

will result in output that looks like:

raj@tardy:~/netperf2_trunk$ src/netperf -t omni -H localhost -c -C -- -m 16K -O foo
OMNI TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost.localdomain 
(127.0.0.1) port 0 AF_INET
Local       Remote      Local  Elapsed Throughput Throughput
Send Socket Recv Socket Send   Time               Units
Size        Size        Size   (sec)
Final       Final
606960      2072576     16384  10.00   3437.47    10^6bits/s

Local   Local   Local Local   Local
CPU     Service CPU   Peak    Peak
Util    Demand  Count Per CPU Per CPU
%                     Util %  ID
100.00  2.383   1     100.00  0

Remote  Remote  Remote Remote  Remote
CPU     Service CPU    Peak    Peak
Util    Demand  Count  Per CPU Per CPU
%                      Util %  ID
100.00  2.383   1      100.00  0

Local                          Local     Remote                         Remote
CPU                            CPU       CPU                            CPU
Model                          Frequency Model                          Frequency
                                MHz                                      MHz
Intel(R) XEON(TM) CPU 2.00GHz  1995      Intel(R) XEON(TM) CPU 2.00GHz  1995

modulo some wrapping,  can also use -o to get one set of CSV or -k to get keyval. 
  The file can have as many as four lines which will be honored by the -O option, 
with -o producing one big line regardless and -k producing one line per keyval 
regardless.  netperf -t omni -- -O \?  will give a list of all the known output 
selections.

So, you can get netperf to tell you about the CPUs, and whether one of them 
pegged on either side.

happy benchmarking,

rick jones

> 
> Also what are the raw numbers that you were getting?
> 
> Cheers,


      reply	other threads:[~2009-06-17 20:14 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-27  4:45 [0/14] GRO: Lots of microoptimisations Herbert Xu
2009-05-27  4:50 ` [PATCH 1/14] gro: Open-code frags copy in skb_gro_receive Herbert Xu
2009-05-27  4:50 ` [PATCH 2/14] gro: Inline skb_gro_header and cache frag0 virtual address Herbert Xu
2009-05-27  4:50 ` [PATCH 3/14] gro: Localise offset/headlen in skb_gro_offset Herbert Xu
2009-05-27  4:50 ` [PATCH 4/14] gro: Only use skb_gro_header for completely non-linear packets Herbert Xu
2009-05-27  4:50 ` [PATCH 5/14] tcp: Optimise GRO port comparisons Herbert Xu
2009-05-27  4:50 ` [PATCH 6/14] tcp: Remove unnecessary window comparisons for GRO Herbert Xu
2009-05-27  4:50 ` [PATCH 7/14] tcp: Optimise len/mss comparison Herbert Xu
2009-05-27  4:50 ` [PATCH 8/14] gro: Optimise length comparison in skb_gro_header Herbert Xu
2009-05-27  4:50 ` [PATCH 9/14] gro: Avoid unnecessary comparison after skb_gro_header Herbert Xu
2009-05-27  4:50 ` [PATCH 10/14] ipv4: Use 32-bit loads for ID and length in GRO Herbert Xu
2009-05-27 18:00   ` Andi Kleen
2009-05-27 21:26     ` Herbert Xu
2009-05-27  4:50 ` [PATCH 11/14] gro: Open-code final pskb_may_pull Herbert Xu
2009-05-27  4:50 ` [PATCH 12/14] gro: Nasty optimisations for page frags in skb_gro_receive Herbert Xu
2009-05-27  4:50 ` [PATCH 13/14] gro: Store shinfo in local variable " Herbert Xu
2009-05-27  4:50 ` [PATCH 14/14] tcp: Do not check flush when comparing options for GRO Herbert Xu
2009-05-27 10:42 ` [0/14] GRO: Lots of microoptimisations David Miller
2009-05-27 17:52 ` Benjamin LaHaise
2009-05-27 23:08   ` Herbert Xu
2009-05-28 15:21     ` Benjamin LaHaise
2009-05-29  9:28       ` Herbert Xu
2009-05-29  9:29         ` Herbert Xu
2009-05-29 16:23           ` Benjamin LaHaise
2009-06-10  5:44             ` Herbert Xu
2009-06-12 16:09               ` Benjamin LaHaise
2009-06-12 23:48                 ` David Miller
2009-06-16 16:35                   ` Benjamin LaHaise
2009-06-16 16:38                     ` Herbert Xu
2009-06-17  8:07                       ` Herbert Xu
2009-06-17  8:08                         ` Herbert Xu
2009-06-17 20:14                           ` Rick Jones [this message]

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=4A394EA9.20503@hp.com \
    --to=rick.jones2@hp.com \
    --cc=ben.lahaise@neterion.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.