Mark McLoughlin wrote:
Hi Alex,
Just had a quick looked over these and they seem pretty good, but some
broad comments:
- The logic around "is this a NIC+TAP pair?" would be good to have a
better API around. We need this to merge virtio GSO support too.
Anthony had some ideas here.
Right now, the networking API is based on VLANs and VLAN clients. This
is fine for a simple interface of sending/receiving packets one at a time.
When you want to support special features (like filtering, GSO) or want
to supply many receive buffers, this falls apart because the VLAN client
needs to consider what features are supported by every other VLAN client
and also deal with things like hot add/remove from a VLAN.
A better architecture IMHO would be to have a NIC backend/frontend
architecture. This provides a rather simple interface to support
feature negotiation and optimizes the interface for the common case (one
VLAN client per VLAN).
You would then implement the VLAN layer as a NIC backend. The
user-visible interface wouldn't change at all. You could even go as far
as to special case the circumstance where you had a VLAN containing one
host device and one guest device and simply avoid using the VLAN at all.
Regards,
Anthony Liguori
- I think you could keep the client_added()/removed() logic in net.c
and things would be a lot cleaner. I think you just want to trigger
a reload of the filter, right? So a "reload this filter" callback
to qemu_vlan_rxfilter() might do it.
- What do we need rxfilter=on|off on the command line for?
Cheers,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
