Anthony Liguori wrote: > Anthony Liguori wrote: >> While it has served us well, it is long overdue that we eliminate the >> virtio-net tap hack. It turns out that zero-copy has very little >> impact on >> performance. The tap hack was gaining such a significant performance >> boost >> not because of zero-copy, but because it avoided dropping packets on >> receive >> which is apparently a significant problem with the tap implementation >> in QEMU. >> > > FWIW, attached is a pretty straight forward zero-copy patch. What's > interesting is that I see no change in throughput using this patch. > The CPU is pegged at 100% during the iperf run. Since we're still > using small MTUs, this isn't surprising. Copying a 1500 byte packet > that we have to bring into the cache anyway doesn't seem significant. > I think zero-copy will be more important with GSO though.
Zero copy is important when the guest is zero copy, and when we are not doing any extra copying on the host. This doesn't fit the way we benchmark. I expect zero copy to show improvements on things like apachebench (with a file size > 50K) with an external client. The improvements will also show up on SMP, where the likelihood of the copy happening on the wrong cpu increase. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
