Cloud native architecture is emerging for Telecom workloads. To support these emerging trends, Intel is targeting enhancements to the Dataplane Development Kit (DPDK). The enhancements would target network service mesh with dedicated sidecar accelerators and the mechanism to build the mesh dynamically.
Speaker: Gerald Rogers. Gerald Rogers is a Principal Engineer in the Network Products Group focused on virtual switching, network function virtualization and Data Plane Development Kit (DPDK). After joining Intel in 2005, Gerald has worked as a software engineer and architect in the embedded and networking groups. For the past 7 years Gerald has led the network virtual switching software and hardware acceleration effort to drive Intel architecture into the networking and telecommunications industry. Gerald holds a Bachelor’s degree in Electrical Engineering and a Master’s degree in Computer Science, and has 20 years of experience in the networking and telecommunications industry.
2. 2
Original ETSI NFV Goals
• Improved CAPEX via COTS (instead of
dedicated hardware)
• Flexibility in assigning VNFs to hardware
• Rapid service innovation
• Improved OPEX from automation
• Reduced power usage by migrating workloads
(so unused hardware can be powered down)
• Standardized and open interfaces between
VNF and NFVI (to enable multi-vendor
solutions)
In the beginning….
VNF 1 VNF 2 VNF 3
NFVI
NFVI Hardware
NFVI Software
Adapted from: http://www.etsi.org/deliver/etsi_gs/nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf
MANO
4. Custom HW
Proprietary
Framework
4
Physical to Cloud Native
Service
COTS
VM
Proprietary
Framework
Service
COTS
Containers/Pods
Open Framework
Micro
Service
Micro
Service
Micro
Service
Micro
Service
COTS
Container or VM
Mixed
Framework
Service
Physical NFV Cloud Ready Cloud Native
Vendor Open
5. Computer A
POD
Service Mesh Concepts:
Service A
Framework
Platform Infrastructure
Protocol Stack
Sidecar
Service
Proxy
Computer B
Platform Infrastructure
Protocol Stack
Service B
Framework
Sidecar
Service
Proxy
Service A
Framework
Service B
Framework
POD
6. Native DPDK
Applications
DPDK view of Cloud Native
6
Runtime Dynamic Orchestration
Support both VM and Container
Sidecar, VM or Native Host
applications have access to HW
Sidecar is trusted and provides to
other containers/VM services
(switching, accelerator, etc.)
Orchestration
Hardware Devices
Linux Kernel
DPDK
Host and/or containers
“Trusted Sidecar”
Native DPDK
Applications
DPDK
Host and/or containers
“Trusted Sidecar”
DPDK
Host and/or containers
“Trusted Sidecar”
Application
Containers or VM’s
Applications are able
to bypass sidecar to
HW
7. I/O to HW or virtual devices
SR-IOV, SIOV, memif, VirtIO, …
DPDK Trusted Sidecar I/O Container
7
Trusted Sidecar
DPDK
NICs
Intel®
QAT vEth memif VirtIO
Software Patch Panel
Sidecar detail view
Trusted Sidecar
Sidecar functional view
Application Containers
VirtIO, vCH, memif, …
Direct access to
hardware is supported
Ether
PMD
Crypto
PMD
Compress
PMD
mDev Device
Class PMDs
Raw
PMD
Device PMDs
DPDK provides abstraction of devices, removing need for application to
be device aware.
Interconnectivity between containers, VM, and accelerator via standard
interfaces.
8. DPDK Runtime Coordination
8
DPDK
DPDKRuntimeCoordination
(librte_drc)
Applications
ethdev cryptodev rawdev eventdev
FUSE
Filesystem
External
Orchestration
Layer
xyzdev compressdev
Service
chain
1
• DPDK coordination library provides the connection between the FUSE filesystem and DPDK
• Each DPDK instance has it own filesystem path and configuration/information files
• The external or orchestration agents interact with the FUSE filesystem to Get/Set
information/configuration at runtime
• Librte_drc access/configures DPDK/system via standard dev APIs and/or new APIs in these dev layers
• Providing an API for applications to add to the FUSE file system for configuration
Service
chain
2
Service
chain
3
….
Service
chain
N
Standard
Applications
9. Applications
Service: Application Abstraction Layer
Building a hardware/software application abstraction layer
9
DPDK
DPDKOrchestrationlibrary
(librte_drc)
ethdev cryptodev rawdev eventdev
FUSE
Filesystem
External
Orchestration
Layer
xyzdev compressdev
Service
chain
1
• New DPDK library librte_aal (optional for applications)
• Providing a higher layer abstraction for applications using standard DPDK APIs
• Giving the application developer a simpler set of APIs, which helps hide some of the more
complexed APIs in DPDK and/or structures, but still able to use DPDK APIs
• Hiding the nature of the hardware or software under the hood allowing the AAL layer to
decide which type to use and when
Service
chain
2
Standard
Applications
….
Service
chain
N
DPDK
Applications
Service: Application Abstraction Layer (librte_aal)
10. 10
Software Patch Panel
DPDK resource manager
Centralizes DPDK platform resource control.
Utilizes an inter-process via sockets to
configure and assign resources to an
application
Provides an API component that DPDK
applications interface via inter-process to
provide resource assignment.
Enhancements to include DPDK runtime
coordinator for file system configuration.
Trusted Sidecar
DPDK
NICs
Intel®
QAT vCH memif VirtIO
Software Patch Panel
Sidecar detail view
Ether
PMD
Crypto
PMD
Compress
PMD
Raw
PMD
11. 11
Summary
• Cloud Native emerging as solution space
• DPDK foundation was set for NFV acceleration
• Build on NFV work to Improve DPDK for Cloud Native
• New API’s (Fuse file system, service abstraction layer)
• Cloud Native sidecar to facilitate container interaction with physical devices
• “Trusted” proxy for containers and VM to interact with other containers.