Anthony Liguori wrote:
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.
Okay, we can go along with mangling the current virtio implementation
like you proposed.
--
error compiling committee.c: too many arguments to function
--
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
