On Wed, Apr 06, 2016 at 07:34:46AM +0200, Roman Dobosz wrote: > On Tue, 5 Apr 2016 13:58:44 +0100 > "Daniel P. Berrange" <berra...@redhat.com> wrote: > > > Along similar lines we have proposals to add vGPU support to Nova, > > where the vGPUs may or may not be exposed using SR-IOV. We also want > > to be able to on the fly decide whether any physical GPU is assigned > > entirely to a guest as a full PCI device, or whether we only assign > > individual "virtual functions" of the GPU. This means that even if > > the GPU in question does *not* use SR-IOV, we still need to track > > the GPU and vGPUs in the same way as we track PCI devices, so that > > we can avoid assigning a vGPU to the guest, if the underlying physical > > PCI device is already assigned to the guest. > > That's correct. I'd like to mention, that FPGAs can be also exposed > other way than PCI (like in Xeon+FPGA). Not sure if this also applies > to GPU. > > > I can see we will have much the same issue with FPGAs, where we may > > either want to assign the entire physical PCI device to a guest, or > > just assign a particular slot in the FPGA to the guest. So even if > > the FPGA is not using SR-IOV, we need to tie this all into the PCI > > device tracking code, as we are intending for vGPUs. > > > > All in all, I think we probably ought to generalize the PCI device > > assignment modelling so that we're actually modelling generic > > hardware devices which may or may not be PCI based, so that we can > > accurately track the relationships between the devices. > > > > With NIC devices we're also seeing a need to expose capabilities > > against the PCI devices, so that the schedular can be more selective > > in deciding which particular devices to assign. eg so we can distinguish > > between NICs which support RDMA and those which don't, or identify NIC > > with hardware offload features, and so on. I can see this need to > > associate capabilities with devices is something that will likely > > be needed for the FPGA scenario, and vGPUs too. So again this points > > towards more general purpose modelling of assignable hardware devices > > beyond the limited PCI device modelling we've got today. > > > > Looking to the future I think we'll see more usecases for device > > assignment appearing for other types of device. > > > > IOW, I think it would be a mistake to model FPGAs as a distinct > > object type on their own. Generalization of assignable devices > > is the way to go > > That's why I've bring the topic here on the list, so we can think about > similar devices which could be generalized into one common accelerator > type or even think about modeling PCI as such.
I wouldn't specialize it to "accelerators" as we'll inevitably come across a need for other types of device assignment. We should just generalize it to track *any* type of host hardware device that is potentially assignable. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __________________________________________________________________________ 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