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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
