OPI Summit on DPUs/IPUs 2026

A DPU is not ready for use simply because it has booted or received an IP address. It still needs a trusted identity, compatible software, network configuration, credentials, and evidence that it has reached the expected state.

This session presents an OPI Blueprint that uses FusionLayer’s RFC 8572 sZTP server and client to prepare an NVIDIA BlueField-3 from a factory-default or reinitialized state. The workflow establishes trust, verifies onboarding artifacts, applies initial configuration, runs bootstrap scripts, reports progress, handles failures, and performs readiness checks.

OpenShift and F5-specific tools then complete the platform integration. An existing Red Hat OpenShift and F5 BIG-IP Next environment serves as the integration target. The project aims to validate traffic flowing from a virtual IP address through the BIG-IP Next traffic-processing component on the DPU to application pods.

We will share the resulting workflow, validation results, compatibility constraints, and the boundary between repeatable sZTP onboarding and platform-specific integration.

AI infrastructure is rapidly exposing new limitations in traditional cloud architectures. As models scale, the challenge is no longer limited to computation. Model checkpoints, embeddings, vector indexes, prompts, KV caches, and inference data must move efficiently and securely across storage, networks, processors, and accelerators.
Historically, DPUs have been used to offload networking, storage, and security functions from host CPUs. However, the next evolution of programmable infrastructure is far more significant. DPUs are emerging as intelligent infrastructure components that can actively participate in storage control, data movement, policy enforcement, tenant isolation, attestation, and trusted execution workflows.
This session explores how DPUs are evolving from infrastructure accelerators into foundational building blocks for AI-native and security-first platforms. We examine emerging architectures where DPUs enable disaggregated storage, optimize storage-to-accelerator data paths, and establish verifiable trust across AI infrastructure. The talk explores how emerging DPU architectures can provide a common control and security layer across storage, networking, and AI infrastructure, enabling more trusted and scalable AI platforms. Attendees will gain insight into the future role of DPUs in storage architectures, confidential AI deployments, trusted data movement, along with key challenges and opportunities shaping the next generation of programmable infrastructure.

SONiC DASH programs tenant overlay objects — ENI, VNET, routes, ACL — through the SAI C ABI that dashorch already uses. On a DPU/IPU those objects must land in hardware tables on the card, not in a software switch on the host.
The default path today is a vendor SAI library loaded into syncd. That library talks a proprietary SDK from the host. The SONiC image, the SAI .so, and the DPU firmware become a single-vendor stack. Swap a BlueField for an Intel IPU and you rebuild the NOS.
This talk presents a different seam: SAI northbound, and OPI southbound. libsai_opi_adapter.so is dlopened as libsai.so — the same path every SONiC ASIC backend uses. sai_create_eni becomes CreateInterface + CreateVnic. sai_get_eni_stats becomes GetVnicMetrics. The vendor’s closed SDK stays behind an OPI bridge on the DPU SoC. The host never opens a DOCA or IPDK handle.

We will show, through a working demo,
1. The object mapping contract as a published, vendor-neutral dictionary
2, An end-to-end lab: gNMI Set (SAI-Challenger / gnmic) → APPL_DB → dashorch → in-process SAI → OPI :50051 on the DPU
3. What is live in the .so today (ENI create + stats).
4. Why this split matters for multi-vendor racks

DPUs and SuperNICs sit at the center of AI factories, HPC and hyperscaler networking, but the hardware is still mostly locked behind vendor employment. Open-source software solved contributor access decades ago. Hardware has not. That leaves the infrastructure-acceleration contributor pipeline artificially narrow when the industry needs it wide.

This talk follows one path through OPI's open model: CS student with no STEM pipeline, Red Hat intern on DPU/SmartNIC work, then OPI LFX mentee who brought the DPU Operator into OPI as upstream. We cover the technical work of that handoff (decoupling OpenShift-specific dependencies, supporting vanilla Kubernetes, validating Fedora/CentOS Stream/AlmaLinux via bootable containers, and standing up multi-vendor community CI) and show how open labs and mentorship produce both working code and working engineers. From there, OPI steers the project.

Attendees leave with a concrete model for growing the DPU/IPU contributor base by solving the hardware access problem, as well as the software one.

WorldTech IT builds Network Engine, a purpose-built hypervisor for network virtual appliances, on an open-source foundation. Today we don't ship with OVS. Our supported NICs span Intel E823 and X710, but only E823 supports switchdev offload, so there's no consistent path across the matrix. OVS-DPDK covers X710, but most of our NVAs already run their own DPDK fast path, so stacking DPDK in the host OVS just burns CPU cores twice. Instead we lean on Linux bridges with NIC hardware acceleration, virtio multi-queue tuning, and SR-IOV/IOMMU passthrough where NVAs need maximum performance.
I'm sponsoring OPI Blueprint 003: OVS offload on a DPU, starting with NVIDIA BlueField-3 since it's already largely packaged there, with the goal of bringing that pattern to the rest of the ecosystem for both KVM and KubeVirt. Move OVS to the DPU and switching stops costing host CPU cores at all. I'll cover what we've hit in product engineering, where the blueprint stands, and why turning one vendor's example into an ecosystem standard is the whole point of OPI.

DPUs and IPUs can move networking, security, storage, telemetry, and other infrastructure services away from host CPUs. The operational challenge is that different devices expose different discovery, lifecycle, endpoint, forwarding, and evidence models.
This session introduces Open DSE (open variant of vSphere's DSE), a demo-ready open-source framework for expressing, executing, and validating DPU/IPU infrastructure-offload workflows. . Users express the required outcome through one control point, while Open DSE validates the topology, applies readiness gates, maps VFs and representors or equivalent endpoints, configures forwarding, runs traffic, collects evidence, generates a report, and safely removes only the state created by the experiment.
The session includes a live hardware demonstration of two KVM/QEMU virtual machines communicating through a DPU-controlled forwarding path, followed by evidence showing whether the flow was configured in software or offloaded to hardware. The talk will also share where attempted abstraction succeeds, where it fails, and what those results suggest for OPI APIs, operators, blueprints, and interoperability testing