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. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- 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
