netdev - Re: [PATCH 0/1] ixgbe: Support for Intel(R) 10GbE PCI Express adapters

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46A4F8F6.3010008@hp.com>
Date:	Mon, 23 Jul 2007 11:52:38 -0700
From:	Rick Jones <rick.jones2@...com>
To:	"Veeraiyan, Ayyappan" <ayyappan.veeraiyan@...el.com>
Cc:	Jeff Garzik <jeff@...zik.org>, netdev@...r.kernel.org,
	arjan@...ux.intel.com, akpm@...ux-foundation.org,
	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>, hch@...radead.org,
	shemminger@...ux-foundation.org, nhorman@...driver.com,
	inaky@...ux.intel.com, mb@...sch.de
Subject: Re: [PATCH 0/1] ixgbe: Support for Intel(R) 10GbE PCI Express	adapters
 -	Take #2

> 
> 
> Bidirectional test.
> 87380  65536  65536    60.01   7809.57   28.66    30.02    2.405   2.519
> TX
> 87380  65536  65536    60.01   7592.90   28.66    30.02    2.474   2.591
> RX
> ------------------------------
> 87380  65536  65536    60.01  7629.73   28.32    29.64    2.433   2.546
> RX
> 87380  65536  65536    60.01  7926.99   28.32    29.64    2.342   2.450
> TX
> 
> Signle netperf stream between 2 quad-core Xeon based boxes. Tested on
> 2.6.20 and 2.6.22 kernels. Driver uses NAPI and LRO.

The bidirectional looks like a two concurrent stream (TCP_STREAM + TCP_MAERTS) 
test right?

If you want a single-stream bidirectional test, then with the top of trunk 
netperf you can use:

./configure --enable-burst
make install # yadda yadda
netperf -t TCP_RR -H <remote> -f m -v 2 -l 60 -c -C -- -r 64K -b 12

which will cause netperf to have 13, 64K transactions in flight at one time on 
the connection, which for a 64K request size has been sufficient, thusfar 
anyway, to saturate things.  As there is no select/poll/whatever call in netperf 
TCP_RR it might be necessary to include test-specific -s and -S options to make 
sure the socket buffer (SO_SNDBUF) is large enough that none of those send() 
calls ever block, lest both ends end-up blocked in a send() call.

The -f m will switch the output from transactions/s to megabits per second and 
is the part requiring the top of trunk netperf.  The -v 2 stuff causes extra 
stuff to give bitrates in each direction and transaction/s rate as well as 
computed average latency.  That is also in top of trunk, otherwise, for 2.4.3 
you can skip that and do the math to conver to megabits/s yourself and not get 
all the other derived values.

rick jones
-
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