DPU SmartNIC Offload: BlueField vs Pensando vs Intel IPU for Cloud Infrastructure (2026)

A modern cloud server spends a startling share of its CPU on work that earns no revenue. Virtual switching, overlay encapsulation, IPsec, storage protocol handling, telemetry and security policy all run on the same cores that tenants rent. At 400 Gb/s a single host can see hundreds of millions of packets per second, and the arithmetic of doing that in software stops working. The DPU SmartNIC is the industry’s answer: move the infrastructure plane onto a separate, programmable chip on the network card, and hand the host cores back to the workload.

This matters now because the three silicon families that define the category have all reached a new generation. NVIDIA announced BlueField-4, AMD ships Pensando Salina at 400G, and Intel’s IPU line moved from the E2000 to the E2200 “Mount Morgan” shown at Hot Chips 2025. This post explains the architecture underneath, what really moves to the card, where it stops helping, and how to reason about the economics.

What this covers: the DPU architecture (Arm cores, hardware pipeline, eSwitch), the offload mechanics for OVS, crypto and NVMe-oF, a vendor comparison of BlueField, Pensando and Intel IPU, Kubernetes integration, an illustrative core-reclaim calculation, and the operational failure modes that vendor slides skip.

Context and Background

The term “SmartNIC” covers anything from a NIC with checksum offload to a card running a full Linux. The more precise vocabulary has settled into three tiers. A plain NIC offloads stateless work such as checksums, segmentation and receive-side scaling. A SmartNIC adds a programmable datapath, often an FPGA or a flow-matching ASIC, but leaves control to the host. A data processing unit (DPU), which Intel brands an infrastructure processing unit (IPU), adds general-purpose CPU cores running their own operating system, so the card is effectively a small server that sits in the I/O path of the big one.

The motivation is both economic and architectural. Hyperscalers discovered that the “infrastructure tax” of virtualization consumed a meaningful slice of each host. AWS Nitro was the template: dedicated hardware for networking, storage and the hypervisor control plane, so that the host runs only customer code. Google’s co-designed IPU with Intel, exposed in the C3 instance family announced in October 2022, followed the same logic. Google described C3 as offering up to 200 Gb/s of throughput on an E2000 IPU, with Hyperdisk block storage behind it (Techzine report).

The second driver is security. When the control plane that enforces tenant policy runs on the same CPU as the tenant, a hypervisor escape or a kernel exploit also compromises the policy. A DPU creates a separate trust domain: it has its own boot chain, its own root of trust and an out-of-band management port. Even if the host is fully compromised, the firewall rules living on the card still apply. This “zero-trust host” argument is increasingly the reason enterprises adopt DPUs, even when they have no CPU shortage.

The third driver is AI. GPU clusters need east-west bandwidth at 400 and 800 Gb/s, and the same fabric carries storage and tenant traffic. Offloading storage protocols and isolation to a DPU keeps host CPUs free to feed GPUs. For cluster-level network design, our RDMA, RoCE and InfiniBand deep dive covers the fabric side; this post covers the endpoint.

Before DPUs, the software answer was kernel bypass and eBPF. DPDK polls NIC queues from user space; XDP runs eBPF programs at the driver. Both still burn host cores. If you are evaluating where eBPF fits, our Cilium sidecarless service mesh deep dive shows what a pure software datapath can do, and why the DPU is the next step when that path saturates cores.

The Reference Architecture of a DPU

A DPU is best understood as three cooperating subsystems on one card: a fixed-function, hardware-accelerated packet pipeline; a cluster of Arm cores that run control software; and a set of specialized engines for crypto, compression and storage. Everything is connected to the host over PCIe and to the world over one or more Ethernet or InfiniBand ports.

In short: a DPU is a network adapter with its own CPU. The hardware pipeline (the eSwitch) forwards established flows at line rate with no software involvement, the on-card Arm cores handle the first packet of each flow and all control-plane work, and dedicated engines perform encryption and storage processing. The host sees ordinary PCIe devices, while the infrastructure software runs elsewhere.

Figure 1: DPU SmartNIC reference architecture. Established flows stay in the eSwitch hardware; only flow misses reach the Arm cores.

Figure 1 shows the essential split. Packets from tenant VMs arrive through PCIe virtual functions into the embedded switch. Known flows are forwarded in hardware. Misses go up to the Arm cores, where a software switch decides policy and installs a rule back into the hardware table. The Arm cores also run management services, and a separate path connects the crypto and storage engines.

Hardware pipeline and eSwitch

The eSwitch is a hardware match-action engine. It parses headers, looks up a flow table keyed on fields such as the five-tuple, tunnel ID and VLAN, and applies actions: forward, drop, encapsulate, decapsulate, rewrite headers, count, meter, and mirror. Flow tables are stored in on-chip and card memory, and lookups happen at line rate regardless of CPU load.

The crucial property is that the table is populated by software. Linux exposes this through TC flower and the switchdev model: each virtual function on the host is mirrored by a “representor” netdev on the DPU side, and rules attached to representors are pushed to hardware. The kernel networking stack becomes the control plane for a hardware dataplane. Applications and orchestrators continue to speak standard interfaces, and the vendor driver translates them into hardware rules.

Capacity matters. A table has a finite number of entries and an insertion rate. NVIDIA, for example, quotes connection tracking that scales to many millions of flows on its newest parts, and Intel stated that the E2200 inline crypto block supports 64 million flows (Chips and Cheese on Hot Chips 2025). Insertion rate, measured in rules per second, often limits workloads with many short-lived connections more than the table size does. We return to this in the gotchas.

Arm cores and the on-card operating system

The general-purpose complex is where the DPU differs from a classic SmartNIC. BlueField-3 carries up to 16 Armv8.2+ A78 “Hercules” cores with 8 MB of L2 and 16 MB of last-level cache, and DDR5 on dual controllers at 5600 MT/s (BlueField-3 datasheet). Intel’s E2000 shipped with up to 16 Arm Neoverse N1 cores. The E2200 raises this to 24 Neoverse N2 cores according to the Hot Chips coverage, though Intel did not disclose the exact configuration. AMD’s Salina brief does not state a core count, so this post does not either.

These cores run a full Linux distribution, typically Ubuntu or a vendor build, with containers, systemd and standard networking tools. That is powerful and risky in equal measure. You get Open vSwitch, an IPsec daemon like strongSwan, an NVMe target, a metrics agent and a firewall all running on the card. You also inherit patching, key management, logging and capacity planning for a second operating system on every server.

Crypto, storage and compression engines

Fixed-function engines carry the bulk-data work. The BlueField-3 datasheet lists MACsec, IPsec and TLS data-in-motion encryption, AES-GCM 128/256 and AES-XTS 256/512 for data at rest, a public key accelerator for RSA, Diffie-Hellman, DSA and ECC, a true random number generator, and secure boot with a root of trust. On the storage side it lists NVMe-oF and NVMe/TCP acceleration, BlueField SNAP (an NVMe and virtio-blk emulation layer), a decompression engine and erasure coding for RAID.

AMD’s Salina brief lists a similar set: bulk and inline IPsec and DTLS, public key encryption, compression, NVMe virtualization, NVMe-oF over RoCEv2 or TCP, deduplication hashing and checksums. The common pattern is that the expensive per-byte operations run in silicon at line rate, while the per-flow decisions (key negotiation, policy lookup) stay in software on the Arm cores.

The datapath accelerator

BlueField-3 also exposes a programmable datapath accelerator (DPA) of 16 cores and 256 threads, programmed through DOCA, for custom packet and RDMA processing that the fixed pipeline cannot express. It targets workloads such as in-network telemetry, custom transport offloads and collective-communication assist. For most cloud operators the DPA is a niche tool; the fixed pipeline plus Arm cores handle the mainstream use cases.

The Three Product Families in 2026

The market is effectively a three-way race, with FPGA-based alternatives and Marvell’s OCTEON line occupying specialist niches. Before comparing, one caveat: vendor specifications below come from vendor datasheets and press coverage, and the figures are peak capabilities, not measured throughput under your workload.

NVIDIA BlueField-3 and BlueField-4

BlueField-3 is the shipping workhorse. The datasheet describes up to 400 Gb/s with 1, 2 or 4 Ethernet ports, or one NDR 400 Gb/s InfiniBand port, 32 lanes of PCIe Gen 5, 16 Arm A78 cores, and form factors in half-height and full-height half-length. Management is through a 1GbE out-of-band port plus NC-SI and MCTP.

BlueField-4 was announced as part of the Vera Rubin platform. A third-party summary of the announcement states 800 Gb/s networking via a ConnectX-9 SuperNIC, a 64-core Grace CPU (Arm Neoverse V2), 128 GB of LPDDR5, PCIe Gen 6 x16, and early deployment in 2026, with NVIDIA claiming roughly 6x the compute of BlueField-3 (NADDOD summary). We treat these as announced figures from a secondary source; confirm against NVIDIA’s own datasheet before capacity planning.

The software story is DOCA, NVIDIA’s SDK. It provides libraries for flow programming, crypto, compression, RDMA, DPA programming and a catalog of ready services, including a host-based networking (HBN) service that runs BGP and EVPN on the DPU, and a Kubernetes-oriented DOCA Platform Framework. DOCA is the lock-in: code written to its flow APIs does not port to other vendors.

AMD Pensando (Salina)

AMD acquired Pensando in 2022. The Salina generation, per AMD’s product brief, provides 400G data-plane throughput over two QSFP112 ports, 64 GB of DDR5 at 6400 MT/s with ECC, PCIe Gen 5 x16 in a full-height half-length card, and optional multi-host support up to two hosts (Salina product brief).

Pensando’s differentiator is its programmable P4 pipeline. Instead of a fixed set of header fields and actions, the data-plane is a P4-programmable match-action engine, so services such as stateful firewall, NAT/PAT, load balancing with TCP/TLS termination, overlays (VXLAN, NVGRE, Geneve, GRE, IP-in-IP), segment routing and flow telemetry (ERSPAN, NetFlow/IPFIX) are expressed as pipeline programs. The brief says the platform supports P4 along with C and C++. Pensando’s early traction came from VMware vSphere (Project Monterey, the “DPU-backed” vSphere 8 architecture) and from Aruba switches that embed Pensando silicon for stateful services.

Intel IPU (E2000 and E2200)

Intel’s IPU line began with Mount Evans, the E2000, co-designed with Google. It has up to 16 Neoverse N1 cores, 200 Gb/s Ethernet, and 16 lanes of PCIe Gen 4. Intel pairs that with a P4-programmable packet processing pipeline. The E2200 “Mount Morgan” shown at Hot Chips 2025 moves to 24 Neoverse N2 cores, quad-channel LPDDR5-6400, 32 PCIe Gen 5 lanes, 400 Gb/s Ethernet and multi-host operation for up to four hosts, per the Chips and Cheese write-up. The memory capacity and bandwidth numbers in that article are the author’s estimates, not Intel disclosures.

Intel also pursues an open software path: the Infrastructure Programmer Development Kit (IPDK), built around P4 and the OPI (Open Programmable Infrastructure) community under the Linux Foundation, aiming for a vendor-neutral API across DPUs. Adoption remains thinner than DOCA, and we flag IPDK and OPI maturity as something to verify with a proof of concept rather than assume.

Side by side

Attribute	NVIDIA BlueField-3	NVIDIA BlueField-4 (announced)	AMD Pensando Salina	Intel IPU E2000	Intel IPU E2200
Line rate	up to 400 Gb/s	800 Gb/s (reported)	400 Gb/s	200 Gb/s	400 Gb/s
Cores	up to 16 Arm A78	64 Grace (Neoverse V2)	not stated in brief	up to 16 Neoverse N1	24 Neoverse N2 (reported)
Host interface	PCIe Gen 5	PCIe Gen 6 x16	PCIe Gen 5 x16	PCIe Gen 4	PCIe Gen 5, 32 lanes
Dataplane model	fixed pipeline + DPA	fixed pipeline + DPA	P4 programmable	P4 programmable	P4 programmable
SDK	DOCA	DOCA	Pensando SDK, P4	IPDK, P4	IPDK, P4
Notable users	many clouds, enterprise	early 2026 deployment	VMware, HPE Aruba	Google Cloud C3	roadmap

The table shows a sharp divide in philosophy. NVIDIA optimizes for raw throughput with a fixed pipeline and a rich SDK, while AMD and Intel favor P4 programmability. Fixed pipelines hit line rate on the features they support and fall back to Arm cores on anything else. Programmable pipelines trade some peak efficiency for the ability to define new services after deployment.

What Actually Moves to the DPU

Not every task benefits equally. The useful way to decide is by flow structure: offloading wins when a packet’s work is predictable, repeated and independent of payload semantics.

OVS offload

Open vSwitch is the most common virtual switch in OpenStack, many Kubernetes CNIs and enterprise clouds. In software, OVS has a fast-path flow cache in the kernel module or in user space with DPDK, and a slow path (ovs-vswitchd) that handles misses. Every packet crosses host cores in either case.

With OVS offload the OVS instance runs on the DPU Arm cores. The first packet of a flow misses in hardware and is forwarded to OVS, which classifies it, applies OpenFlow rules and installs an exact-match hardware rule through TC flower or the vendor’s flow library. Every subsequent packet of the flow is forwarded by the eSwitch, never touching an Arm core or the host. NVIDIA’s accelerated variant, OVS-DOCA, uses the DOCA flow API directly rather than TC and reports higher rule insertion rates and larger tables than OVS-kernel offload; treat vendor-quoted rates as an upper bound and benchmark yourself.

Figure 2: OVS offload sequence. The first packet takes the slow path through OVS on the DPU’s Arm cores; all subsequent packets and replies are forwarded by the eSwitch with no host CPU involvement.

Figure 2 makes the cost structure visible. The slow path is paid once per flow, so offload shines on long-lived, high-throughput flows such as storage, bulk transfer and east-west traffic between services. It is weakest on connection-per-request workloads with very short flows, where every request pays the upcall and rule-installation latency and the Arm cores become the bottleneck.

Overlay networking is a prime case. VXLAN or Geneve encapsulation and decapsulation, ECMP hashing and tenant isolation (VNI to VF mapping) are all pure header manipulations. Offloading them removes per-packet CPU cost entirely and keeps tenant traffic invisible to the host kernel.

Crypto: IPsec, TLS and MACsec

Encryption is the most clear-cut offload. A modern x86 core with AES-NI can sustain on the order of single-digit gigabytes per second of AES-GCM in optimized libraries, but real IPsec adds packet processing, replay checks and per-packet overhead. As an illustrative figure, assume one core sustains about 5 Gb/s of full ESP processing in practice. Encrypting a 400 Gb/s link would then consume roughly 80 cores. Whatever the exact per-core number in your environment, the shape is the same: line-rate encryption in software does not fit on a host. Inline crypto in the NIC pipeline does it at wire speed with no host cycles.

The key detail is the split between control and data. IKE negotiation, certificate handling and rekeying run in software on the Arm cores (or the host), while the per-packet ESP encryption happens in hardware once the security association is installed. TLS offload is subtler. Kernel TLS (kTLS) hardware offload lets the NIC encrypt records for established connections, but the handshake and certificate logic still run on the CPU. Full proxy-style TLS termination on a DPU, as Pensando’s brief lists, moves even that to the card at the cost of running a user-space proxy on the Arm cores.

Storage: NVMe-oF and NVMe emulation

Two distinct storage uses exist. The first is the initiator side: NVMe-oF over RDMA or TCP, handled in the DPU so that the host sees a local NVMe disk, while the DPU talks to remote storage. This is what makes “diskless” servers possible: the host sees a standard NVMe PCIe device emulated by the card (for example BlueField SNAP) and has no idea its blocks live across the network. Cloud providers use this to attach remote volumes without changing the guest driver.

The second is the target side: a DPU in a storage server runs the NVMe-oF target, terminating RDMA queues, applying erasure coding and compression and moving data between NIC and SSDs peer-to-peer over PCIe without touching host memory. The BlueField-3 datasheet lists erasure coding for RAID, a decompression engine and M.2/U.2 connectors for direct-attached storage.

Security and isolation

A stateful firewall on the DPU applies policy per VF, with connection tracking in hardware. Because the Arm complex runs its own OS, the policy engine is outside the tenant’s reach, and a bare-metal tenant can be given full root on the host without touching the cloud’s network policy. This is the mechanism behind bare-metal cloud offerings with tenant isolation, where the DPU enforces the virtual network even though the host is entirely tenant-controlled.

Trade-offs exist. Hardware connection tracking tables are finite, and exceeding them either drops new connections or falls back to the slow path. Deep packet inspection and application-layer firewalling (anything beyond L4) generally runs on Arm cores, not in hardware, and throughput there is a fraction of line rate.

Telemetry and load balancing

Flow telemetry (sFlow, IPFIX, ERSPAN) is cheap on a DPU because the pipeline already touches every packet. Load balancing is similar: consistent hashing and DSR-style L4 balancers can run in the pipeline. For the algorithmic background on why L4 balancers hash the way they do, see our load balancing algorithms guide, which covers Maglev-style consistent hashing that translates well to hardware tables.

eBPF/XDP vs Hardware Offload

Teams often ask whether eBPF makes a DPU redundant. The honest answer is that they sit at different points on a curve, and the choice depends on the cycle budget per packet.

Take the arithmetic. At 400 Gb/s with 1500-byte frames (1538 bytes on the wire including preamble, FCS and inter-frame gap) the packet rate is 400e9 / (1538 x 8), about 32.5 million packets per second. With 64-byte frames (84 bytes on the wire) it is about 595 million packets per second. A 3 GHz core processing 100 Gb/s of 1500-byte traffic gets only about 8.1 million packets per second, which is roughly 370 cycles per packet; at 64-byte frames, a single 100 Gb/s port needs 149 Mpps and the budget collapses to about 20 cycles per packet, which no software path achieves on one core.

XDP is excellent at what it does: dropping, redirecting and simple load balancing at driver level with tens of cycles of overhead per packet when programs are short, and it scales across cores with RSS. DPDK similarly achieves very high per-core rates at the cost of dedicated polling cores. Both consume host CPU in proportion to packet rate. Hardware offload decouples CPU use from packet rate for flows it can match.

XDP also has a hardware offload mode on some NICs (Netronome pioneered it), where the eBPF program is compiled to run on the NIC. In practice, the mainstream DPU path is not “offload your eBPF program” but “offload the flow rule”, via TC flower, OVS or vendor SDKs. The two approaches are complementary: eBPF handles host-local policy and observability, while the DPU handles the bulk flow forwarding. Cilium, for example, supports XDP acceleration and has been adding hardware-offload integrations, which is a topic worth tracking if you run it at scale.

A pragmatic rule: if software cores are idle most of the time and your traffic is below roughly 25 to 50 Gb/s per host, eBPF and DPDK are cheaper and simpler. Above that, or when isolation matters, hardware offload starts to pay.

Kubernetes Integration and Tenant Isolation

Running containers on a DPU-equipped host introduces a question that virtual machines did not: who owns the network namespace? Three models exist, and they imply different operational burdens.

Figure 3: Kubernetes integration. The pod’s network device is a virtual function or scalable function; its representor attaches to the OVS bridge on the DPU, while an operator provisions and updates the DPU’s own operating system and services.

Figure 3 shows the common pattern. The host-side CNI plugin (often SR-IOV based, used with Multus for secondary networks) hands a virtual function or a lighter-weight scalable function to the pod. On the DPU, a representor for that function attaches to an OVS bridge. A separate operator, such as NVIDIA’s DOCA Platform Framework or a vendor-specific DPU operator, manages the card’s operating system image, firmware and services through the Kubernetes API, so the DPU appears as a managed node-like resource. For a comparison of CNI models and where SR-IOV and Multus fit, see our CNI comparison of Calico, Cilium, Flannel and Multus.

Three deployment models

Host-trusted offload. The host still runs the CNI and the network policy engine; the DPU merely accelerates the datapath. This is the simplest model and the weakest on isolation, since a compromised host can reprogram the rules.

DPU-as-enforcer. The control plane for network policy runs on the DPU. The host kernel and tenant code can only use the virtual functions they are given. This is the model behind bare-metal clouds and is the strongest isolation option. The cost is that any CNI feature must exist in the DPU’s software stack.

DPU-as-Kubernetes-node. The DPU’s Arm cores join the cluster as a separate (arm64) node, running infrastructure daemonsets such as the CNI agent, a service proxy and observability agents. This enables a clean separation but doubles the number of nodes to patch and monitor. It also means multi-architecture container images become mandatory.

Tenant isolation properties

Isolation is only as good as the weakest shared resource. Hardware flow tables, rule-insertion queues, Arm memory bandwidth and PCIe bandwidth are all shared between tenants on one DPU. A noisy tenant that floods new connections can starve the slow path for others, because all misses funnel through the same Arm cores. Good designs use per-VF rate limits, meters on the eSwitch, and per-tenant flow-count quotas. They also treat the out-of-band management network as a privileged plane, because the DPU’s BMC-like interface can reflash firmware.

Service meshes and sidecarless designs

Service-mesh data-plane work (mTLS, L7 routing) is mostly application-layer and resists full hardware offload. What can be offloaded is the L4 transport: encryption of pod-to-pod links with IPsec or kTLS, connection tracking and policy at L3/L4. Sidecarless meshes combine well with this because the node-level proxy can rely on the DPU for encryption instead of burning host cores. Expect the DPU to take the bytes and the CPU to keep the semantics.

Illustrative Economics: What a Reclaimed Core Is Worth

The business case for DPUs rests on a simple idea: if infrastructure work consumes N cores per server, the DPU gives them back as sellable capacity. The numbers below are illustrative assumptions, not measurements, and are meant as a template for your own spreadsheet.

Assume a fleet of 1,000 servers, each with 64 usable cores. Suppose the vSwitch, IPsec, storage protocol handling and telemetry together consume 10 cores per host at the traffic levels you run. That is 10,000 cores across the fleet. At 64 cores per server, 10,000 cores equal about 156 servers’ worth of capacity.

Now price it. Suppose a DPU adds an assumed 2,000 USD per server in hardware, so 1,000 DPUs cost 2.0 million USD. If an equivalent server costs an assumed 15,000 USD all-in (hardware only), the 156 servers you avoid buying are worth about 2.34 million USD. Add power, rack space and licensing savings for those servers and the DPU looks better. Subtract the extra DPU power (assume 50 W per card, so 50 kW across the fleet), the engineering time to run a second OS per host, and the platform software licenses, and the margin narrows.

Item (illustrative)	Value
Servers	1,000
Cores per server	64
Infrastructure cores consumed per host	10
Cores reclaimed fleet-wide	10,000
Equivalent servers avoided	~156
DPU cost per server (assumed)	2,000 USD
Fleet DPU spend	2.0 M USD
Avoided server spend (assumed 15,000 USD each)	~2.34 M USD
Added DPU power (assumed 50 W each)	50 kW

Three observations make this more than arithmetic. First, the break-even moves with traffic: if you run at 25 Gb/s per host and infrastructure uses two cores, the DPU rarely pays on cores alone. Second, the case strengthens when the cores you reclaim are the expensive ones, for instance hosts with large GPU or licensed-per-core software where each core carries a high software cost. Third, the calculation ignores the isolation benefit, which for bare-metal and regulated multi-tenant clouds may be the real reason to buy.

The sensitivity is mostly in the infrastructure core count. Measure it before you model it: sample per-core CPU of ovs-vswitchd, ksoftirqd, ipsec workers and storage daemons under a production-like load, and convert to core-seconds per gigabit. That single metric makes a procurement case defensible.

Latency and jitter benefits

Cores are not the only currency. Moving the vSwitch off the host removes noisy-neighbor jitter from the network path, since softirq processing no longer competes with tenant workloads. For latency-sensitive traffic this can tighten tail latency even if it does not change the median. The effect is real but workload-specific, so treat it as something to measure rather than quote.

Deployment Walk-through: Enabling OVS Offload

The commands below sketch the host-side steps for hardware-offloaded OVS on a Linux system with an offload-capable NIC in switchdev mode. Device names and PCI addresses are placeholders, and exact steps vary by vendor and driver version, so follow your vendor’s current documentation.

# 1. Create virtual functions on the physical function (host or DPU Arm side)
echo 4 > /sys/class/net/ens1f0/device/sriov_numvfs

# 2. Put the eSwitch into switchdev mode (placeholder PCI address)
devlink dev eswitch set pci/0000:03:00.0 mode switchdev

# 3. Enable TC hardware offload on the uplink and representors
ethtool -K ens1f0 hw-tc-offload on

# 4. Tell Open vSwitch to push datapath flows to hardware
ovs-vsctl set Open_vSwitch . other_config:hw-offload=true
systemctl restart openvswitch-switch

# 5. Verify what actually got offloaded
ovs-appctl dpctl/dump-flows type=offloaded
tc -s filter show dev ens1f0_0 ingress

Step 5 is the one people skip. The OVS flag silently falls back to software for flows whose match or action the hardware cannot express, and the only evidence is the split between type=offloaded and type=ovs flows. Make “percentage of bytes in offloaded flows” a standing metric. If it is low, you are paying for hardware you are not using.

On a DPU, the same procedure runs on the Arm side: OVS lives on the DPU, host VFs map to representors, and the host sees only plain PCI functions. NVIDIA’s OVS-DOCA mode replaces the TC path with DOCA flow calls; AMD and Intel ship their own bridge or P4-program workflows. The conceptual model in Figure 2 is the same across vendors.

Validating the result

Establish a baseline before enabling anything. Capture host CPU by core, packets per second, and latency percentiles under a replayed production-like load, then repeat with offload enabled. Test the unhappy cases explicitly: a connection-per-request workload with short flows, a flow table at 80 percent occupancy, a rule-update storm during a rolling deploy, and a tenant that opens a million connections. The average case will look excellent. The tail cases decide whether the platform is trustworthy.

Choosing a Platform

Figure 4 condenses the decision logic. It is deliberately conservative, because the right default for most workloads is not a DPU.

Figure 4: Offload decision flow. Short-lived, stateless traffic stays on the host with XDP or DPDK; long-lived stateful flows with isolation or core pressure justify a DPU.

Decision matrix

Requirement	BlueField (NVIDIA)	Pensando (AMD)	IPU (Intel)
AI cluster with RoCE or InfiniBand	Strongest fit, same vendor as GPUs and fabric	Ethernet and RoCE storage fit	Ethernet fit
Custom stateful network services	DPA and DOCA services	P4 pipeline is the core strength	P4 pipeline and IPDK
VMware vSphere integration	Supported	Early and deep partnership	Check current support
Hyperscaler-style co-design	Many clouds	Cloud and OEM	Google C3 precedent
Software ecosystem breadth	Largest (DOCA)	Moderate	Smaller, open-standards focus
Vendor lock-in risk	High with DOCA APIs	Moderate with P4	Moderate with P4 and IPDK

The AI cluster row deserves emphasis. If your fleet is GPU servers built around NVIDIA networking, BlueField is the path of least resistance, because it shares tooling with ConnectX and Spectrum, supports InfiniBand natively and is positioned in NVIDIA’s reference platforms. If you run Ethernet-centric clouds, an AMD or Intel option introduces competition in procurement and a P4-based programming model.

Beware of comparing peak numbers. A 400 Gb/s part is not 400 Gb/s of everything: crypto, connection tracking, small-packet rate and rule-insertion rate each have separate ceilings. Ask each vendor for the number that matches your traffic, with your tunnel type and policy depth, and test with your packet size mix.

P4 programmability versus a fixed pipeline

P4 lets you define header parsing and match-action tables, so a new encapsulation or telemetry format can be deployed as a program update rather than waiting for silicon. That matters for operators who evolve their overlays. The cost is that P4 skills are scarce, toolchains differ per target, and portability between vendors is partial because target-specific extensions and architecture models differ. A fixed pipeline with a broad SDK is easier to staff, and a programmable pipeline is easier to extend. Match the choice to whether your team will realistically write data-plane programs.

Trade-offs, Gotchas, and What Goes Wrong

DPU projects fail more often from operations than from performance. The following problems recur.

A second computer in every server. The Arm complex needs OS patching, CVE response, credential rotation, logging and capacity monitoring. Fleet tooling built for x86 hosts rarely covers it on day one. The card’s firmware, bootloader, OS image and host driver form a four-way compatibility matrix, and a mismatch can take a node off the network.

Boot-order and lifecycle coupling. The host’s network depends on the DPU being up. If the DPU reboots for an update, the host loses connectivity, including any storage presented by an emulated NVMe device. Rolling updates must drain hosts, and an emulated boot disk makes the DPU a hard dependency of host boot. Out-of-band access to the DPU is essential when the host network is down.

Flow-table exhaustion and slow-path collapse. When tables fill, new flows fall back to software or drop. Rule-insertion rate caps short-lived connection workloads. A DDoS of new connections can melt the Arm cores even though the hardware could forward established traffic indefinitely. Size for flows, rules per second and tails, not for bandwidth.

Silent fallback. Unsupported matches or actions leave flows in software without errors. Monitor offloaded versus non-offloaded byte share continuously, as described above.

Observability gaps. When the vSwitch is in hardware, familiar host tools (tcpdump on a bridge, conntrack, iptables counters) no longer see the traffic. You need DPU-side counters, mirroring to a collector, and a mental model of which layer owns each packet. Debugging is harder because the evidence lives in two operating systems.

Vendor lock-in. DOCA flow code, SNAP configurations and Pensando P4 programs are not portable. OPI and IPDK aim to standardize APIs, but their maturity should be validated, not assumed. Keep business logic in portable layers (standard OVS, standard NVMe, standard IPsec) and confine vendor-specific code to thin adapters.

Power, thermal and form factor. DPUs are high-wattage PCIe cards with their own cooling needs. Airflow in dense servers matters, and some form factors (full-height cards) do not fit all chassis. Check the datasheet power figure for your SKU; the sources used for this post did not state it for all parts.

Cost when utilization is low. If your hosts run at modest network rates, the DPU’s cost and operational overhead outweigh the reclaimed cores. Do not buy DPUs because competitors have them.

Practical Recommendations

Start with measurement, not hardware. Profile host CPU consumed by networking and storage infrastructure at your real peak, and express it in core-seconds per gigabit. If it is under a few percent of your cores and your isolation needs are modest, stay with XDP, DPDK or plain SR-IOV, and revisit later.

If the case is real, pick the workload that offloads most cleanly first. Encryption and overlay forwarding of long-lived flows are the best pilots. Run a four-to-six week proof of concept on one rack with your own traffic mix and track three outcomes: host cores freed, offloaded byte share, and tail latency under rule churn.

Choose a vendor by ecosystem fit before specification sheets. GPU-centric fleets lean toward BlueField; Ethernet clouds with P4 skills can evaluate AMD and Intel; VMware shops should check each vendor’s current vSphere support directly.

Design operations in parallel with the hardware. Treat the DPU as a first-class managed node with its own CI, image pipeline, canary rollout and rollback.

Measure infrastructure core consumption per gigabit before buying.
Confirm offload coverage for your exact tunnel, policy and crypto configuration.
Test rule-insertion rate and flow-table occupancy at 80 percent.
Track offloaded versus software byte share as a production metric.
Build firmware, OS and driver compatibility tests into your pipeline.
Keep out-of-band management to every DPU on an isolated network.
Limit vendor-specific code to thin adapters over standard interfaces.
Rehearse a rolling DPU update on a non-production rack.

Frequently Asked Questions

What is the difference between a SmartNIC and a DPU?

A SmartNIC adds programmable packet processing, often through an FPGA or ASIC pipeline, but is generally controlled from the host. A DPU adds a cluster of general-purpose CPU cores running their own operating system, so the card hosts its own control plane, services and management. In practice vendors use the terms loosely, and Intel calls its equivalent an infrastructure processing unit. The practical test is whether the card runs independent software that survives host compromise.

Does a DPU replace the host CPU or a hypervisor?

No. The host CPU still runs tenant workloads, and a hypervisor or container runtime still schedules them. The DPU takes over infrastructure functions such as virtual switching, encryption, storage protocol handling and policy enforcement. Hyperscaler designs like AWS Nitro go further and move most of the hypervisor’s responsibilities to dedicated hardware, but the guest workloads continue to run on the host processors.

Is OVS hardware offload better than DPDK or XDP?

It depends on flow behavior and core budget. Offload removes host CPU cost for established flows, giving the best results for long-lived, high-throughput traffic. DPDK and XDP are more flexible, need no extra hardware beyond a good NIC, and handle short-lived flows without a rule-install penalty, but they use host cores in proportion to packet rate. Many deployments combine them, using hardware offload for bulk flows and software for exceptions.

Which is best: BlueField, Pensando or Intel IPU?

There is no universal winner. BlueField has the broadest software ecosystem and the closest integration with NVIDIA GPU and InfiniBand fabrics. AMD Pensando emphasizes a P4-programmable pipeline and has deep VMware ties. Intel IPU offers Neoverse cores, P4 programmability and a Google Cloud precedent. Choose by workload fit, ecosystem, supply and the skills of your team, and validate with a proof of concept on your own traffic.

Can I use a DPU with Kubernetes?

Yes. The usual approach gives pods SR-IOV virtual functions or scalable functions through a CNI plugin, with representors attached to an OVS bridge on the DPU. Operators such as NVIDIA’s DOCA Platform Framework manage DPU images and services from the Kubernetes API. Some designs make the DPU’s Arm cores a separate arm64 node. Verify that your CNI’s features, such as network policy, are supported in the offloaded path.

Does a DPU improve security?

It can, by moving policy enforcement and encryption into a separate trust domain with its own secure boot and root of trust, so that a compromised host cannot disable the firewall. It also adds attack surface: the DPU’s operating system, management interface and firmware need patching and monitoring. The net effect is positive only if you operate the DPU as carefully as any other production server.