Open Stack

On 09/25/2017 05:39 AM, Sahid Orentino Ferdjaoui wrote:
> There is a desire to expose the vGPUs resources on top of Resource
> Provider which is probably the path we should be going in the long
> term. I was not there for the last PTG and you probably already made a
> decision about moving in that direction anyway. My personal feeling is
> that it is premature.
> 
> The nested Resource Provider work is not yet feature-complete and
> requires more reviewer attention. If we continue in the direction of
> Resource Provider, it will need at least 2 more releases to expose the
> vGPUs feature and that without the support of NUMA, and with the
> feeling of pushing something which is not stable/production-ready.
> 
> It's seems safer to first have the Resource Provider work well
> finalized/stabilized to be production-ready. Then on top of something
> stable we could start to migrate our current virt specific features
> like NUMA, CPU Pinning, Huge Pages and finally PCI devices.
> 
> I'm talking about PCI devices in general because I think we should
> implement the vGPU on top of our /pci framework which is production
> ready and provides the support of NUMA.
> 
> The hardware vendors building their drivers using mdev and the /pci
> framework currently understand only SRIOV but on a quick glance it
> does not seem complicated to make it support mdev.
> 
> In the /pci framework we will have to:
> 
> * Update the PciDevice object fields to accept NULL value for
>    'address' and add new field 'uuid'
> * Update PciRequest to handle a new tag like 'vgpu_types'
> * Update PciDeviceStats to also maintain pool of vGPUs
> 
> The operators will have to create alias(-es) and configure
> flavors. Basically most of the logic is already implemented and the
> method 'consume_request' is going to select the right vGPUs according
> the request.
> 
> In /virt we will have to:
> 
> * Update the field 'pci_passthrough_devices' to also include GPUs
>    devices.
> * Update attach/detach PCI device to handle vGPUs
> 
> We have a few people interested in working on it, so we could
> certainly make this feature available for Queen.
> 
> I can take the lead updating/implementing the PCI and libvirt driver
> part, I'm sure Jianghua Wang will be happy to take the lead for the
> virt XenServer part.
> 
> And I trust Jay, Stephen and Sylvain to follow the developments.

I understand the desire to get something in to Nova to support vGPUs, 
and I understand that the existing /pci modules represent the 
fastest/cheapest way to get there.

I won't block you from making any of the above changes, Sahid. I'll even 
do my best to review them. However, I will be primarily focusing this 
cycle on getting the nested resource providers work feature-complete for 
(at least) SR-IOV PF/VF devices.

The decision of whether to allow an approach that adds more to the 
existing /pci module is ultimately Matt's.

Best,
-jay