[openstack-dev] FPGA as a dynamic nested resources

Fei K Chen uchen at cn.ibm.com
Thu Jul 21 00:56:07 UTC 2016



Roman Dobosz <roman.dobosz at intel.com> wrote on 2016/07/20 15:25:28:

> From: Roman Dobosz <roman.dobosz at intel.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Cc: Ed Leafe <ed at leafe.com>
> Date: 2016/07/20 15:30
> Subject: Re: [openstack-dev] FPGA as a dynamic nested resources
>
>
> > > 4. It might be also necessary to track every VF individually,
although
> > >   I didn't assumed it will be needed, nevertheless with nested
> > >   resources it should be easy to handle it.
> >
> > I’m still not seeing the need for nesting. If you have a single FPGA
> > with 8 slots, when you program the slots with accelerators, you now
> > have 8 consumable resources. The fact that they came from a
> > particular FPGA unit doesn’t seem relevant from a scheduling
> > perspective.
>
> Unless you have one FPGA with 8 slots, which can become FPGA with 4
> slots. From scheduling perspective you have to know, which FPGA
> resources can be reconfigured, and which not, isn't it? Also, AFAIRC
> to provide VM with VF, there is a need for providing libvirt with
> address of such VF, right? That's why I've putted this last point.
>
> The whole idea of getting FPGA as resource is its ability to swap
> resources on demand. So it can be thought of as several available
> hardware (means - accelerators, consumable by VMs) which most of the
> time are not programmed in certain moment.
>
Let's have more thought about the resource swapping. The number of run-time
accelerators is not limited by the number of region/slot. Inside FPGA,
there
can be some self-scheduling logic to schedule accelerators on regions by
using
the fast partial reconfiguration. It is not new, there are lots of such
design in FPGA academic.


-- Fei Chen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160721/eee90a90/attachment.html>


More information about the OpenStack-dev mailing list