Preface: This week I had the pleasure of updating several data path related visuals at work. While this one may seem like a WTF overwhelming block of information, I assure you that everything I’ve included answers a question I’ve had about EDP in the last couple of years. -Gabe

Enhanced Data Path (EDP) Standard is the core engine driving packet processing efficiency and CPU optimization across the hypervisor. Whether you’re handling standard virtual machines, containerized workloads, or host-level infrastructure traffic, EDP Standard optimizes how frames move between virtual switches and physical silicon.

This diagram provides a complete structural blueprint of how traffic traverses an ESXi host running as an NSX Transport Node under EDP Standard. Here is a step-by-step walkthrough of the architecture, layer by layer.

1. The Ingress Layer: Workloads and Host Services

At the top of the visual, the architecture divides ingress/egress points into two distinct categories: Workloads on the left and vSphere Host Services on the right.

• Workloads Box: High-performance fast-path processing within EDP Standard is exclusive to the paravirtualized VMXNET3 adapter. The diagram highlights virtual machines (vm) and containerized pods (Eth0) leveraging VMXNET3 (vNIC0 and Eth0) to interface directly with the virtual switch. Workloads utilizing emulated or legacy adapters (such as E1000 or E1000E) cannot leverage EDP’s fast path and will automatically fall back to traditional slow-path processing via the IOChain.
  
• vSphere Host Services Box: On the right, host infrastructure traffic sits directly alongside virtual workloads. The set of VMkernel adapters (vmk0 through vmk4) represents a unified collection of VMkernel traffic—including management, vMotion, vSAN, replication, and TEP overlay encapsulation—that is fully handled by the EDP packet processing engine.

2. Virtual Switching Fabric: VDS Powered by NSX

Directly beneath the endpoints sits the vSphere Distributed Switch (VDS) Powered by NSX. This virtual switching domain abstracts and routes three primary network constructs:

• VPC VLAN Network: Handles traditional tagged VLAN traffic tied to Virtual Private Cloud constructs.
  
• VPC Overlay Network: Manages Geneve-encapsulated tenant traffic.
  
• Distributed Port Group: Handles standard vSphere management port groups and host networking.

All three constructs converge into this layer, passing frames directly down to the core EDP execution pipeline.

3. The Datapath Core: EDP Fast Path Engine & IOChain Fallback

In the center of the diagram lies the core processing engine. Notice how this block is split between the primary green EDP Fast Path Engine box and the grey IOChain Fallback box on the right.

EDP Fast Path Engine (Optimized Packet Processing)

This is the primary pipeline designed for efficient packet forwarding:

• VLAN & Overlay Traffic: Ingress packets enter the pipeline directly.
  
• EDP Mbuf Data Framework: EDP replaces traditional heavy packet structures with a compact 128-byte Mbuf data framework. This 50% reduction in memory footprint optimizes CPU L3 cache locality for faster processing.
  
• EDP Flow Cache: A high-speed lookup table storing active flow states. Once a flow is learned on its initial packet, subsequent packets matching the flow signature bypass traditional stack processing entirely.

IOChain Fallback (Slow Path / Exception Handling)

Follow the dashed arrow extending from the Fast Path Engine into the grey box. EDP Standard interacts with this layer as an exception mechanism. When an un-cached flow, first-packet setup, control-plane resolution, or diagnostic packet enters the engine, EDP routes it to the legacy IOChain stack to resolve the necessary forwarding rules before populating the Flow Cache for subsequent fast-path execution.

Thread Scheduling (EnsNetWorlds & TLB)

Directly beneath the processing engine sits the Thread Load Balancer (TLB) | Core Scheduling Threads (EnsNetWorlds) bar. EDP Standard assigns dedicated ESXi execution threads (EnsNetWorlds) to poll and process network queues. The Thread Load Balancer continuously monitors thread utilization and dynamically balances active network flows across available CPU cores to prevent thread contention and hotspots.

4. Memory and Queuing: EDP Queue Manager & NUMA Alignment

Moving down to the light green block, the EDP Queue Manager orchestrates how packet queues map to system hardware:

• NetQueue RSS NUMA 0 & NUMA 1 (Shared RSS Engine): EDP Standard is strictly NUMA-aware out of the box. Receive Side Scaling (RSS) queues are bound directly to local NUMA sockets. Packets arriving on physical NIC ports tied to NUMA socket 0 are processed by memory and threads residing strictly on NUMA socket 0, eliminating cross-socket interconnect latency.
  
• Default Queue RSS (Fallback Pool): Serves as a secondary queue pool handling background or unassigned traffic when dedicated hardware queues are saturated.

5. The Physical Boundary: pNIC Drivers & Hardware Offloads

At the very bottom of the visual, we reach the physical hardware and driver interface.

• EDP-Capable pNIC Driver Box (Bottom Left): The driver block represents leading pNIC vendor drivers (such as Broadcom bnxtnet, Intel icen/i40en, AMD Pensando ionic, NVIDIA/Mellanox nmlx5, Marvell qedentv, and Cisco nenic-ens) that natively support EDP Standard. These high-performance native drivers interface directly with the EDP engine to streamline ring-buffer operations.
  
• NetQueue Filter Steering & NIC Offloads (Bottom Right): The green arrows show the interaction between software and silicon. Hardware filters on the pNIC steer incoming packet streams directly into NUMA-aligned NetQueue rings. Meanwhile, EDP Standard automatically orchestrates hardware NIC offloads out-of-the-box (such as Geneve encapsulation offload, TCP Segmentation Offload, and Large Receive Offload). Offloading heavy packet manipulation directly to the physical ASIC conserves host CPU cycles for application workloads.

Summary Flow

By following the visual cues in the diagram from top to bottom, you can track the complete journey of a packet through EDP Standard:

1. Ingress: Originates from a VMXNET3 VM, Container, or VMkernel adapter (or falls back to the slow path if using legacy emulated adapters).
   
2. Switching: Traverses the vSphere Distributed Switch Powered by NSX across VLAN, Overlay, or DPG constructs.
   
3. Processing: Enters the EDP Fast Path Engine via the compact Mbuf framework and Flow Cache (or branches to IOChain Fallback for un-cached or exception traffic).
   
4. Scheduling: Handled by EnsNetWorlds threads and balanced dynamically by the TLB.
   
5. Queuing: Aligned to socket-local CPU memory via the EDP Queue Manager and NetQueue RSS.
   
6. Egress: Passed down through native EDP pNIC Drivers with hardware NIC Offloads enabled on the physical adapter.

🤷🏻‍♂️ Hope that made sense.

—
Gabe

P.S. I have a couple of other diagrams in the kitchen. Very much looking forward to sharing those.

On a personal note… Spencer (16), my oldest son has left home to study out of state! It blows me away how fast we went from diapers to early adulthood. We took the milestone as an excuse to get an updated family portrait.

Here’s a snapshot of what the family:

Other than that – I’m now fully unplugged from socials. It’s kind of quiet – but doing alright.