> On Jul 28, 2016, at 7:57 AM, Jay Pipes <jaypi...@gmail.com> wrote: > > On 07/19/2016 06:51 PM, Ed Leafe wrote: >> On Jul 19, 2016, at 2:58 PM, Chris Friesen >> <chris.frie...@windriver.com> wrote: >>>> 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? >> >> That doesn’t sound right to me, but maybe I’m just not that familiar >> with FPGA specifics. In general, VMs don’t control their hosts. > > Oh, but in NFV-land they most certainly do. :/ > > It's commonplace now to see NFV use cases where VMs are provided passthrough > access to an SR-IOV physical function on the host and the VMs application > code then controls and allocates at will virtual functions from that physical > function. Once that happens, yes, it's true that Nova no longer has any clue > about the resource usage of VFs on that host device -- it's essentially at > that point totally up to the VNF software to properly manage and maintain > access to those VFs and allocate/free resources as needed on the host device. > Agreed as a statement of today. Once the “VM” application has what looks like dedicated FPGA resources to it, it typically does both management and optionally the actual application workload. That typically includes loading the bitstream on the device as well and then executing API calls to the service it then provides. This can all be done now with PCIe/SR-IOV , which is great….
But the generic boards are getting bigger and we often want greater utilization of them and to virtualize and manage them separately from the VM based application code that may utilize them. In other words these “funky” devices are becoming hosts for dynamically loaded services. While a key first step to enable allocating the virtual region of the device to a VM when it is provisioned, we may want to enable separating management from data plane (aka workload) and support dynamic service consumption through more than network connections. VNFs are a use case for sure and a dominant one, but now that we have NICs on these large boards and also want to support service chaining, we have the opportunity to do that without consuming many CPU cycles. When I can push firewall, or ipsec or compression to the “NIC” and not use CPU cycles, why not ;-), and why not share it to other nearby VMs. Then take it past VNFs to other workloads that can exploit FPGA... > Same goes for FPGAs. VNF vendors want access to the physical host device and > want to be able to do with that host device whatever they please. > > As I wrote on Twitter recently, NFV is changing software-defined > infrastructure to instead be hardware-defined software. > > It's a funky new* world we live in, Ed :) > > -jay > > * new == old == new again. > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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
