From: Anthony L. <an...@co...> - 2008-05-15 15:43:51
|
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 |