Open Stack

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" <berrange at 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 :|