Re: RFT: virtio_net: limit xmit polling

From: Roopa Prabhu <roprabhu@cisco.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
	Tom Lendacky <tahm@linux.vnet.ibm.com>
Cc: Krishna Kumar2 <krkumar2@in.ibm.com>,
	habanero@linux.vnet.ibm.com, lguest@lists.ozlabs.org,
	Shirley Ma <xma@us.ibm.com>,
	kvm@vger.kernel.org, Carsten Otte <cotte@de.ibm.com>,
	linux-s390@vger.kernel.org,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org, steved@us.ibm.com,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	netdev@vger.kernel.org,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	linux390@de.ibm.com
Subject: Re: RFT: virtio_net: limit xmit polling
Date: Thu, 07 Jul 2011 06:24:22 -0700	[thread overview]
Message-ID: <CA3B0196.2D7A9%roprabhu@cisco.com> (raw)
In-Reply-To: <20110629084206.GA14627@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 1756 bytes --]


On 6/29/11 1:42 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
>> >roprabhu, Tom,
>> >
>> >Thanks very much for the testing. So on the first glance
>> >one seems to see a significant performance gain in V0 here,
>> >and a slightly less significant in V2, with V1
>> >being worse than base. But I'm afraid that's not the
>> >whole story, and we'll need to work some more to
>> >know what really goes on, please see below.
>> >
>> >
>> >Some comments on the results: I found out that V0 because of mistake
>> >on my part was actually almost identical to base.
>> >I pushed out virtio-net-limit-xmit-polling/v1a instead that
>> >actually does what I intended to check. However,
>> >the fact we get such a huge distribution in the results by Tom
>> >most likely means that the noise factor is very large.
>> >
>> >
>> >From my experience one way to get stable results is to
>> >divide the throughput by the host CPU utilization
>> >(measured by something like mpstat).
>> >Sometimes throughput doesn't increase (e.g. guest-host)
>> >by CPU utilization does decrease. So it's interesting.
>> >
>> >
>> >Another issue is that we are trying to improve the latency
>> >of a busy queue here. However STREAM/MAERTS tests ignore the latency
>> >(more or less) while TCP_RR by default runs a single packet per queue.
>> >Without arguing about whether these are practically interesting
>> >workloads, these results are thus unlikely to be significantly affected
>> >by the optimization in question.
>> >
>> >What we are interested in, thus, is either TCP_RR with a -b flag
>> >(configure with  --enable-burst) or multiple concurrent
>> >TCP_RRs.
> 
> ok sounds good. I am testing your v1a patch. Will try to get some results out
> end of this week. Thanks.
> 


[-- Attachment #1.2: Type: text/html, Size: 2328 bytes --]

[-- Attachment #2: Type: text/plain, Size: 184 bytes --]

_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization