Accelerator Management g-API’s S.No IPSec – Look Aside Accelerator PDCP – Look Aside Accelerator 1 g_ipsec_la_get_api_version g_pdcp_la_get_api_version 2 g_ipsec_la_open g_pdcp_la_open 3 g_ipsec_la_close g_pdcp_la_close 4 g_ipsec_la_group_delete 5 g_ipsec_la_group_create 6 g_ipsec_la_get_available_list 7 g_ipsec_la_get_active_list 27/10/2019

How to common gAPI (IPSec/PDCP etc.,) The below challenges needs to be discussed to make the Management API’s in common Management Abstraction layer should be super set of all the accelerators. Managing the multiple api version of different lookaside accelerators. Performance overhead on the system, where only one accelerators is used. Multiple instance management for the supported/unsupported accelerators Managing the similarity between the uspace/kspace applications Growing API set for addition of new accelerators All Application has to be changed for the changes in the API parameters VNF Application 1 VNF Application 1 g-API Management Abstraction layer g-API - control g-API - data legacy-API g-API - control g-API - data legacy-API Acceleration Core (AC) e.g. DPDK, ODP or another acceleration implementation s-API Acceleration Core (AC) e.g. DPDK, ODP or another acceleration implementation s-API Software Acceleration Layer (SAL) Buffer and memory mgnt, rings/queues, ingress/egress scheduling, tasks, pipeline, … g-drivers for (paravirtualized) SW/HW-funcs Buffer and memory mgnt, rings/queues, ingress/egress scheduling, tasks, pipeline, … g-drivers for (paravirtualized) SW/HW-funcs sio + VirtIO hio sio + VirtIO hio This view is attempting to how the DPACC layer and configuration can be designed by the developer to give his application the best accelerated performance. In this picture having a software acceleration layer in the host would provide the best performance and flexibility for a VNF application.