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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list