Hi all,

In the current SR-IOV implementation there is a check in Nova (specifically 
_get_device_type in nova/virt/libvirt/driver.py) that determines if a given PCI 
device is:

- a normal PCI device,
- an SR-IOV physical function (PF); or
- an SR-IOV virtual function (VF).

If it's a normal PCI device or a virtual function it's considered fair game for 
passthrough, if it's a PF it's not (considered to be owned by the host). There 
are two things I am a little unclear on and was hoping someone might be able to 
help me understand:

1) If the device is a "normal" PCI device, but is a network card, am I still 
able to take advantage of the advanced syntax added circa Juno to define the 
relationship between that card and a given physical network so that the 
scheduler can place accordingly (and does this still use the ML2 mech drvier 
for SR-IOV even though it's a "normal" device.

2) There is no functional reason from a Libvirt/Qemu perspective that I 
couldn't pass through a PF to a guest, and some users have expressed surprise 
to me when they have run into this check in the Nova driver. I assume in the 
initial implementation this was prevented to avoid a whole heap of fun 
additional logic that is required if this is allowed (e.g. check that no VFs 
from the PF being requested are already in use, remove all the associated VFs 
from the pool when assigning the PF, who gets allowed to use PFs versus VFs 
etc.). Am I correct here or is there another reason that this would be 
undesirable to allow in future - assuming such checks can also be designed - 
that I am missing?

Thanks,

Steve

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to