Avi Kivity wrote:
Anthony Liguori wrote:
Why not merge these bits prior to merging virtio? They aren't kvm
specific and would be good in mainline qemu.
I'd rather have a consumer of an interface before merging the actual
infrastructure.
So merge them all into qemu at the same time (as separate patches, if
you like).
But that will require refactoring a lot of these optimizations. In
order to do that right, they need to be presented on qemu-devel.
It's a whole lot easier to do that incrementally so that people can
digest it all instead of blasting a big series.
Can you elaborate? Which interfaces will need rework, and why?
Last time I tried, virtio-net doesn't work with slirp. I believe it's
either because of the GSO changes (unlikely) or because of the
can_receive changes (more likely). The can_receive changes probably
need some refactoring to be more slirp friendly. The GSO changes are a
bit vlan unfriendly.
Right now, you could construct something like -net tap -net
nic,model=virtio -net model=e1000. e1000 doesn't support GSO and bad
things will happen from this. It's very centric to the single-nic,
single-host driver model. Also, exposing something like
tap_has_vnet_hdr() to the actual network cards violates the layering.
The network cards shouldn't have any knowledge of what types of host
drivers there are, just what features a particular VLAN supports.
It's also unclear how you handle things like NIC hot-plug. What if you
add a nic that doesn't support GSO to a VLAN that is using GSO? What
about migration? What if you migrate from a host that has GSO support
to a host that doesn't support GSO? This later problem is hard and
would require either a feature renegotiation mechanism in virtio or
software implementation of GSO within QEMU.
The amount of code duplication is frightening.
I've already got that worked out. I need to prepare and commit a
patch to fix stw/lduw in upstream QEMU and then we can switch to
always using those functions in KVM. I've done some performance
testing and that seems to be enough. With that, there is no longer
any scary code duplication.
Yes, your patch on qemu-devel looks good. Even if we do have a
performance problem (which may well turn out after we optimize things
some more), it's easy to have a cached pointer along with the phys
address.
And I don't think that patch matters anymore :-/ I was doing
measurements with iperf doing TX in the guest. The numbers are very
erratic and I mistakenly attributed a boost to that patch.
Measuring based on RX seems to be more reliable since we're pegging the
CPU. We idle too much in TX due to the tx mitigation timeouts.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
