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. s. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
