Vfpgamanager: A Hardware-Software Framework for Optimal FPGA Resources Exploitation in Network Function Virtualization

The emergence of Network Function Virtualization (NFV) has turned dedicated hardware devices (routers, firewalls, wide area network accelerators) to Virtual Machines (VMs). However, the execution of these Virtualized Network Functions (VNF) in general purpose hardware brings slower performance and higher energy consumption. Field Programmable Gate Arrays (FPGAs) are a promising solution to improve performance and energy consumption thanks to their reconfigurable fabric and acceleration capabilities. These capabilities are in general made available to computing systems through the PCIe bus and the SR-IOV technology that enables a single PCIe device to offer multiple virtual interfaces (Virtual Functions or VFs) to the applications (or VMs). This brings static allocation of FPGA portions to each virtual machine, achieving best acceleration performance given by the direct communication of guests application with the FPGA fabric. Despite that, SR-IOV has a strong impact on the FPGA resources usage. In fact, the number of available VFs (i.e., interfaces for connection to the VMs) is limited in number and flexibility. This is a problem, especially in containerized or cloud native environments where several thousands of guests need to be run concurrently. In addition, static assignment of FPGA resources might not always be the best strategy, especially when the VNFs that are attached to VFs underutilize the FPGA resource. In that case, a VNF that rarely uses the FPGA prevents a new VNF from accessing the accelerators. This paper aims to address these limitations by assigning one FPGA's VF to multiple VNFs. To do this, we extended the SR-IOV based acceleration framework FPGA Virtualization Manager (vFPGAmanager) with VF sharing feature. The CPU-FPGA throughput performance of two containers using different hardware accelerators through the same VF has been measured. The results show a penalty of 30% when two VNFs request acceleration at the same time (worst case scenario). In the best case (i.e., when the VNFs don't concurrently request FPGA acceleration) close to native performance is achieved.