[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B32315C.1000006@codemonkey.ws>
Date:	Wed, 23 Dec 2009 09:03:56 -0600
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Andi Kleen <andi@...stfloor.org>
CC:	Avi Kivity <avi@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Gregory Haskins <gregory.haskins@...il.com>,
	kvm@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>,
	torvalds@...ux-foundation.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	netdev@...r.kernel.org,
	"alacrityvm-devel@...ts.sourceforge.net" 
	<alacrityvm-devel@...ts.sourceforge.net>
Subject: Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33
On 12/23/2009 06:14 AM, Andi Kleen wrote:
>> http://www.redhat.com/f/pdf/summit/cwright_11_open_source_virt.pdf
>>
>> See slide 32.  This is without vhost-net.
>
> Thanks. Do you also have latency numbers?
They'll be along the lines of the vbus numbers.
But I caution people from relying too much on just netperf TCP_RR and 
TCP_STREAM numbers.  There's a lot of heuristics in play in getting this 
sort of numbers.  They really aren't good ways to compare different drivers.
A better thing to do is look more deeply at the architectures and 
consider things like the amount of copying imposed, the cost of 
processing an exit, and the mechanisms for batching packet transmissions.
The real argument that vbus needs to make IMHO is not "look how much 
better my netperf TCP_STREAM results are" but "we can eliminate N copies 
from the transmit path and virtio-net cannot" or "we require N exits to 
handle a submission and virtio-net requires N+M".
It's too easy to tweak for benchmarks.
Regards,
Anthony Liguori
--
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
Powered by blists - more mailing lists
 
