From: Thomas Lendacky <tahm@linux.vnet.ibm.com>
To: David Ahern <dsahern@gmail.com>
Cc: Shirley Ma <mashirle@us.ibm.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
netdev@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [RFC PATCH 1/1] NUMA aware scheduling per cpu vhost thread
Date: Tue, 27 Mar 2012 09:34:35 -0500 [thread overview]
Message-ID: <2290046.f5KjQb758a@tomlt1.ibmoffice.com> (raw)
In-Reply-To: <4F6D0B24.1010300@gmail.com>
On Friday, March 23, 2012 05:45:40 PM David Ahern wrote:
> On 3/23/12 12:32 PM, Thomas Lendacky wrote:
> > Quick description of the tests:
> > TCP_RR and UDP_RR using 256 byte request/response size in 1, 10, 30
> > and 60 instances
> > TCP_STREAM and TCP_MAERTS using 256, 1K, 4K and 16K message sizes
> > and 1 and 4 instances
> >
> > Remote host to VM using 1, 4, 12 and 24 VMs (2 vCPUs) with the tests
> > running between an external host and each VM.
> >
> > Local VM to VM using 2, 4, 12 and 24 VMs (2 vCPUs) with the tests
> > running between VM pairs on the same host (no TCP_MAERTS done in
> > this situation).
> >
> > For TCP_RR and UDP_RR tests I report the transaction rate as the
> > score and the transaction rate / KVMhost CPU% as the efficiency.
> >
> > For TCP_STREAM and TCP_MAERTS tests I report the throughput in Mbps
> > as the score and the throughput / KVMhost CPU% as the efficiency.
>
> Would you mind sharing the netperf commands you are running and an
> example of the math done to arrive at the summaries presented?
I'm actually using uperf not netperf. Uperf allows me to launch
multiple instances of a test with one executable. I've provided the
XML profiles for the tests below.
The math is simply taking the score (for TCP_RR it is the tranaction
rate and for TCP_STREAM/TCP_MAERTS it is the throughput) and dividing
by the CPU utilization of the KVM host (obtained from running sar
during the test).
Here are the uperf profiles that were used. The destination,
instances and message sizes are set using environment variables.
TCP_RR
<?xml version="1.0"?>
<!--
Note: uperf reports operations/second. A transaction is made up of
two operations, so to get transactions/second (like netperf)
you must divide the operations/second by 2.
-->
<profile name="TCP_RR">
<group nprocs="$uperf_instances">
<transaction iterations="1">
<flowop type="connect" options="remotehost=$uperf_dest
protocol=tcp"/>
</transaction>
<transaction duration="$uperf_duration">
<flowop type="write" options="size=$uperf_tx_msgsize"/>
<flowop type="read" options="size=$uperf_rx_msgsize"/>
</transaction>
<transaction iterations="1">
<flowop type="disconnect" />
</transaction>
</group>
</profile>
UDP_RR:
<?xml version="1.0"?>
<!--
Note: uperf reports operations/second. A transaction is made up of
two operations, so to get transactions/second (like netperf)
you must divide the operations/second by 2.
-->
<profile name="UDP_RR">
<group nprocs="$uperf_instances">
<transaction iterations="1">
<flowop type="connect" options="remotehost=$uperf_dest
protocol=udp"/>
</transaction>
<transaction duration="$uperf_duration">
<flowop type="write" options="size=$uperf_tx_msgsize"/>
<flowop type="read" options="size=$uperf_rx_msgsize"/>
</transaction>
<transaction iterations="1">
<flowop type="disconnect" />
</transaction>
</group>
</profile>
TCP_STREAM:
<?xml version="1.0"?>
<profile name="TCP_STREAM">
<group nprocs="$uperf_instances">
<transaction iterations="1">
<flowop type="connect" options="remotehost=$uperf_dest
protocol=tcp"/>
</transaction>
<transaction duration="$uperf_duration">
<flowop type="write" options="count=16 size=$uperf_tx_msgsize"/>
</transaction>
<transaction iterations="1">
<flowop type="disconnect" />
</transaction>
</group>
</profile>
TCP_MAERTS:
<?xml version="1.0"?>
<profile name="TCP_MAERTS">
<group nprocs="$uperf_instances">
<transaction iterations="1">
<flowop type="accept" options="remotehost=$uperf_dest
protocol=tcp"/>
</transaction>
<transaction duration="$uperf_duration">
<flowop type="read" options="count=16 size=$uperf_rx_msgsize"/>
</transaction>
<transaction iterations="1">
<flowop type="disconnect" />
</transaction>
</group>
</profile>
Tom
>
> David
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2012-03-27 14:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-22 23:48 [RFC PATCH 1/1] NUMA aware scheduling per cpu vhost thread Shirley Ma
2012-03-23 0:16 ` Shirley Ma
2012-03-23 18:32 ` Thomas Lendacky
2012-03-23 19:00 ` Rick Jones
2012-03-23 21:10 ` Thomas Lendacky
2012-03-23 21:21 ` Rick Jones
2012-03-23 23:45 ` David Ahern
2012-03-27 14:34 ` Thomas Lendacky [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=2290046.f5KjQb758a@tomlt1.ibmoffice.com \
--to=tahm@linux.vnet.ibm.com \
--cc=dsahern@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=mashirle@us.ibm.com \
--cc=mst@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox