This section gives a global overview of the architecture of Cloud Native Data Plane (CNDP).
The main goal of the CNDP is to provide a simple, complete framework for fast packet processing in Cloud Native data plane applications. Users may use the code to understand some of the techniques employed, to build upon for prototyping or to add their own protocol stacks.
2.1. Development Environment¶
The CNDP project installation requires Linux and the associated toolchain, such as one or more compilers, assembler, make utility, editor and various libraries to create the CNDP components and libraries.
See the CNDP Getting Started Guide for information on setting up the development environment.
CNDP provides a number of libraries and tools that can be catagorised as follows:
Core libraries: the core libraries for interacting with an lport
Application libraries: libraries with additional functionality that can be used by apps.
PMDs: the PMDs enabled in CNDP.
Functional Test: testcne - a functional test framework.
Ansible Playbooks: Playbooks for setting up the CNDP Development environment.
Docker and Kubernetes: Docker files, Pod specs and instructions for getting started with CNDP in a Kubernetes env.
An incomplete picture of the architecture is shown here.
The following section shows the breakdown of these libraries under the lib/core directory.
2.2.1. Cloud Native Environment (cne)¶
Initializes the application environment and provides runtime services like unique thread ids.
Library to manage epoll event callbacks.
Hash table implementation with various hash functions.
2.2.4. Key Value¶
Library to parse key-value pairs.
Logging services with various debug levels.
2.2.6. Memory Pool Manager¶
The Memory Pool Manager is responsible for allocating pools of objects in memory. A pool is identified by name and uses a ring to store free objects. It provides some other optional services, such as a per-core object cache and an alignment helper to ensure that objects are padded to spread them equally on all DRAM channels.
This memory pool allocator is described in Mempool Library.
2.2.7. Memory Map (mmap)¶
A memory allocator using mmap(). This memory is usually passed to a mempool.
2.2.8. OS Abstraction Layer (osal)¶
Library to abstract some things like reading cpu counts from the file-system or interacting with a netdev.
2.2.9. Network Packet Buffer Management (pktmbuf)¶
The pktmbuf library provides the facility to create and destroy buffers that may be used by the CNDP application to store message buffers. The message buffers are created at startup time and stored in a mempool, using the CNDP mempool library.
This library provides an API to allocate/free mbufs, manipulate packet buffers which are used to carry network packets.
Network Packet Buffer Management is described in pktmbuf Library.
2.2.10. Poll-Mode Drivers (pmds)¶
PMDs implement the pktdev API. For more information, see PMD Guide.
The ring structure provides a lockless multi-producer, multi-consumer FIFO API in a finite size table. It has some advantages over lockless queues; easier to implement, adapted to bulk operations and faster. A ring is used by the Memory Pool Manager (mempool) and may be used as a general communication mechanism between cores and/or execution blocks connected together on a logical core.
This ring buffer and its usage are fully described in Ring Library.
2.2.12. Tx Buffer (txbuff)¶
Provide buffering for packets before transmission.
This is a low level API that abstracts some of the complexities of AF_XDP sockets.
This is a high level API that allows you to interact with a number of underlying devices such as rings and AF_XDP sockets. It has inbuilt mempool management and uses the xskdev APIs to create and manage logical ports.
2.2.15. Application Libraries (lib/usr/app)¶
Libraries providing services for applications such as json-c config file parsing and Unix Domain Socket (UDS) handling.
2.2.16. C Language Libraries (clib)¶
Libraries providing services to packet processing applications such as Access Control List (ACL) and timer implementations.
ACL an AVX 512 enabled Access Control List library
cthread a userspace lightweight threading library
Intel(R) Data Streaming Accelerator (Intel(R) DSA)
2.3. CNET - Cloud Native Network stack (lib/cnet)¶
The libraries under the cnet directory create the CNET stack, which uses the Graph Library. These include nodes for UDP/IPv4/QUIC with IPv6/TCP in the future.
The CNET stack gets most of its configuration via netlink messages. Using netlink allows CNET to be
configured via the host command line tools. Using tools like
arp the user
can configure the CNET and allow CNET to detect changes in the system network configuration.
The Fig. 2.2 shows the basic layout of the CNDP with CNET stack and components.