From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [ANNOUNCE] kvm-guest-drivers-windows-2 Date: Thu, 15 May 2008 10:43:49 -0500 Message-ID: <482C5A35.1030802@codemonkey.ws> References: <482AEE8D.7000608@wpkg.org> <1210777782.24261.829.camel@localhost.localdomain> <482B09EE.20903@wpkg.org> <1210781968.24261.841.camel@localhost.localdomain> <482B2649.2090006@codemonkey.ws> <482BEDCD.7050308@qumranet.com> <482C4133.7010000@codemonkey.ws> <482C5705.3070509@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel@lists.sourceforge.net, Tomasz Chmielewski To: Avi Kivity Return-path: In-Reply-To: <482C5705.3070509@qumranet.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org Avi Kivity wrote: > Anthony Liguori wrote: >> Avi Kivity wrote: >>> Anthony Liguori wrote: >>>> FWIW, virtio-net is much better with my patches applied. >>> >>> The can_receive patches? >>> >>> Again, I'm not opposed to them in principle, I just think that if >>> they help that this points at a virtio deficiency. Virtio should >>> never leave the rx queue empty. Consider the case where the virtio >>> queue isn't tied to a socket buffer, but directly to hardware. >> >> For RX performance: >> >> >> right now >> [ 3] 0.0-10.0 sec 1016 MBytes 852 Mbits/sec >> >> revert tap hack >> [ 3] 0.0-10.0 sec 564 MBytes 473 Mbits/sec >> >> all patches applied >> [ 3] 0.0-10.0 sec 1.17 GBytes 1.01 Gbits/sec >> >> drop lots of packets >> [ 3] 0.0-10.0 sec 1.05 GBytes 905 Mbits/sec >> >> >> The last patch is not in my series but it basically makes the ring >> size 512 and drops packets when we run out of descriptors. That was >> to valid that we're not hiding a virtio deficiency. The reason I >> want to buffer packets is that it avoids having to deal with >> tuning. For vringfd/vmdq, we'll have to make sure to get the tuning >> right though. > > Okay; I'll apply the patches. Hopefully we won't diverge too much > from upstream qemu. I am going to push these upstream. I need to finish the page_desc cache first b/c right now the version of virtio that could go into upstream QEMU has unacceptable performance for KVM. Regards, Anthony Liguori ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/