On 07/19/2016 01:40 PM, Ed Leafe wrote:
On Jul 19, 2016, at 11:03 AM, Roman Dobosz <roman.dob...@intel.com> wrote:
It can identified 3 levels of FPGA resources, which can be nested one
on the others:
1. Whole FPGA. If used discrete FPGA, than even today it might be pass
through to the VM.
Can you explain why this would ever be useful? IOW, what can a VM do with an
entire FPGA?
2. Region in FPGA. Some of the FPGA models can be divided into regions
or slots. Also, for some model it is possible to (re)program such
region individually - in this case there is a possibility to pass
entire slot to the VM, so that it might be possible to reprogram
such slot, and utilize the algorithm within the VM.
Why would a VM program the slot? Wouldn’t it usually be at the host level?
Are there no cases where a VM might want to download a proprietary program into
an FPGA?
3. Accelerator in region/FPGA. If there is an accelerator programmed
in the slot, it is possible, that such accelerator provides us with
Virtual Functions (similar to the SR-IOV), than every available VF
can be treated as a resource.
This is my understanding of what would be consumable: the slot / VF, which the
VM could take advantage of.
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.
If you want to be able to provide an FPGA as either a whole un-programmed FPGA
or as pre-programmed resources, you'd presumably need to know which whole FPGAs
are available and which have been fractionally allocated, no?
I agree that if you are only going to have the host program the FPGA and then
make the resources available then the scheduler doesn't need to know about whole
FPGAs.
Chris
__________________________________________________________________________
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
