Daniel P. Berrange 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 ?
Yup. You may be sharing a physical network device via SR-IOV, but from
libvirt's perspective, we're dedicating a physical device to a guest
virtual nic.
> I think there are a few ways libvirt could support vhost-net in
this
> second mode. The simplest would be to introduce a new tag similar to
> <source network='br0'>. In fact, if you probed the device type for the
> network parameter, you could probably do something like <source
> network='eth0'> and have it Just Work.
>
> 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'
That certainly simplifies the problem.
I don't know whether SR-IOV requires additional setup though wrt
programming the VF's mac address. It may make sense for libvirt to at
least do that.
--
Regards,
Anthony Liguori