§ 9.1 – 9.19 DPDK: Kernel Bypass · EAL · PMD · RSS · Mbuf · NUMA · rte_ring · ACL/LPM · SR-IOV · Offload · SIMD · virtio · Pipeline · Hot Upgrade · Session · QoS · Bonding · OVS-DPDK

1. Overview

DPDK (Data Plane Development Kit) eliminates every per-packet overhead in the Linux kernel networking stack: interrupts, system calls, sk_buff allocation, copy_to_user(), and lock contention in netfilter and the routing table. Instead, a Poll Mode Driver (PMD) runs entirely in userspace, mapping NIC registers directly via UIO or VFIO, and spins in a tight loop checking descriptor DD (Descriptor Done) bits — no interrupts, no syscalls, no copies.

The result: from ~1 Mpps maximum in the kernel to 14.88 Mpps line rate at 64-byte frames on a single 10 GbE port with a single core.

2. § 9.1 — Why DPDK: Kernel Bypass Architecture

The Six Kernel Networking Bottlenecks

At 10 Gbps with 64-byte frames, the NIC delivers 14.88 million packets per second. Each packet gets only 67 nanoseconds of CPU time. The Linux kernel path burns most of that budget before the application even sees the data.

UIO vs VFIO vs AF_XDP — Bypass Mechanisms Compared

The NIC must be detached from its kernel driver and handed to userspace. Three mechanisms exist, each with different security and performance trade-offs.

How VFIO Works

VFIO groups devices by IOMMU group (devices that share an IOMMU context must be in the same group). The workflow: unbind the NIC from its kernel driver → echo vfio-pci > /sys/bus/pci/.../driver_override → DPDK EAL opens /dev/vfio/<group> → calls VFIO_MAP_DMA ioctl to register hugepage memory with the IOMMU → NIC can only DMA into registered regions. UIO skips the IOMMU entirely: faster to set up, but a buggy (or malicious) userspace process can DMA to any physical address.

3. § 9.2 — DPDK Startup Flow: EAL Initialization

rte_eal_init() — 10-Step Sequence

Every DPDK application calls rte_eal_init(argc, argv) as its first act. This one call bootstraps the entire DPDK runtime: CPU topology, memory, devices, and worker threads. If it returns a negative number, the application must exit — the environment is not usable.

Multi-Process Mode — Shared Hugepage Memory

DPDK supports running multiple cooperating processes on one host. The primary process allocates hugepages and initializes devices; one or more secondary processes attach by mmap()-ing the same hugepage files. Data structures stored in named rte_memzone regions (mempool, rings, flow tables) are accessible from both — at the same virtual addresses, because DPDK maps the files at a fixed base address. This is the foundation of DPDK hot upgrade.

Minimal C Demo — EAL Startup Simulation

Real rte_eal_init() requires DPDK libraries and hardware. This simulation traces the same 10 steps in plain C so you can follow the sequence mentally.

4. § 9.3 — Poll Mode Driver (PMD) — Deep Dive

PMD Initialization Sequence

After EAL init, the application configures each NIC port in three steps: set queue counts and offload flags, allocate descriptor rings, then start the device. Each step maps directly to a NIC register write via the mapped BAR.

RX Descriptor Ring — NIC Fills, PMD Drains

The RX ring is a circular array of fixed-size descriptors in DMA-accessible memory (inside huge pages). The PMD pre-fills every slot with the physical address (buf_iova) of an empty mbuf from the mempool. When a packet arrives, the NIC DMA-writes the packet bytes into the pointed-to buffer and sets DD=1. The PMD polls, harvests completed descriptors, and immediately refills each slot with a fresh mbuf before ringing the doorbell (writing the new tail index to the RDT BAR register).

TX Descriptor Ring — PMD Fills, NIC Drains

TX is symmetric. The PMD fills each descriptor with the outgoing mbuf's buf_iova, the packet length, and command flags (EOP = end of packet, RS = report status, IFCS = insert CRC). It then writes the new tail to the TDT BAR register (the TX doorbell). The NIC DMA-reads the packet bytes over PCIe and transmits. The PMD reclaims completed descriptors (DD=1) in batches of tx_free_thresh (default 32) to amortize the mempool free cost.

PMD RX Burst — Step-by-Step Code Path

Burst Design — Why 32 Packets?

rte_eth_rx_burst() processes up to 32 packets per call. This is not arbitrary:

• Amortizes the doorbell write — one PCIe transaction to update RDT costs ~100 ns; doing it once per 32 packets costs 3 ns per packet amortized.
• Fits in a cache line prefetch window — with a prefetch-ahead distance of 3–4, 32 descriptors keep the CPU pipeline full without exceeding L1 capacity.
• Aligns with SIMD width — 32 × 64-bit descriptors = 256 bytes, fitting in 4 AVX2 registers for batch DD-bit checking.

Minimal C Demo — PMD RX Descriptor Ring

Minimal C Demo — PMD TX Path

5. § 9.4 — NIC Multi-Queue, RSS & Flow Classification

Overview — One Queue per Core, No Locks

Modern NICs expose dozens or hundreds of RX/TX queues. Each queue is an independent descriptor ring, so the standard DPDK design is queue-to-lcore ownership: lcore 0 polls queue 0, lcore 1 polls queue 1, and so on. No two cores mutate the same RX ring, the application avoids locks on the hot path, and packet ordering is preserved inside a flow because RSS sends the same 5-tuple to the same queue.

Key Data Structures — RSS RETA and Flow Rules

Core Mechanism — RSS Queue Selection

Background: A 100 Gbps NIC cannot push all packets through one RX ring. It must spread flows across cores without reordering packets inside one TCP connection.

Plan: 1) hash the packet 5-tuple in hardware, 2) mask the hash into the RSS indirection table, 3) read the selected queue id, 4) DMA the packet into that queue's descriptor ring, 5) let the owning lcore poll it.

Example: A TCP flow 10.0.0.1:12345 → 10.0.0.2:443 hashes to 0x91ab0025. If the RETA has 128 entries, index 0x25 is read; if that entry contains queue 3, every packet in that flow is DMA-written into RX queue 3 and processed by lcore 3.

rte_flow — Precise Hardware Classification

RSS is probabilistic load distribution. rte_flow is explicit steering: match a packet pattern, then run an action such as queue, drop, mark, count, RSS, encap, or decap. Smart NIC projects use this to steer control-plane traffic, tenant ports, or tunnel flows before the packet ever touches CPU caches.

Minimal C Demo — RSS Queue Selection

6. § 9.5 — Memory Management: Huge Pages, Mempool & Mbuf

Overview — Pre-Allocate Everything the NIC Will Touch

DPDK avoids runtime allocation in the packet path. EAL maps pinned huge pages, builds NUMA-local memzones, then creates rte_mempool objects full of fixed-size rte_mbuf packet buffers. RX descriptors point directly at mbuf data rooms by IOVA, so the NIC can DMA packets into memory that userspace already owns.

Key Data Structures — Huge Page, Mempool, Mbuf

rte_mbuf Layout

An mbuf begins with hot metadata, then packet headroom, packet bytes, and tailroom. The packet pointer is not always buf_addr; DPDK computes it as buf_addr + data_off, which is what rte_pktmbuf_mtod() returns.

Core Mechanism — Mempool Fast Path

Background: At 20 Mpps, a normal malloc/free per packet would destroy throughput through locks, metadata writes, and cache misses.

Plan: 1) allocate all mbufs at startup from huge pages, 2) let each lcore allocate from its local cache, 3) refill or drain in bulk from the central ring, 4) return mbufs to the same NUMA socket whenever possible.

Example: lcore 2 starts with 4 cached mbufs. It receives a burst of 32 packets, consumes its 4 local objects, then bulk-pulls 32 more from the central ring. The shared ring CAS cost is paid once for the batch, not once per packet.

Multi-Segment Mbuf Chain

Jumbo frames, TSO, and scatter-gather I/O use chained mbufs. The first mbuf storespkt_len for the whole packet and nb_segs for the chain length; each segment stores its own data_len. The NIC can transmit the chain by DMA reading each segment address, avoiding a linear copy.

Minimal C Demo — Mempool + Mbuf Fast Path

7. § 9.6 — NUMA-Aware Programming in DPDK

Overview — Keep NIC, Queue, Mempool, and Lcore on One Socket

NUMA is not a small tuning detail in DPDK. A packet path touches the NIC DMA engine, the RX descriptor ring, the mbuf metadata, the packet bytes, and the polling lcore. If any of those live on the wrong socket, every packet pays an inter-socket hop. At high PPS that becomes a throughput cliff, commonly a 30–50% drop.

Wrong Placement — Remote Memory on Every Packet

The classic mistake is binding a NIC on socket 0, allocating its mempool on socket 0, but polling it from a lcore on socket 1. The NIC DMA is local, but the CPU reads packet bytes and updates mbuf metadata through the interconnect. The fix is mechanical: use rte_eth_dev_socket_id(port) for the NIC, allocate with that socket_id, and assign only lcores whose rte_socket_id() matches.

Key Data Structures — NUMA Placement Inputs

Core Mechanism — Locality Walkthrough

Background: A dual-socket host has port 0 attached to socket 0. You need to decide where to allocate the mempool and which lcore should poll RX queue 0.

Plan: 1) read the NIC socket, 2) allocate the mempool and descriptor rings on that socket, 3) pin the polling lcore to the same socket, 4) keep per-lcore tables and stats on the same socket, 5) use rings only when a packet must cross sockets.

Example: port 0 reports socket 0. Mempool mp0 is created with socket 0. lcore 2 also reports socket 0, so it polls queue 0. Packet bytes DMA into socket 0 memory, DDIO places them in the local LLC, and lcore 2 reads them without a remote hop.

Minimal C Demo — NUMA Placement Check

8. § 9.7 — Lock-Free Ring Buffer: rte_ring Deep Dive

Overview — Bounded FIFO Without Locks

rte_ring is DPDK's shared queue primitive. It is a power-of-two circular array of object pointers with separate producer and consumer cursors. Multi-producer mode uses CAS to reserve a range of slots, then publishes the range by advancing prod.tail. Single-producer and single-consumer modes remove the CAS and become plain loads/stores plus barriers.

Key Data Structures — Head/Tail Split

Core Mechanism — Multi-Producer Enqueue

Background: Two worker lcores need to enqueue packets to one TX lcore without a mutex. Both may enter the enqueue path at the same time.

Plan: 1) reserve slots by CAS-ing prod.head, 2) copy objects into the reserved slots, 3) issue a write barrier, 4) wait until any earlier producer has published, 5) advance prod.tail.

Example: producer A reserves slots 8–11 and producer B reserves slots 12–15. B may finish copying first, but it cannot publish tail 16 until A publishes tail 12. That spin-wait preserves FIFO order for the consumer.

Minimal C Demo — MPMC Enqueue

9. § 9.8 — Cache Optimization in DPDK

Overview — Performance Is Cache-Line Ownership

DPDK's hot path is designed around cache lines: align frequently written fields, avoid false sharing, prefetch packet metadata before use, and keep data owned by the lcore that mutates it. At 20 Mpps, a single remote cache-line transfer can cost more than the useful packet work.

Key Techniques — Alignment, Prefetch, MESI, DDIO

Core Mechanism — Prefetch Pipeline

Background: The PMD receives a burst of 32 mbufs. Each mbuf points to packet bytes that may be in LLC because of DDIO, but the metadata and payload still need to be pulled into L1 before parsing.

Plan: 1) process the current mbuf, 2) prefetch a future mbuf 3–4 packets ahead, 3) keep the CPU doing useful parsing while the cache hierarchy fetches the future packet, 4) tune the distance so it hides latency without evicting useful data.

Example: while parsing mbuf[0], the loop prefetches mbuf[3]. By the time the loop reachesmbuf[3], its first cache lines are already in L1.

Minimal C Demo — Prefetch-Ahead Loop

10. § 9.9 — ACL & LPM Classification Libraries

Overview — Classify Packets Before the Slow Path

Fast packet processing is mostly classification: decide which route, tenant, ACL rule, or session a packet belongs to without touching a long chain of branches. DPDK provides three core libraries for that job: rte_lpm for IPv4 longest-prefix route lookup, rte_acl for multi-field packet rules, and rte_hash for exact-match flow state.

Key Data Structures — LPM, ACL, Hash

Core Mechanism — DIR-24-8 Longest Prefix Match

Background: A router must map every destination IP to the most specific route. A trie works but costs several dependent memory loads per packet.

Plan: 1) use the top 24 bits as a direct array index, 2) return immediately for /0 through /24 routes, 3) follow one extra 256-entry table only for /25 through /32 routes, 4) store the selected next hop in the matching entry.

Example: route 203.0.113.0/24 has next hop 3. A more specific 203.0.113.200/32 has next hop 7. The first 24 bits index tbl24; theext_entry bit tells lookup to read the low 8 bits from tbl8 and return 7 for that one host.

Cuckoo Hashing — Exact Flow Lookup

rte_hash uses cuckoo hashing: every key has two candidate buckets, each bucket stores compact signatures for SIMD-friendly comparison, and insertions relocate existing keys only when both buckets are full. This keeps lookup predictable: compute two hashes, compare bucket signatures, then verify the full key on a signature hit.

Minimal C Demo — DIR-24-8 Lookup

11. § 9.10 — SR-IOV in DPDK

Overview — Split One NIC into Hardware Tenants

SR-IOV exposes one physical NIC as a Physical Function (PF) plus many Virtual Functions (VFs). The PF owns full device control: VF creation, MAC/VLAN filters, link settings, and policy. Each VF appears as its own PCIe function with private RX/TX queues and can be bound to vfio-pci for a DPDK app, container, or VM passthrough datapath.

Key Data Structures — PF, VF, Queue, IOMMU Domain

Core Mechanism — VF Passthrough Walkthrough

Background: A VM needs low-latency networking, but assigning the whole PF would give it control over every tenant on the NIC.

Plan: 1) enable VFs from the PF, 2) bind a VF to vfio-pci, 3) map guest or DPDK hugepage memory through the IOMMU, 4) configure VF MAC/VLAN rules from the PF, 5) let the VF poll its private queues directly.

Example: VF 3 is assigned to tenant A with MAC 52:54:00:aa:00:03 and VLAN 120. The PF programs filters so only those packets enter VF 3 queues; VF 3 DMA is restricted to tenant A memory by the IOMMU.

12. § 9.11 — Hardware Offload

Overview — Move Mechanical Packet Work into the NIC

Hardware offload removes repetitive per-packet work from the CPU: checksum generation, checksum verification, TCP segmentation, tunnel checksum handling, timestamping, and flow steering. In DPDK, the application still owns the packet; it marks the mbuf withol_flags and length fields so the PMD can describe the operation in the TX descriptor.

Key Data Structures — Offload Contract

Core Mechanism — TSO and Checksum Offload

Background: A TCP sender wants to transmit 64 KB of payload. If the CPU splits it into MTU-sized packets and computes every checksum, it burns cycles on work the NIC can do while transmitting.

Plan: 1) build one large mbuf chain, 2) set header lengths andtso_segsz, 3) set TX offload flags, 4) hand the descriptor to the NIC, 5) let hardware segment and compute per-frame checksums.

Example: an mbuf with 64 KB TCP payload, MSS 1460, IPv4 checksum offload and TCP TSO flags becomes roughly 45 Ethernet frames on the wire. The CPU rings one TX doorbell; the NIC emits correctly checksummed frames.

13. § 9.12 — SIMD in DPDK

Overview — One Instruction, Many Packets

DPDK uses SIMD where the packet path repeats the same operation across a burst: descriptor status checks, ACL state transitions, hash bucket signature comparison, checksum arithmetic, LPM batch lookup, and optimized memory copies. The scalar mental model is still a loop over packets, but the CPU executes several lanes in parallel with SSE4.2, AVX2, or AVX-512.

Key Data Structures — SIMD-Friendly Batches

Core Mechanism — Batch Classification

Background: A firewall receives 32 packets from rte_eth_rx_burst(). Checking every packet through scalar branches wastes instruction bandwidth and mispredicts on mixed traffic.

Plan: 1) gather the same field from multiple mbufs, 2) load them into vector lanes, 3) compare all lanes against the rule value, 4) convert the result to a bit mask, 5) process only the matching packets.

Example: eight destination IPs are compared against 10.0.1.0/24 in one AVX2-style operation. A result mask of 0x12 means lanes 1 and 4 matched.

Minimal C Demo — Offload Flags + SIMD-Style Mask

14. § 9.13 — Virtio, vhost-user & vDPA

Overview — Paravirtual Networking for VMs

Virtio gives a VM a simple paravirtual NIC: the guest driver writes packet buffers into virtqueues, and a host backend consumes those descriptors. With vhost-user, the backend is a DPDK userspace process such as OVS-DPDK, connected to QEMU over a Unix domain socket for control and shared hugepage memory for data. With vDPA, the NIC itself implements the virtio datapath.

Key Data Structures — Split Virtqueue

vhost-user — Control Socket, Shared-Memory Datapath

QEMU remains the frontend, but packet movement goes through a DPDK backend. The Unix socket carries setup messages such as memory tables, vring addresses, feature bits, and eventfd file descriptors. Packet bytes stay in shared hugepage memory, so the backend can walk guest virtqueue descriptors directly and forward bursts without a kernel tap device.

vDPA — Hardware Virtio Datapath

vDPA moves the virtio data path into the NIC. Software still handles control-plane details such as feature negotiation, queue setup, and migration state, but packet DMA goes directly between the NIC and the guest virtio rings. The VM keeps the standard virtio-net driver while reaching near passthrough performance.

Core Mechanism — vhost-user Packet Receive

Background: A VM sends or receives packets through virtio-net, but the host wants DPDK throughput instead of kernel tap networking.

Plan: 1) QEMU sends guest memory and vring addresses to the DPDK backend, 2) the guest publishes descriptors in the available ring, 3) the backend maps descriptor guest physical addresses to host virtual addresses, 4) the backend copies or attaches packet data into mbufs, 5) it updates the used ring and optionally signals the guest.

Example: the guest publishes desc 5 for a 2048-byte RX buffer. OVS-DPDK reads desc 5 through shared memory, writes a packet into that buffer, places desc 5 in the used ring with the received length, then kicks the guest through eventfd if notification suppression is disabled.

Minimal C Demo — Virtqueue Descriptor Handoff

15. § 9.14 — Pipeline & Run-to-Completion Models

Overview — Two Ways to Assign Work to Cores

A DPDK datapath either keeps the full packet lifecycle on one lcore (run-to-completion) or splits work into stages connected by rte_ring queues (pipeline). The right choice is a cache-locality decision: simple L2/L3 forwarding usually prefers R2C; expensive or uneven work such as crypto, DPI, or control-plane punts often needs a pipeline.

Pipeline Model — Specialized Stages

Pipeline mode dedicates lcores to stages: RX, worker, TX, or a richer chain such as parse → ACL → crypto → route → transmit. Each handoff is a pointer enqueue/dequeue through an rte_ring, which costs cache-line traffic but lets bottleneck stages scale independently.

Key Design Trade-Offs

Core Mechanism — Choosing R2C or Pipeline

Background: A gateway receives 32-packet bursts. Most packets only need session lookup and forwarding, but a small fraction need slow ACL and crypto work.

Plan: 1) use R2C for session hits so packet cache lines stay on the polling lcore, 2) enqueue session misses or crypto packets to a worker ring, 3) return processed packets to a TX ring, 4) measure the worker stage and add lcores only there.

Example: packets 0–29 hit the per-lcore session cache and transmit immediately on lcore 2. Packets 30–31 miss and are enqueued to a worker. The worker creates sessions, then sends those two packets to the TX lcore. The hot path avoids ring handoff for 30 out of 32 packets.

Minimal C Demo — R2C vs Pipeline Flow

16. § 9.15 — DPDK Hot Upgrade — Deep Dive

Overview — Upgrade Without Losing Datapath State

Hot upgrade is hard because a DPDK process owns hugepage memory, NIC queues, timers, session tables, and in-flight packet bursts. The practical design is to separate durable datapath state from process-local execution state: keep sessions and flow tables in named shared memzones, attach a new process to the same hugepages, validate compatibility, then swap traffic ownership with a short drain window.

Shared Memory Persistence

Hugepage files in hugetlbfs can outlive one binary execution when the application controls cleanup. A new binary using the same --file-prefix can locate named memzones, read a schema version and generation number, and import or migrate existing state. This preserves session continuity even when NIC queues must be reconfigured.

Key State Boundaries

Core Mechanism — Multi-Process Hot Upgrade

Background: A virtual switch holds millions of sessions and must upgrade the binary without rebuilding those sessions from scratch.

Plan: 1) old primary exports sessions into versioned memzones, 2) new secondary attaches to the same hugepages, 3) new process validates schema and warms flow caches, 4) old process stops accepting new sessions and drains rings, 5) traffic ownership switches, 6) old process exits after final counters are merged.

Example: version N stores each NAT session as key, translated tuple, timeout, and counters. Version N+1 reads generation 42, sees schema 1 is supported, rebuilds its per-lcore cache from the shared table, installs required hardwarerte_flow rules, and then becomes active.

Minimal C Demo — Shared State Handoff

17. § 9.16 — Session Management: Fast Path & Slow Path

Overview — First Packet Pays, Later Packets Hit Cache

Session management turns expensive per-packet decisions into a cached forwarding action. The first packet of a flow misses the table and goes through ACL, routing, NAT, and policy logic. The created session stores the 5-tuple, translated tuple, output port, timeout, and QoS class so later packets run through a per-lcore hash lookup and transmit immediately.

Slow Path — Build the Cached Decision

On a session miss, the packet leaves the hot path. The slow path may run on the same lcore for simple gateways or be enqueued to a control-plane worker through an rte_ring. The important rule is that session publication is controlled: per-lcore tables avoid locks, while global tables need RCU or writer-side locks so readers never see half-initialized state.

Key Data Structures — Session Table

Core Mechanism — Fast/Slow Path Walkthrough

Background: A NAT gateway receives a new TCP flow. Running ACL, route lookup, and NAT allocation for every packet would waste the line-rate budget.

Plan: 1) hash the packet 5-tuple, 2) on hit apply the cached action, 3) on miss send the first packet through ACL, LPM, and NAT allocation, 4) publish the session entry, 5) send later packets through the fast path.

Example: packet 1 for 10.0.0.1:12345 → 203.0.113.8:443 misses, gets NATed to 10.0.0.9:40000, and creates a session. Packet 2 hashes to the same entry and only applies the cached rewrite and output port.

Minimal C Demo — Session Miss Then Fast-Path Hit

18. § 9.17 — QoS in DPDK

Overview — Shape, Police, and Schedule Bursts

QoS in a DPDK datapath usually has two layers. rte_meter colors packets with token bucket policers such as srTCM or trTCM. rte_sched then schedules traffic hierarchically: port, subport, pipe, traffic class, and queue. This lets one process enforce tenant, VM, or service-class limits before packets reach the TX ring.

Token Bucket Policing

A token bucket adds tokens at a configured rate and caps them at the burst size. A packet consumes tokens equal to its length. srTCM and trTCM turn that check into colors: green packets conform, yellow packets exceed committed rate but may pass at lower priority, and red packets violate policy and are dropped or remarked.

Key Data Structures — Meter and Scheduler

Core Mechanism — Per-VM Rate Limit

Background: A host has many VMs behind OVS-DPDK. One VM must not consume the entire 25G port during a burst.

Plan: 1) classify packet to VM or tenant, 2) run its token bucket, 3) drop or mark red packets, 4) enqueue green/yellow packets into the scheduler pipe, 5) let rte_sched choose eligible packets for TX.

Example: VM A has a 1 Gbps committed rate and 64 KB burst. A 9 KB packet passes while tokens are available. Once the bucket drains, later packets turn yellow or red until tokens refill.

Minimal C Demo — Token Bucket Colors

19. § 9.18 — DPDK Bonding & Link Aggregation

Overview — One Logical Port Over Multiple NICs

rte_eth_bond exposes multiple physical ports as one logical ethdev. Applications call normal ethdev APIs on the bond port, while the bonding PMD chooses a slave port according to the configured mode. Active-backup is common for redundancy; 802.3ad/LACP is common when the upstream switch participates in link aggregation.

Key Modes

Core Mechanism — Active-Backup Failover

Background: A virtual switch needs to survive one NIC or cable failure without changing the application datapath.

Plan: 1) create a bond ethdev, 2) add two slave ports, 3) set a primary slave, 4) poll link state, 5) switch active slave on failure, 6) keep the application using the same logical port id.

Example: port 0 is active and port 1 is standby. If port 0 link drops, the bond PMD marks port 1 active. The app still transmits to bond port 7; only the bond PMD changes which physical TX queue receives descriptors.

20. § 9.19 — OVS-DPDK: Open vSwitch with DPDK Datapath

Overview — OpenFlow Control Plane, DPDK Packet Path

OVS-DPDK keeps the OVS control plane but replaces the kernel datapath with userspace PMD threads. ovs-vswitchd owns bridges and flow programming, while netdev-dpdk ports poll physical NICs and vhost-user sockets with DPDK. The fast path is a cascade of caches: EMC, datapath classifier, and finally the full OpenFlow pipeline.

Port Types — Physical, VM, Patch, Internal, Tunnel

OVS-DPDK bridges combine several port types: dpdk for physical NICs, dpdkvhostuser for VM virtio backends, patch ports between bridges, internal ports for host networking, and tunnel ports for VXLAN or Geneve encap/decap in userspace.

Key Data Structures — OVS Datapath Caches

Core Mechanism — OVS-DPDK Flow Lookup

Background: A VM packet enters a vhost-user port. OVS must decide whether to forward to another VM, a physical NIC, a tunnel, or the OpenFlow slow path.

Plan: 1) PMD receives a burst, 2) check EMC for exact-flow hit, 3) on miss check dpcls megaflows, 4) on miss run ofproto, 5) install or update a megaflow, 6) execute actions such as output, drop, recirculate, or VXLAN encap.

Example: the first packet from VM A to VM B misses EMC and dpcls, so ofproto runs the OpenFlow table and installs a megaflow. The next packet with matching masked fields hits dpcls; repeated packets from the same exact tuple hit EMC.

21. Kernel Source Pointers

22. Interview Prep