Acceleration Management Architectures in OpenStack Nomad and DPACC
The figures depict the architecture of Software Acceleration Layer (SAL), Acceleration Management Layer (AML), and other components in OpenStack Nomad and DPACC. They illustrate the interaction between Software Routing Layer (SRL), General Drivers (g-drivers), Hardware I/O Interface (hio), and more in providing acceleration for virtual machines. The visuals show how different layers and components collaborate to manage acceleration functionalities efficiently in virtualized environments.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Figure C: From DPACC Architecture SAL: Software Acceleration Layer Provides an abstraction between SW and HW VM 1 VM 4 VM 0 VM 2 VM 3 sio-backend: backend of paravirtualized drivers vHost-user: User space based VirtIO interface optional for VM host access sio-backend (optional vHost-user) Software Routing Layer (SRL) s-API: APIs for utilizing an AC (APIs from the AC) Software Acceleration Layer (SAL) Acceleration Management Layer g-drivers: General driver for each device type Implemented in software or the frontend to the hardware (may be different for different acceleration functions) s-API hio: Hardware I/O interface Non-virtualized, accessed only by host SAL Acceleration Core (AC) Buffer and memory mgnt, rings/queues, ingress/egress scheduling, tasks, pipeline, AC: Software/Hardware Acceleration Core e.g. DPDK, ODP or other acceleration implementation g-drivers SW-crypto or drivers for HW-crypto SRL: Software Routing Layer (Optional layer for the host) Open vSwitch (OVS) or vRouter hio AML: Acceleration Management Layer To be define for orchestration and spans more than the SAL
Figure 3-2 VIM-NFVI acceleration management architecture Questions for discussion guest VM 0 VM 3 VM 4 VM 1 VM 2 1. 2. EPD is not existent in DPACC arch, sio? and indicate that AML is using userland g-drivers instead of acc drivers in Hypervisor for device access. Current DPACC Arch does not include any components from host kernel. In previous figure, it is not clear whether accelerator driver is in host kernel or not. And it is clear there is a EPD backend driver in hypervisor. need another arrow between Compute Management Function and Acceleration Management Function? For VNF deployment events as described later in Section 5. need to extend sio-backend to expose the host AML to guest? There are such interactions in the previous figure between guest and host. DPACC Management (VIM-NFVI) sio-backend (optional) Acceleration Management Layer SRL Compute Management Layer VIM Acceleration Agent Compute Agent* Compute Agent* s-API Compute Management Function host Acceleration Core (AC) Acceleration Management Function g-drivers 3. SW-crypto or drivers for HW-crypto hio SAL Hypervisor Control node 4. CPU/Mem/Disk Accelerator device * Compute agent collaborates with Acceleration agent for VM lifecycle managements. Compute node
