[openstack-dev] FPGA as a dynamic nested resources

Daniel P. Berrange berrange at redhat.com
Thu Jul 21 09:07:30 UTC 2016


On Thu, Jul 21, 2016 at 07:54:48AM +0200, Roman Dobosz wrote:
> On Wed, 20 Jul 2016 10:07:12 +0100
> "Daniel P. Berrange" <berrange at redhat.com> wrote:
> 
> Hey Daniel, thanks for the feedback.
> 
> > > Thoughts?
> > 
> > I'd suggest you'll increase your chances of success with nova design
> > approval if you focus on implementing a really simple usage scheme for
> > FPGA as the first step in Nova.
> 
> This. Maybe I'm wrong, but for me the minimal use case for FPGA would
> be ability to schedule VM which need certain accelerator from multiple
> potential ones on available FPGA/fixed slot. How insane does it sound?
> 
> Providing fixed, prepared earlier by DC administrator accelerator
> resource, doesn't bring much value, beyond what we already have in
> Nova, since PCI/SR-IOV passthrough might be used for accelerators,
> which expose their functionality via VF.

IIUC, there's plenty of FPGAs which are not SRIOV based, so there's
still scope for Nova enhancement in this area.

The fact that some FPGAs are SRIOV & some are not though, is is also
why I'm suggesting that any work related to FPGA should be based around
refactoring of the existing PCI device assignment model to form a more
generic "Hardware device assignment" model.  If we end up having a
completely distinct data model for FPGAs that is a failure. We need to
have a generalized hardware assignment model that can be used for generic
PCI devices, NICs, FPGAs, TPMs, GPUs, etc regardless of whether they
are backed by SRIOV, or their own non-PCI virtual functions. Personally
I'll reject any spec proposal that ignores existing PCI framework and
introduces a separate model for FPGA.

> > All the threads I've see go well off into the weeds about trying to 
> > solve everybody's niche/edge cases  perfectly and as a result get 
> > very complicated.
> 
> The topic is complicated :)

Which is why i'm advising to not try to solve the perfect case and instead
focus on getting something simple & good enough for common case.

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 :|



More information about the OpenStack-dev mailing list