On Thursday 17 December 2009, Daniel P. Berrange wrote:
On Wed, Dec 16, 2009 at 07:48:08PM -0600, Anthony Liguori wrote:
The more interesting invocation of vhost-net though is one where the vhost-net device backs directly to a physical network card. In this mode, vhost should get considerably better performance than the current implementation. I don't know the syntax yet, but I think it's reasonable to assume that it will look something like -net tap,dev=eth0. The effect will be that eth0 is dedicated to the guest.
Ok, so in this model you have to create a dedicated ethXX device for every guest, no sharing ?
I think so, but it could be any of * a physical NIC dedicated to the guest, e.g. if you want to run a firewall on that guest and provide connectivity to all other guests to that, or if you have lots of real NICs * an IOV adapter with separate physical or virtual functions * a VMDq adapter that shows multiple queues on the same PCI function as separate network interfaces * a macvlan device in VEPA or bridge mode The creation for each of these is different, but once it's there, using it should be possible in identical ways. I think an important question here is if libvirt should at all be responsible for creating the devices, or just for opening the sockets or taps on them.
Yes, since the hardware doesn't allow for any usable configurability of the number of VFs, we'll guest assume that they have already been setup. Likely the kernel can just enable the max # of VFs at all times.
In macvlan, there is no such limitation. How many would you create?
Another model would be to have libvirt see an SR-IOV adapter as a network pool whereas it handled all of the VF management. Considering how inflexible SR-IOV is today, I'm not sure whether this is the best model.
Agreed, given the hardware limitations I don't see that it is worth the bother.
This new mode is not really what we'd call 'bridging' in libvirt network XML format, so I think we'll want to define a new type of network config for it in libvirt. Perhaps
<network type='physical'> <source dev='eth0'/> </network>
Or type='passthru'
You should also have a parameter mode={'vepa'|'bridge'|'private'} like macvlan now has. Even if SR-IOV nics today only support bridge mode, they should support at least vepa mode in the future. Arnd