From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roopa Prabhu Subject: Re: RFT: virtio_net: limit xmit polling Date: Thu, 07 Jul 2011 06:24:22 -0700 Message-ID: References: <20110629084206.GA14627@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1957387557649889097==" Cc: Krishna Kumar2 , habanero@linux.vnet.ibm.com, lguest@lists.ozlabs.org, Shirley Ma , kvm@vger.kernel.org, Carsten Otte , linux-s390@vger.kernel.org, Heiko Carstens , linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, steved@us.ibm.com, Christian Borntraeger , netdev@vger.kernel.org, Martin Schwidefsky , linux390@de.ibm.com To: "Michael S. Tsirkin" , Tom Lendacky Return-path: In-Reply-To: <20110629084206.GA14627@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org List-Id: netdev.vger.kernel.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1957387557649889097== Content-type: multipart/alternative; boundary="B_3392864662_8981458" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3392864662_8981458 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 6/29/11 1:42 AM, "Michael S. Tsirkin" 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. > --B_3392864662_8981458 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: RFT: virtio_net: limit xmit polling


On 6/29/11 1:42 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>
>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.<= BR> >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 o= ut end of this week. Thanks.

--B_3392864662_8981458-- --===============1957387557649889097== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization --===============1957387557649889097==--