超擎数智超擎数智

Tech Preview for DPF Host Trusted DPU Passthrough - v25.10.0

Created on March 05, 2026 Scope This guide provides detailed instructions for deploying a Kubernetes (K8s) cluster using NVIDIA® BlueField®-3 DPU and DOCA Platform Framework (DPF) in Host-Trusted mode, with the worker node not connected to the host management network. It relies on the Baseline RDG and details additional steps for passthrough mode.

文档目录

Created on March 05, 2026

Scope

This guide provides detailed instructions for deploying a Kubernetes (K8s) cluster using NVIDIA® BlueField®-3 DPU and DOCA Platform Framework (DPF) in Host-Trusted mode. The guide covers provisioning DPU in passthrough mode where the worker node is not connected to the host management network.

This document relies on the RDG for DPF with OVN-Kubernetes and HBN Services (referred to as the Baseline RDG), especially for the infrastructure preparation part. It details the additional steps and modifications required to deploy DPU in passthrough mode in the modified architecture mentioned above.

Leveraging NVIDIA's DPF, administrators can provision and manage DPU resources within a Kubernetes cluster while deploying and orchestrating special DPU services such as HBN (Host Based Networking) and accelerated OVN-Kubernetes. This approach enables full utilization of NVIDIA DPU hardware acceleration and offloading capabilities, maximizing data center workload efficiency and performance.

Warning

  • This guide is a specific, opiniated deployment example designed to address the use case described above
  • While other approaches may exist to implement similar solutions, this document provides a detailed guide for this particular method

Abbreviations and Acronyms

Term Definition Term Definition
BFB BlueField Bootstream MAAS Metal as a Service
CNI Container Network Interface NFS Network File System
CRD Custom Resource Definition OVN Open Virtual Network
DOCA Data Center Infrastructure-on-a-Chip Architecture PVC Persistent Volume Claim
DPF DOCA Platform Framework RDG Reference Deployment Guide
DPU Data Processing Unit SFC Service Function Chaining
K8S Kubernetes VLAN Virtual LAN (Local Area Network)

References

Solution Architecture

Key Components and Technologies

  • NVIDIA BlueField® Data Processing Unit (DPU) The NVIDIA® BlueField® data processing unit (DPU) ignites unprecedented innovation for modern data centers and supercomputing clusters. With its robust compute power and integrated software-defined hardware accelerators for networking, storage, and security, BlueField creates a secure and accelerated infrastructure for any workload in any environment, ushering in a new era of accelerated computing and AI.

  • NVIDIA DOCA Software Framework NVIDIA DOCA™ unlocks the potential of the NVIDIA® BlueField® networking platform. By harnessing the power of BlueField DPU and SuperNICs, DOCA enables the rapid creation of applications and services that offload, accelerate, and isolate data center workloads. It lets developers create software-defined, cloud-native, DPU- and SuperNIC-accelerated services with zero-trust protection, addressing the performance and security demands of modern data centers.

  • NVIDIA ConnectX SmartNICs 10/25/40/50/100/200 and 400G Ethernet Network 网卡 The industry-leading NVIDIA® ConnectX® family of smart network interface cards (SmartNICs) offer advanced hardware offloads and accelerations. NVIDIA Ethernet adapters enable the highest ROI and lowest Total Cost of Ownership for hyperscale, public and private clouds, storage, machine learning, AI, big data, and telco platforms.

  • NVIDIA LinkX Cables The NVIDIA® LinkX® product family of cables and transceivers provides the industry’s most complete line of 10, 25, 40, 50, 100, 200, and 400GbE in Ethernet and 100, 200 and 400Gb/s InfiniBand products for Cloud, HPC, hyperscale, Enterprise, telco, storage and artificial intelligence, data center applications.

  • NVIDIA Spectrum 以太网交换机 Flexible form-factors with 16 to 128 physical ports, supporting 1GbE through 400GbE speeds. Based on a ground-breaking silicon technology optimized for performance and scalability, NVIDIA Spectrum switches are ideal for building high-performance, cost-effective, and efficient Cloud Data Center Networks, Ethernet Storage Fabric, and Deep Learning Interconnects. NVIDIA combines the benefits of NVIDIA Spectrum™ switches, based on an industry-leading application-specific integrated circuit (ASIC) technology, with a wide variety of modern network operating system choices, including NVIDIA Cumulus® Linux, SONiC and NVIDIA Onyx®.

  • NVIDIA Cumulus Linux NVIDIA® Cumulus® Linux is the industry's most innovative open network operating system that allows you to automate, customize, and scale your data center network like no other.

  • Kubernetes Kubernetes is an open-source container orchestration platform for deployment automation, scaling, and management of containerized applications.

  • Kubespray Kubespray is a composition of Ansible playbooks, inventory, provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks and provides:

    • A highly available cluster
    • Composable attributes
    • Support for most popular Linux distributions

Solution Design

Solution Logical Design

Solution Logical Design

The logical design includes the following components:

  • 1 x Hypervisor node (KVM based) with ConnectX-7
    • 1 x Firewall VM
    • 1 x Jump VM
    • 1 x MAAS VM
    • 1 x Storage Target VM
    • 3 x VMs running all K8s management components for Host/DPU clusters
  • 1 x Worker node with BlueField-3 NIC
  • Single 200 GbE High-Speed (HS) switch
  • 1 GbE Host Management network

image-2026-3-5_18-24-7-1.png

SFC Logical Diagram

The following diagram demonstrates how the DHCP will work during the DPU provisioning phase:

image-2026-3-5_18-35-4-1.png

Firewall Design

The pfSense firewall in this solution serves a dual purpose:

  • Firewall – Provides an isolated environment for the DPF system, ensuring secure operations
  • Router – Enables internet access and connectivity between the host management network and the high-speed network

Port-forwarding rules for SSH and RDP are configured on the firewall to route traffic to the jump node's IP address in the host management network. From the jump node, administrators can manage and access various devices in the setup, as well as handle the deployment of the Kubernetes (K8s) cluster and DPF components.

The following diagram illustrates the firewall design used in this solution:

firewall_design.png

Software Stack Components

Software_Stack_updated.png

Warning: Make sure to use the exact same versions for the software stack as described above.

Bill of Materials

Bill_Of_Materials.png

Deployment and Configuration

Node and Switch Definitions

These are the definitions and parameters used for deploying the demonstrated fabric:

Switch Port Usage
mgmt-switch 1 swp1
hs-switch 1 swp1-4
Hosts
Rack Server Type Server Name Switch Port IP and NICs Default Gateway
Rack1 Hypervisor Node hypervisor mgmt-switch: swp1hs-switch: swp1-swp2 lab-br (interface eno1): Trusted LAN IPmgmt-br (interface eno2): -hs-br (interface ens2f0np0): - Trusted LAN GW
Rack1 Worker Node worker hs-switch: swp3-swp4 ens2f0np0: 10.0.123.21/24 10.0.123.254
Rack1 Firewall (Virtual) fw - WAN (lab-br): Trusted LAN IPLAN (mgmt-br): 10.0.110.254/24OPT1 (hs-br): 172.169.50.1/30 Trusted LAN GW
Rack1 Jump Node (Virtual) jump - enp1s0: 10.0.110.253/24 10.0.110.254
Rack1 MAAS (Virtual) maas - enp1s0: 10.0.110.252/24enp7s0np1: 10.0.123.252/24 10.0.110.254
Rack1 Master Node (Virtual) master1 - enp1s0: 10.0.110.1/24 10.0.110.254
Rack1 Master Node (Virtual) master2 - enp1s0: 10.0.110.2/24 10.0.110.254
Rack1 Master Node (Virtual) master3 - enp1s0: 10.0.110.3/24 10.0.110.254

Wiring

布线

虚拟机管理节点

Wiring_Hypervisor_Node.png

K8s 工作节点

Wiring_K8s_Worker.png

网络结构配置

更新 Cumulus Linux

最佳实践是确保使用最新发布的 Cumulus Linux NOS 版本。

有关如何升级 Cumulus Linux 的信息，请参阅 Cumulus Linux 用户指南。

配置 Cumulus Linux 交换机

SN3700 交换机 (hs-switch) 配置如下：

nv set bridge domain br_default untagged 1
nv set interface swp1-4 link state up
nv set interface swp1-4 type swp
nv set interface swp1 ipv4 address 172.169.50.2/30
nv set interface swp2-4 bridge domain br_default
nv set interface vlan1 ipv4 address 10.0.123.254/24
nv set vrf default router static 0.0.0.0/0 address-family ipv4-unicast
nv set vrf default router static 0.0.0.0/0 via 172.169.50.1 type ipv4-address
nv set vrf default router static 10.0.110.0/24 address-family ipv4-unicast
nv set vrf default router static 10.0.110.0/24 via 172.169.50.1 type ipv4-address
nv config apply -y

SN2201 交换机 (mgmt-switch) 配置如下：

nv set bridge domain br_default untagged 1
nv set interface swp1 link state up
nv set interface swp1 type swp
nv set interface swp1 bridge domain br_default
nv config apply -y

主机配置

注意： 本指南假设工作节点中的 BlueField-3 已处于 NIC 模式。如果不是，请参阅 BlueField 操作模式 - 更改模式 了解如何切换到 NIC 模式。

与基线 RDG（“部署和配置”部分，“主机配置”小节）相比无变化。

虚拟机管理程序安装和配置

与基线 RDG（“虚拟机管理程序安装和配置”部分）相比无变化。

准备基础设施服务器

与基线 RDG（“部署和配置”部分，“准备基础设施服务器”小节）中关于防火墙 VM 和跳板 VM 的内容相比无变化。

MaaS VM

建议规格：

  • vCPU：4
  • RAM：4GB
  • 存储：50GB
  • 网络接口：
    • 桥接设备，连接到 mgmt-br
    • ConnectX-7 第二端口，通过 PCI 直通作为 PCIe 设备附加

步骤：

  1. 在安装前为 ConnectX-7 第二端口添加 PCIe 设备：

    maas_hs_interface_without_name.png

  2. 创建以下 Netplan 配置以启用互联网连接、DNS 解析并在高速子网中设置 IP：

    警告：

    • 将 enp1s0 和 enp7s0np1 替换为您的接口名称。
    • 使用 10.0.110.254 作为临时 DNS 服务器。MaaS 安装完成后，在跳板机和 MaaS VM 的 Netplan 文件中将此地址替换为 MaaS IP 地址 (10.0.110.252)。
    network:
  version: 2
  ethernets:
    enp1s0:
      addresses:
      - "10.0.110.252/24"
      nameservers:
        addresses:
        - 10.0.110.254
        search:
        - dpf.rdg.local.domain
      routes:
      - to: "default"
        via: "10.0.110.254"
    enp7s0np1:
      mtu: 9000
      addresses:
        - "10.0.123.252/24"

  3. 按照基线 RDG（“部署和配置”部分，“准备基础设施服务器”小节，“MaaS VM”小节）中的步骤 3-12 进行操作。

  4. 在 MaaS 中配置高速网络，使其能够为其提供 DHCP：

    maas admin subnets create name="hs-dpf" cidr="10.0.123.0/24" gateway_ip=”10.0.123.254” fabric=1
maas admin ipranges create type=dynamic start_ip="10.0.123.51" end_ip="10.0.123.120"
maas admin vlan update 1 untagged dhcp_on=True primary_rack=maas mtu=9000

  5. 为工作节点配置静态 DHCP 租约（将 MAC 地址替换为工作节点 PF0 接口的 MAC）：

    maas admin reserved-ips create ip="10.0.123.21" mac_address="c4:70:bd:cc:66:b8" comment="worker-hs"

  6. 按照基线 RDG 中的步骤 14-15 进行操作。

使用 MaaS 配置主节点 VM 和工作节点

主节点 VM

按照基线 RDG 中的说明进行操作，直到“在主节点 VM 上配置 OVS 桥接”小节。由于使用的 CNI 是 Calico 而非 OVN-Kubernetes，此部署中不需要 OVS 桥接，因此应跳过此部分。

使用 Cloud-Init 部署主节点 VM

使用以下 cloud-init 脚本配置必要的软件：

#cloud-config
system_info:
  default_user:
    name: depuser
    passwd: "$6$jOKPZPHD9XbG72lJ$evCabLvy1GEZ5OR1Rrece3NhWpZ2CnS0E3fu5P1VcZgcRO37e4es9gmriyh14b8Jx8gmGwHAJxs3ZEjB0s0kn/"
    lock_passwd: false
    groups: [adm, audio, cdrom, dialout, dip, floppy, lxd, netdev, plugdev, sudo, video]
    sudo: ["ALL=(ALL) NOPASSWD:ALL"]
    shell: /bin/bash
ssh_pwauth: True
package_upgrade: true
runcmd:
    - apt-get

update - apt-get -y install nfs-common

之后，完全按照基线 RDG 中的说明进行操作，并使用相同的命令进行验证，但与 OVS 相关的命令除外。

Worker 节点

与基线 RDG 相比，worker 节点配置没有变化，只是 br-dpu 上行链路应为 PF0（而非主机管理适配器），子网应为 10.0.123.0/24（而非 10.0.110.0/24）。

K8s 集群部署与配置

Kubespray 部署与配置

对于 K8s 部署，使用与基线 RDG 相同的修改版 Kubespray。

执行以下更改以使用 Calico CNI（而非基线 RDG 中的 OVN-Kubernetes）：

  1. 编辑文件 inventory/mycluster/group_vars/k8s_cluster/k8s-cluster.yml，修改以下行：

    ...
kube_network_plugin: calico
...
kube_proxy_remove: false
kube_proxy_mode: ipvs
...
kube_proxy_strict_arp: true

  2. 查看并编辑 inventory/mycluster/hosts.yaml 文件以定义集群节点。以下是本次部署的配置：

    警告

    • Worker 节点包含额外的 kubelet 配置，将在部署期间应用以实现最佳性能，允许：
      • 具有整数 CPU requests 的 Guaranteed pod 中的容器访问节点上的独占 CPU。
      • 使用 reservedSystemCPUs 选项为系统预留一些核心（启用静态策略时，kubelet 要求预留大于零的 CPU），并确保它们属于 NUMA 0（因为示例中的 NIC 连接到 NUMA 节点 1，如果 NIC 连接到 NUMA 节点 0，则使用 NUMA 1 的核心）。
      • 将拓扑定义为 single-numa-node，以便仅当所有请求的 CPU 和设备都可以从同一个 NUMA 节点分配时才允许 pod 被接纳。
    • kube_node 主机 worker 标记为 #，以便最初仅部署控制平面节点（稍后安装 DPF 系统所需的各种组件后，再添加 worker 节点）。
    all:
  hosts:
    master1:
      ansible_host: 10.0.110.1
      ip: 10.0.110.1
      access_ip: 10.0.110.1
    master2:
      ansible_host: 10.0.110.2
      ip: 10.0.110.2
      access_ip: 10.0.110.2
    master3:
      ansible_host: 10.0.110.3
      ip: 10.0.110.3
      access_ip: 10.0.110.3
    worker:
      ansible_host: 10.0.123.21
      ip: 10.0.123.21
      access_ip: 10.0.123.21
      node_labels:
        "node-role.kubernetes.io/worker": ""
      kubelet_cpu_manager_policy: static
      kubelet_topology_manager_policy: single-numa-node
      kubelet_reservedSystemCPUs: 0-7
  children:
    kube_control_plane:
      hosts:
        master1:
        master2:
        master3:
    kube_node:
      hosts:
        # worker:
    etcd:
      hosts:
        master1:
        master2:
        master3:
    k8s_cluster:
      children:
        kube_control_plane:
        kube_node:

  3. 使用 Kubespray 进行初始 Kubernetes 集群部署（master 节点）的其余步骤与基线 RDG 保持不变（第 "K8s Cluster Deployment and Configuration" 节，子节 "Kubespray Deployment and Configuration" 和 "Deploying Cluster Using Kubespray Ansible Playbook"）。

  4. 集群部署后，运行以下命令：

    $ kubectl wait --for=condition=ready nodes --all
node/master1 condition met
node/master2 condition met
node/master3 condition met

$ kubectl wait --for=condition=ready --namespace kube-system pods --all
pod/calico-kube-controllers-dbf6dc49-jvlx6 condition met
pod/calico-node-68cqk condition met
pod/calico-node-bzhxh condition met
pod/calico-node-vdkj5 condition met
pod/coredns-5c54f84c97-dhnfj condition met
pod/coredns-5c54f84c97-p6v4g condition met
pod/dns-autoscaler-56cb45595c-hlzjw condition met
pod/kube-apiserver-master1 condition met
pod/kube-apiserver-master2 condition met
pod/kube-apiserver-master3 condition met
pod/kube-controller-manager-master1 condition met
pod/kube-controller-manager-master2 condition met
pod/kube-controller-manager-master3 condition met
pod/kube-proxy-8xfmd condition met
pod/kube-proxy-hx9nd condition met
pod/kube-proxy-rxg5k condition met
pod/kube-scheduler-master1 condition met
pod/kube-scheduler-master2 condition met
pod/kube-scheduler-master3 condition met
pod/kube-vip-master1 condition met
pod/kube-vip-master2 condition met
pod/kube-vip-master3 condition met

与基线 RDG 一样，worker 节点将在 DPF 安装后添加。

DPF 安装

与基线 RDG 不同，DPF 安装过程遵循直通用例（DPU Passthrough in DPF Host Trusted - NVIDIA Docs）。

软件先决条件和必需变量

有关软件先决条件（如 helm、envsubst），请参考基线 RDG（第 "DPF Installation" 节，子节 "Software Prerequisites and Required Variables"）。

克隆 DPF doca-platform Git 仓库后，切换到目录 docs/public/user-guides/host-trusted/use-cases/passthrough/，后续命令将在该目录中运行。

使用以下文件定义安装所需的变量：

错误 将 DPUCLUSTER_INTERFACE 替换为您的接口名称。

## Virtual IP used by the load balancer for the DPU Cluster. Must be a reserved IP from the management subnet and not allocated by DHCP.
export DPUCLUSTER_VIP=10.0.110.200

## Interface on which the DPUCluster load balancer will listen. Should be the management interface of the control plane node.
export DPUCLUSTER_INTERFACE=enp1s0

## IP address to the NFS server used as storage for the BFB.
export NFS_SERVER_IP=10.0.110.253

## The DPF REGISTRY is the Helm repository URL where the DPF Operator Chart resides.
## Usually this is the NVIDIA Helm NGC registry. For development purposes, this can be set to a different repository.
export REGISTRY=https://helm.ngc.nvidia.com/nvidia/doca

## The DPF TAG is the version of the DPF components which will be deployed in this guide.
export TAG=v25.10.0

## URL to the BFB used in the `bfb.yaml` and linked by the DPUSet.
export BFB_URL=https://content.mellanox.com/BlueField/BFBs/Ubuntu24.04/bf-bundle-3.2.1-34_25.11_ubuntu-24.04_64k_prod.bfb

导出安装所需的环境变量：

source manifests/00-env-vars/envvars.env

DPF Operator Installation

Create Storage Required by the DPF Operator

  • Create the NS for the operator:

    Jump Node Console

    kubectl create ns dpf-operator-system

  • The following YAML file defines storage (for the BFB image) that is required by the DPF operator.

    YAML

    ---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: bfb-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  nfs:
    path: /mnt/dpf_share/bfb
    server: $NFS_SERVER_IP
  persistentVolumeReclaimPolicy: Delete
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: bfb-pvc
  namespace: dpf-operator-system
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  volumeMode: Filesystem
  storageClassName: ""

  • Run the following command to substitute the environment variables using envsubst and apply the yaml file:

    cat manifests/01-dpf-operator-installation/*.yaml | envsubst | kubectl apply -f –

Additional Dependencies

  1. The DPF Operator requires several prerequisite components to function properly in a Kubernetes environment. Starting with DPF v25.7, all Helm dependencies have been removed from the DPF chart. This means that all dependencies must be installed manually before installing the DPF chart itself. The following commands describe an opiniated approach to install those dependencies (for more information, check: Helm Prerequisites - NVIDIA Docs).

    1. Install helmfile binary:

      Jump Node Console

      wget https://github.com/helmfile/helmfile/releases/download/v1.1.2/helmfile_1.1.2_linux_amd64.tar.gz
tar  -xvf helmfile_1.1.2_linux_amd64.tar.gz
sudo mv ./helmfile /usr/local/bin/

    2. Change directory to doca-platform:

      Use another shell from the one where you run all the other installation commands for DPF.

      Jump Node Console

      cd doca-platform/

    3. Install Helm dependencies using the following command:

      Jump Node Console

      make HELMFILE_FILE=deploy/helmfiles/prereqs.yaml test-deploy-helmfile

DPF Operator Deployment

  1. Run the following commands to install the DPF Operator:

    Jump Node Console

    helm repo add --force-update dpf-repository ${REGISTRY}
helm repo update
helm upgrade --install -n dpf-operator-system dpf-operator dpf-repository/dpf-operator --version=$TAG

  2. Verify the DPF Operator installation by ensuring the deployment is available and all the pods are ready:

    The following verification commands may need to be run multiple times to ensure the conditions are met.

    $ kubectl rollout status deployment --namespace dpf-operator-system dpf-operator-controller-manager
deployment "dpf-operator-controller-manager" successfully rolled out

$ kubectl wait --for=condition=ready --namespace dpf-operator-system pods --all
pod/argo-cd-argocd-application-controller-0 condition met
pod/argo-cd-argocd-redis-77dfd8fcb4-5nvqf condition met
pod/argo-cd-argocd-repo-server-7b6c5b8cdb-vshhx condition met
pod/argo-cd-argocd-server-744d5f9c7c-x7lds condition met
pod/dpf-operator-controller-manager-645467745b-pb69x condition met
pod/kamaji-556cb86895-hdlj9 condition met
pod/kamaji-etcd-0 condition met
pod/kamaji-etcd-1 condition met
pod/kamaji-etcd-2 condition met
pod/maintenance-operator-585767f779-rt6gf condition met
pod/node-feature-discovery-gc-7f64f764f8-4zc7p condition met
pod/node-feature-discovery-master-6fbc95665c-jlrlf condition met

DPU Provisioning and Interface Plumbing

In this step the DPU are provisioned and the necessary interface plumbing is configured to enable the DPU to act as a passthrough device.

In addition to that, to support the DPU provisioning without having a management network interface on the worker and for the host to receive IP via DHCP on PF0 a special DPUFlavor will be configured:

The flavor does the following:

  • Plugs pf0hpf representor in br-sfc.
  • Creates a one-time service (ovs-flows) which runs after the OVS service to set simple rules in br-sfc OVS-bridge to forward traffic from pf0hpf to p0 and vice-versa, so the host will be able to receive DHCP IP and continue with the provisioning process.

YAML

---
apiVersion: provisioning.dpu.nvidia.com/v1alpha1
kind: DPUFlavor
metadata:
  name: passthrough-$TAG
  namespace: dpf-operator-system
spec:
  grub:
    kernelParameters:
    - console=hvc0
    - console=ttyAMA0
    - earlycon=pl011,0x13010000
    - fixrttc
    - net.ifnames=0
    - biosdevname=0
    - iommu.passthrough=1
    - cgroup_no_v1=net_prio,net_cls
    - hugepagesz=2048kB
    - hugepages=3072
  nvconfig:
  - device: "*"
    parameters:
    - PF_BAR2_ENABLE=0
    - PER_PF_NUM_SF=1
    - PF_TOTAL_SF=20
    - PF_SF_BAR_SIZE=10
    - NUM_PF_MSIX_VALID=0
    - PF_NUM_PF_MSIX_VALID=1
    - PF_NUM_PF_MSIX=228
    - INTERNAL_CPU_MODEL=1
    - INTERNAL_CPU_OFFLOAD_ENGINE=0
    - SRIOV_EN=1
    - NUM_OF_VFS=46
    - LAG_RESOURCE_ALLOCATION=1
    - LINK_TYPE_P1=ETH
    - LINK_TYPE_P2=ETH
  ovs:
    rawConfigScript: |
      _ovs-vsctl() {
        ovs-vsctl --no-wait --timeout 15 "$@"
      }

      _ovs-vsctl set Open_vSwitch . other_config:doca-init=true
      _ovs-vsctl set Open_vSwitch . other_config:dpdk-max-memzones=50000
      _ovs-vsctl set Open_vSwitch . other_config:hw-offload=true
      _ovs-vsctl set Open_vSwitch . other_config:pmd-quiet-idle=true
      _ovs-vsctl set Open_vSwitch . other_config:max-idle=20000
      _ovs-vsctl set Open_vSwitch . other_config:max-revalidator=5000
      _ovs-vsctl set Open_vSwitch . other_config:ctl-pipe-size=1024
      _ovs-vsctl --if-exists del-br ovsbr1
      _ovs-vsctl --if-exists del-br ovsbr2
      _ovs-vsctl --may-exist add-br br-sfc
      _ovs-vsctl set bridge br-sfc datapath_type=netdev
      _ovs-vsctl set bridge br-sfc fail_mode=secure
      _ovs-vsctl --may-exist add-port br-sfc p0
      _ovs-vsctl set Interface p0 type=dpdk
      _ovs-vsctl set Interface p0 mtu_request=9216
      _ovs-vsctl set Port p0 external_ids:dpf-type=physical
      _ovs-vsctl --may-exist add-port br-sfc pf0hpf
      _ovs-vsctl set Interface pf0hpf type=dpdk
      _ovs-vsctl set

Interface pf0hpf mtu_request=9216

  tee "/etc/systemd/system/ovs-flows.service" > /dev/null <<'EOF'
  [Unit]
  Description=Add custom OVS flows for br-sfc
  After=openvswitch-switch.service
  Requires=openvswitch-switch.service

  [Service]
  Type=oneshot
  ExecStartPre=/bin/bash -c "until ovs-ofctl -t 60 show br-sfc >/dev/null 2>&1; do sleep 1; done"
  ExecStart=/bin/bash -c "ovs-ofctl add-flow br-sfc 'in_port=p0,actions=output:pf0hpf'; ovs-ofctl add-flow br-sfc 'in_port=pf0hpf,actions=output:p0'"
  RemainAfterExit=yes

  [Install]
  WantedBy=multi-user.target
  EOF
  systemctl daemon-reload
  systemctl enable --now ovs-flows.service

  cat <<EOT > /etc/netplan/99-dpf-comm-ch.yaml
  network:
    renderer: networkd
    version: 2
    ethernets:
      pf0vf0:
        mtu: 9000
        dhcp4: no
    bridges:
      br-comm-ch:
        dhcp4: yes
        interfaces:
          - pf0vf0
  EOT

bfcfgParameters:

  • UPDATE_ATF_UEFI=yes
  • UPDATE_DPU_OS=yes
  • WITH_NIC_FW_UPDATE=yes

configFiles:

  • path: /etc/mellanox/mlnx-bf.conf operation: override raw: | ALLOW_SHARED_RQ="no" IPSEC_FULL_OFFLOAD="no" ENABLE_ESWITCH_MULTIPORT="yes" permissions: "0644"
  • path: /etc/mellanox/mlnx-ovs.conf operation: override raw: | CREATE_OVS_BRIDGES="no" OVS_DOCA="yes" permissions: "0644"
  • path: /etc/mellanox/mlnx-sf.conf operation: override raw: "" permissions: "0644"

</code-snippet>

$ kubectl wait --for=condition=ready --namespace dpf-operator-system dpuserviceinterface p0 p1 pf0hpf pf1hpf dpuserviceinterface.svc.dpu.nvidia.com/p0 condition met dpuserviceinterface.svc.dpu.nvidia.com/p1 condition met dpuserviceinterface.svc.dpu.nvidia.com/pf0hpf condition met dpuserviceinterface.svc.dpu.nvidia.com/pf1hpf condition met

$ kubectl wait --for="jsonpath={.status.phase}=Ready" --namespace dpf-operator-system bfb bf-bundle-$TAG bfb.provisioning.dpu.nvidia.com/bf-bundle-v25.10.0 condition met

</code-snippet>
<p>
 <br>
</p>


</code-snippet>
<p>
 <br>
</p>


</code-snippet>
<p><span style="--color: var(--bold-gray, #172b4d);">&nbsp;</span>
 <br></p>