From: Rick Jones <rick.jones2@hp.com>
To: "Veeraiyan, Ayyappan" <ayyappan.veeraiyan@intel.com>
Cc: Jeff Garzik <jeff@garzik.org>,
netdev@vger.kernel.org, arjan@linux.intel.com,
akpm@linux-foundation.org, "Kok,
Auke-jan H" <auke-jan.h.kok@intel.com>,
hch@infradead.org, shemminger@linux-foundation.org,
nhorman@tuxdriver.com, inaky@linux.intel.com, mb@bu3sch.de
Subject: Re: [PATCH 0/1] ixgbe: Support for Intel(R) 10GbE PCI Express adapters - Take #2
Date: Mon, 23 Jul 2007 11:52:38 -0700 [thread overview]
Message-ID: <46A4F8F6.3010008@hp.com> (raw)
In-Reply-To: <E35F4F4D7F6C9E4E826FEC1F86CEF58304330045@orsmsx412.amr.corp.intel.com>
>
>
> 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
next prev parent reply other threads:[~2007-07-23 18:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-10 17:45 [PATCH 0/1] ixgbe: Support for Intel(R) 10GbE PCI Express adapters - Take #2 Ayyappan.Veeraiyan
2007-07-10 17:49 ` [PATCH 1/1]ixgbe: Driver for Intel 82598 based 10GbE PCI Express family of adapters Ayyappan Veeraiyan
2007-07-10 18:00 ` [PATCH 0/1] ixgbe: Support for Intel(R) 10GbE PCI Express adapters - Take #2 Jeff Garzik
2007-07-10 18:11 ` Veeraiyan, Ayyappan
2007-07-10 18:23 ` Jeff Garzik
2007-07-17 13:22 ` Veeraiyan, Ayyappan
2007-07-23 18:52 ` Rick Jones [this message]
2007-07-26 20:07 ` Veeraiyan, Ayyappan
2007-07-26 20:20 ` Rick Jones
2007-07-10 18:47 ` Kok, Auke
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=46A4F8F6.3010008@hp.com \
--to=rick.jones2@hp.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=auke-jan.h.kok@intel.com \
--cc=ayyappan.veeraiyan@intel.com \
--cc=hch@infradead.org \
--cc=inaky@linux.intel.com \
--cc=jeff@garzik.org \
--cc=mb@bu3sch.de \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=shemminger@linux-foundation.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.