[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4A394EA9.20503@hp.com>
Date: Wed, 17 Jun 2009 13:14:33 -0700
From: Rick Jones <rick.jones2@...com>
To: Herbert Xu <herbert@...dor.apana.org.au>
CC: Benjamin LaHaise <ben.lahaise@...erion.com>,
David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [0/14] GRO: Lots of microoptimisations
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@...dy:~/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,
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists