Unlocking High‑Performance Packet Processing: Inside DPDK’s libgraph Framework

Background

DPDK (Data Plane Development Kit) is a high‑performance packet‑processing framework that runs on major NICs, accelerators and CPU architectures (x86, Arm, Power) under Linux, FreeBSD and Windows, and is widely used in gateways, load balancers, SDN and virtual switches.

libgraph Design

The libgraph component of DPDK adopts the vector‑packet‑processing ideas from the open‑source VPP project. Unlike the scalar model where each function processes a single packet, libgraph processes a batch of packets (a vector) in a graph of nodes, reducing i‑cache misses and pointer‑copy overhead.

Scalar vs Vector Processing

In the scalar model, packets are passed between functions via simple pointer assignments, which can cause high i‑cache miss rates and inefficient memory copies when pipelines become complex. The vector model allows optimized memory copies or even pointer swaps, improving cache locality and decoupling business logic from memory allocation.

Advantages of the Graph Framework

Better i‑cache management and locality.

Flexible pipeline model abstracted from business logic.

Reduced pointer copying.

Nodes can accumulate packets from previous nodes, improving batch performance.

Table‑driven node scheduling that facilitates QoS.

Graph Workflow

A graph consists of nodes connected by edges. At runtime, a circular buffer (cir_start) with head and tail pointers tracks pending streams. The graph walk iterates from source nodes, locating the next node, preparing its objects, invoking its process function, and updating head/tail until no pending streams remain.

Node Object Queue Size

Each node has an object queue of size RTE_GRAPH_BURST_SIZE . If the downstream node’s queue is full, the upstream node’s queue size is dynamically doubled, enabling batch processing. The current API does not support shrinking the queue after it has grown.

Enqueue Mechanisms

Two enqueue types exist:

Normal enqueue : packets are copied or pointer‑assigned to the next node using rte_memcpy or similar.

Home run : when all processed packets go to a single downstream node whose queue is empty, the pointers of the two nodes are swapped, eliminating copy overhead.

<code>/* Home run scenario */
/* Swap the pointers if dst don't have valid objs */
if (likely(dst->idx == 0)) {
    void **dobjs = dst->objs;
    uint16_t dsz = dst->size;
    dst->objs = src->objs;
    dst->size = src->size;
    src->objs = dobjs;
    src->size = dsz;
    dst->idx = src->idx;
    __rte_node_enqueue_tail_update(graph, dst);
}
</code>

Core Components

The main components are the graph (global scheduler) and node (encapsulates business logic). A struct node contains fields such as name, flags, process, init, fini functions, identifiers, parent ID, edge count, and next‑node names.

<code>struct node {
    STAILQ_ENTRY(node) next;              /* Next node in the list. */
    char name[RTE_NODE_NAMESIZE];         /* Name of the node. */
    uint64_t flags;                       /* Node config flag - source node? */
    rte_node_process_t process;           /* Node process function. */
    rte_node_init_t init;                 /* Node init function. */
    rte_node_fini_t fini;                 /* Node fini function. */
    rte_node_t id;                        /* Allocated identifier for the node. */
    rte_node_t parent_id;                 /* Parent node identifier. */
    rte_edge_t nb_edges;                  /* Number of edges from this node. */
    char next_nodes[][RTE_NODE_NAMESIZE]; /* Names of next nodes. */
};
</code>

Nodes are registered via constructor attributes, and a source node must exist to start the pipeline; non‑source nodes are added to the pending stream dynamically.

Summary

DPDK’s libgraph provides a vector‑based graph pipeline that reduces i‑cache misses, abstracts business logic, and offers flexible scheduling, but it introduces potential memory‑safety risks, increased code complexity, and a steep learning curve for beginners. It is best suited for complex pipelines where performance gains outweigh these trade‑offs.