Developing a Conformant DPF System

Independent software vendors (ISVs) can integrate DOCA Platform Foundation (DPF). Integration may involve modifying or replacing dependencies and components used in the upstream version of DPF.

The below details the system highlighting which components can be changed in integration.

The DPF Operator has a number of dependencies which can be swapped out during integration in favor of solutions managed by the integrator. Replacing some of these components may require additional modification - i.e. certificate management with a tool other than cert manager may require changes to the deployments.

Today the following are either mentioned in the installation guide or installed as dependencies from the DPF Operator helm chart.

• certificate management using cert-manager

• storage provisioning using NFS and local-path provisioner

• NVIDIA Network Operator

• SR-IOV Network Operator

• NVIDIA Node maintenance operator.

DPF relies on each worker node having a specific networking configuration. In this configuration the worker node management interface is plugged into a bridge called br-dpu. Virtual functions from the BlueField DPU are added to the same bridge.

This networking pattern must be implemented when integrating DPF. There is no component in DPF which configures this. For more information on the implementation details see the host networking prerequisites.

Manage the lifecycle of the DPU hardware and its Kubernetes orchestration system.

The following components are used in upstream DPF and can be modified or replaced during integration:

• DPU Cluster manager- highlighted in orange - can be replaced in full in integration.

• Kamaji controller - a dependency of the DPUCluster manager - can be replaced.

• BF.cfg - a configuration file used when configuring the DPU.

For more information on implementing a DPUCluster manager see the DPUCluster documentation.

Custom bf.cfg

By default DPF will use a bf.cfg - the Bluefield configuration file - that is tied to the default BFB. If the BFB is replaced during integration it may also be required to replace the bf.cfg.

The DPU controller in the provisioning controller manager uses a template to render the bfb.cfg with values supplied by the user-supplied DPUFlavor. The default bf.cfg.template for v25.1 is here. The template takes the form of a go template. The values used to render it are supplied to it are described in this package.

To supply a custom bf.cfg template:

1) Create a ConfigMap with the following format in the target cluster:

            

            
apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-bfb.cfg
  namespace: dpf-operator-system # Must be in the same namespace as the DPFOperator.
data:
    BF_CFG_TEMPLATE: | # This key must be in the ConfigMap.
        {{.KubeadmJoinCMD}}
        

2) Configure the provisioning controller to use the custom bf.cfg.template through the DPFOperatorConfig.

            

            
apiVersion: operator.dpu.nvidia.com/v1alpha1
kind: DPFOperatorConfig
metadata:
  name: dpfoperatorconfig
  namespace: dpf-operator-system
spec:
  provisioningController:
    bfbPVCName: "bfb-pvc"
    bfCFGTemplateConfigMap: custom-bfb.cfg
...
        

This example template contains only one variable and misses many important configuration steps. It is not sufficient to provision a DPU in DPF. To understand how to write a custom bf.cfg.template the default template serves as the best example.

Orchestrate DOCA Services to run on DPUs.

The following components are used in upstream DPF and can be modified or replaced during integration:

• ArgoCD - a dependency of the DPUService controller manager can be replaced with a managed version of ArgoCD

Orchestrate Service Chains for advanced network flows through DPUs.

None of the components used in Service chain orchestration should be replaced during integration.