OPI Summit on DPUs/IPUs 2026#

Core#

From Platform Baseline to Platform Handoff: Automating DPU Onboarding with sZTP - Anssi Söderena, Fusionlayer, Inc#

Abstract Recording

Speakers: Anssi Söderena, Senior Software Developer, FusionLayer Group

• Why: A DPU that has booted and pulled an IP is not production-ready — it still needs a trusted identity, known-good software, configuration, and provable state before anything will schedule workloads on it. This is exactly the seam between identity/bootstrapping and infrastructure automation that most DPU material hand-waves, and it is a concrete OPI Blueprint with lab results rather than a concept pitch.
• What: An OPI Blueprint that onboards an NVIDIA BlueField-3 from a known platform baseline using a Secure Zero Touch Provisioning (sZTP) server/client built on RFC 8572 (SZTP Bootstrap Data), then hands the DPU off to Kubernetes and the F5 Lifecycle Operator, with F5 BIG-IP Next for Kubernetes running TMM on the DPU. The session covers the workflow, lab findings, validation approach, compatibility constraints, and the boundary between sZTP onboarding and host/BMC-mediated BFB provisioning. (from abstract only)
• How: sZTP establishes trust and identity, applies initial configuration, runs bootstrap scripts, and reports onboarding progress and errors back to the server. Validation is end-to-end: real application traffic is pushed through the DPU to prove the onboarded state actually works before handoff to the Kubernetes operators.
• Where applicable: Firmly pinned to specific platform prerequisites in this blueprint: NVIDIA BlueField-3, the NVIDIA BF-Bundle, an F5-supported DOCA version, and vanilla Kubernetes with BIG-IP Next for Kubernetes. But the sZTP pattern itself (RFC 8572 + baseline attestation + traffic validation + operator handoff) is vendor-neutral and reusable for any DPU/SmartNIC onboarding pipeline. The presenter is the author of the open-source fl-sztp client, so expect real implementation detail.

Network Engine's Hardware Matrix Problem, and Why DPUs Solve What NICs Can't - Josh Brooks, WorldTech IT/Network Engine#

Abstract Recording

Speakers: Josh Brooks, Chief Solutions Architect / Distinguished Technologist, WorldTech IT

• Why: This is a rare, candid product-engineering postmortem about the gap every operator hits with SmartNIC offload: hardware support is a matrix, not a feature. The speaker runs a real product (a hypervisor for network virtual appliances) and explains precisely why NIC offload paths fragment — E823 supports switchdev, X710 does not, OVS-DPDK double-burns CPU when the appliance already runs its own DPDK fast path.
• What: WorldTech IT currently ships Network Engine without OVS, leaning on Linux bridges with NIC hardware acceleration, virtio multi-queue tuning, and SR-IOV/IOMMU passthrough for performance-critical NVAs — an explicitly pragmatic workaround. The talk announces OPI Blueprint 003: move OVS offload onto a DPU (NVIDIA BlueField-3 first, since it is largely packaged there), so switching stops consuming host CPU cores entirely, with the goal of generalizing the pattern to KVM and KubeVirt across the ecosystem. (from abstract only)
• How: Offload the host OVS datapath to the DPU's Arm cores via the BlueField-3's existing OVS packaging, rather than stacking DPDK in the host on top of appliance DPDK, or depending on per-NIC switchdev support that only exists on part of the hardware matrix.
• Where applicable: Describes WorldTech IT's own product engineering, but the underlying problem (per-NIC offload matrix, DPDK-in-host vs DPDK-in-appliance, when passthrough beats bridging) is common to anyone running virtualized network functions on commodity NICs. Blueprint work starts from one vendor's silicon (BlueField-3), which the speaker is upfront about — the OPI point is turning that single-vendor example into a repeatable standard.

One Control Plane, Many DPU/IPUs: SONiC DASH and Open DSE Powered by OPI - Serey Kong, Intel Corporation & Mounire El Houmaidi, BE-NET#

Abstract Recording

Speakers: Serey Kong, Tech Lead - Driver Architect, Intel Corporation; Mounire El Houmaidi, BE-NET

• Why: Heterogeneous DPU racks are becoming normal, and today each vendor's SDK drags its own control surface with it. This session demonstrates two working PoCs for the problem — translating a NOS control plane into vendor-neutral OPI APIs, and reconciling state across four vendors' DPUs — which is the central question for anyone planning multi-silicon DPU fleets.
• What: Two proof-of-concepts. (1) An in-process SAI-to-OPI adapter (libsai_opi_adapter.so) that translates SONiC DASH overlay objects — ENI, VNet, ACL — directly into OPI gRPC calls, keeping proprietary vendor SDKs confined to the DPU SoC so the host control plane stays uniform across mixed-vendor racks. (2) Open DSE, an intent-driven framework that executes workloads across NVIDIA, Intel, AMD, and Marvell DPUs, using OPI to reconcile state and — notably — to distinguish functional connectivity from true hardware offload, i.e. to verify offload actually happened rather than being emulated in software. (from abstract only)
• How: The adapter pattern maps SONiC's SAI object model onto OPI's gRPC northbound API; Open DSE drives intent across heterogeneous DPUs and uses OPI state reconciliation as the ground truth for whether offload is genuine. This is the software-offload trap in disguise — a NIC can accept the API and still do the work on the host — so the verification distinction is a genuinely practical contribution.
• Where applicable: The SAI adapter is tied to SONiC DASH deployments; Open DSE spans NVIDIA, Intel, AMD, and Marvell silicon per the abstract. These are PoCs, so treat multi-vendor coverage as demonstrated-in-lab rather than production-hardened, but the architecture (vendor SDKs isolated on the SoC, one gRPC northbound) is broadly applicable and aligns with where the OPI project is heading.

Adjacent#

Reimagining DPUs for Storage Control and End-to-End Confidential AI - Jitendra Singh & Anshuman Ghosh, Microsoft#

Abstract Recording

Speakers: Jitendra Singh and Anshuman Ghosh, Senior Software Engineers, Microsoft

• Why: The identity/attestation angle makes this worth watching: the claim is that DPUs evolve from offload engines into a verifiable trust layer for AI infrastructure — a place where attestation, policy enforcement, and tenant isolation live in hardware independent of the host. That intersects directly with workload-identity and confidential-computing roadmaps even if you don't run AI factories.
• What: An architectural vision talk, not a results talk: how DPUs can serve as a common control and security layer across storage, networking, and AI infrastructure, enabling disaggregated storage, optimized storage-to-accelerator data paths (checkpoints, embeddings, vector indexes, KV caches, prompts), tenant isolation, attestation, and trusted-execution workflows for "confidential AI." It frames DPUs as foundational building blocks for security-first, AI-native platforms and closes on challenges and open opportunities. (from abstract only)
• How: Mechanisms named in the abstract are DPU-mediated storage control, active data movement between storage and accelerators, and DPU-enforced policy/attestation across the data path. No specific system, measurement, or deployment is described, so expect architecture patterns rather than substantiated numbers.
• Where applicable: Vendor (Microsoft) perspective on where DPU platforms are heading; it sketches a plausible convergence of confidential computing, attestation, and infrastructure offload, but nothing here is yet a deployable technique. Useful as roadmap signal for how attested data paths may be positioned over the next cycle.

Feeding the AI Factory: The Role of DPU/IPUs in AI Infrastructure - Tina Tsou, Board Chair, LF Edge; Rajalaxmi Angadi, Senior Engineering Manager, Intel & Moderated by Paul Pindell, F5 Networks#

Abstract Recording

Speakers: Tina Tsou (LF Edge / InfiniEdge AI TSC), Rajalaxmi Angadi (Intel), Paul Pindell (F5 Networks)

• Why: Positions the DPU question the industry is actually arguing about: at 800G+ AI-fabric scale, the bottleneck shifts from GPU compute to data movement, storage I/O, and infrastructure overhead — and the panel's through-line is whether OPI can keep heterogeneous DPU/IPU fleets from fragmenting into per-vendor silos.
• What: A panel discussion on offloading virtual networking, NVMe-oF storage access for KV caches, security enforcement, and telemetry to DPUs/IPUs to reclaim host CPU/GPU cycles, enforce hardware-isolated security air gaps, and improve AI job completion times in multi-tenant clusters — with emphasis on OPI's role in preventing vendor lock-in via standardized gRPC APIs, gNMI telemetry, and the community DPU Operator as unified northbound abstractions. (from abstract only)
• How: Panel format — no single technique to evaluate, but the framing (one open AI-factory blueprint over heterogeneous silicon, DPU as the multi-tenancy security boundary) is a useful synthesis of where hyperscalers and cloud providers are converging.
• Where applicable: Relevant to multi-tenant AI cluster operators and cloud providers; the OPI abstractions it references are real upstream work (DPU Operator, gNMI, gRPC) but the session itself is discussion, not evaluation. Skew toward Intel/NVIDIA-era 800G assumptions.

KV Cache in the Agentic Era: The Five Forces that Decide Where the Cache Lives, and What a DPU Can Do About It - Jigar Kuverji Savla, Tensordyne#

Abstract Recording

Speakers: Jigar Kuverji Savla, ASIC Architect & Product Manager, Tensordyne

• Why: Agentic AI workloads re-read entire conversation histories each turn, which turns KV-cache placement into a systems problem spanning chip memory, system RAM, local drives, network storage, and — the speaker argues — the DPU as the data mover. This is a concrete case of AI workload pressure reshaping data-path design, with numbers attached.
• What: A framework of "five forces" that determine where KV-cache memory should live: (1) agent turns — move memory blocks only at turn boundaries; (2) execution stages — keep the main processor on control while the DPU moves whole blocks; (3) model sizes — size storage to actual context needs and stop moving data at the crossover point; (4) orchestrators — store shared text once, route tasks to the holder, track hit rates by tier; (5) hardware paths — the physical route determines real speed. Claims measured results: a well-chosen path yields a 3.4x speedup while a poor one costs a 3.84x slowdown, raising the question of whether freed chip memory should buy cheaper servers or more useful capacity. The talk offers a blueprint for measuring the whole data path. (from abstract only)
• How: Tiered memory placement with turn-boundary migration, DPU-driven bulk data movement, orchestrator-level deduplication and locality-aware routing, and an end-to-end path-measurement methodology.
• Where applicable: Specific to agentic inference serving (context-heavy, read-mostly, turn-structured workloads) rather than training or general serving. The 3.4x/3.84x figures come from the speaker's own testing at Tensordyne; methodology details are promised in the talk but not in the abstract, so treat the exact numbers as single-vendor until seen.

Wildcard#

How Open Hardware Access Builds the Next Generation of Infrastructure Engineers - Sam Dasilva, Red Hat#

Abstract Recording

Speakers: Sam Dasilva, Associate Software Engineer, Red Hat

• Why: Not a networking technique, but a genuinely different argument: the open-source model fixed contributor access to software decades ago, but infrastructure-acceleration work (DPUs, SuperNICs) is still gated behind vendor employment — so the contributor pipeline for the exact hardware class this whole conference is about is artificially narrow. The talk walks one full path: CS student with no STEM background → Red Hat intern on DPU/SmartNIC work → OPI LFX mentee who upstreamed the DPU Operator.
• What: The technical substance of the handoff: decoupling the DPU Operator from OpenShift-specific dependencies, making it work on vanilla Kubernetes, validating across Fedora/CentOS Stream/AlmaLinux via bootable containers, and standing up multi-vendor community CI for DPU hardware. Plus the argument that open hardware labs plus mentorship produce both working code and working engineers. (from abstract only)
• How: Concretely: dependency decoupling for k8s portability, bootable-container-based OS validation matrices, and community CI across multiple DPU vendors — the same engineering patterns (portability, CI, upstreaming) applied to the hardware-access problem itself.
• Where applicable: Relevant to anyone building or depending on open infrastructure projects facing hardware access as the bottleneck (DPU/IPU, SmartNIC, accelerator ecosystems). The multi-vendor CI story also matters operationally if you consume the DPU Operator: it describes what is actually validated, and on what.

Notes on the rest of the program#

The program is short; beyond the sessions above it consists of meals, a break, and opening remarks. One session — From Complexity to Deployment: Bridging the DPU Adoption Gap (Benoit Paquin, Kalray) — has no abstract in the program text, only a speaker bio (Kalray product management lead), so its substance cannot be assessed; a vendor PM-led talk with no published abstract is likely roadmap-flavored and is not selected here.

Themes#

• OPI's maturity pivot from spec to blueprint: the strongest talks are OPI Blueprints with lab findings (sZTP onboarding, OVS-on-DPU, SAI adapter), not abstract API definitions — the project is now proving patterns on real silicon.
• Multi-vendor verification as the hard problem: several sessions converge on distinguishing genuine hardware offload from software emulation, and keeping proprietary SDKs confined to the DPU SoC behind a gRPC/gNMI northbound.
• DPUs as the security and trust boundary: hardware-isolated air gaps, attestation, trusted bootstrapping, and confidential-AI data paths — identity/trust functions are migrating into the DPU layer.
• AI workloads are rewriting DPU requirements: KV-cache movement, NVMe-oF for accelerators, and turn-structured memory migration are driving a new class of data-path problems (and marketing) around DPUs.
• The BlueField-3 gravity well: NVIDIA's BlueField-3 is the default first target for nearly every blueprint, which makes the single-vendor-to-standard transition both the explicit goal and the open risk of the ecosystem.