Single Point of Resource Distribution

This document describes the Single Point of Resource Distribution (SPRD) system, including the dpa-resource-mgmt tool, new Flex IO SDK APIs for consuming SPRD outputs, and the DPA Execution Unit (EU) management tool, dpaeumgmt.

DPA Flex IO applications may run simultaneously across multiple VHCAs, with multiple applications per VHCA. This can lead to contention for shared resources—such as Execution Units (EUs). Historically, applications independently allocated EUs based on general recommendations, which could result in performance degradation or even application crashes due to over-commitment.

To address this, the SPRD system provides a centralized infrastructure to orchestrate DPA resource allocation across applications. It is designed primarily for administrators managing DPUs in scalable environments and is managed using the dpa-resource-mgmt tool.

SPRD enables consistent resource planning at scale, for example, deploying the same configuration across a cluster of DPUs.

Key Characteristics

• Centralized EU resource management via dpa-resource-mgmt.

• Supports BlueField-3 and newer platforms.

• Operates over the dpaeumgmt EU management infrastructure.

• Host applications can reside on:

  • The BlueField Arm core (BF-ARM)

  • One or more external hosts (e.g., multi-host server configurations)

• Supports multiple instances of the same application running across different hosts.

• Non-SPRD-aware applications continue to run unaffected.

Integration Requirements

To fully adopt SPRD, the following updates are required:

• New APIs must be added to the FlexIO SDK.

• Existing tests and applications that use EU resources must be updated to consume allocations provided via the SPRD tool and APIs.

Glossary

This table introduces important terms necessary to understand this document:

To work with SPRD, ensure the following prerequisites are met:

System Requirements

To work with SPRD, the following requirements must be met:

• A functioning system with DOCA installed

• Python 3.6 or higher

• An NVIDIA® BlueField®-3 or newer device

• MFT package installed and running, version 4.32.0-94 or higher

• Firmware (FW) version XX.45.0322 or higher

• dpa-resource-mgmt package installed and running, version 25.04.160 or higher

EUs and Cores

The hardware consists of several cores, each containing a set number of EUs. Some EUs or entire cores may be reserved by the firmware and are therefore unavailable to both dpa-resource-mgmt and user applications.

Partition Concept

A partition is a logical, continuous array of EUs starting at index zero, with a fixed size. Partitions are assigned to one or more vHCAs, and only applications on those vHCAs can use the EUs in the assigned partition.

Partition types:

• Default partition (ROOT):

  • Created at boot on root devices (ECPF in DPU mode, PF in NIC mode)

  • Operates over all free EUs initially

  • Uses absolute EU indices

• Sub-partitions:

  • Created and deleted at runtime

  • Pull EUs from the default partition (which then loses access to them)

  • EUs in a sub-partition do not need to be contiguous, but must not overlap with other sub-partitions

  • Use relative EU indices starting from 0

When a sub-partition is deleted, its EUs are returned to the default partition.

Group Concept

A group is a firmware-managed list of EUs. When EU affinity is set to "group", the firmware selects an EU from the assigned group.

• The maximum number of groups per sub-partition is defined when the partition is created

• The default partition (ROOT) has its limit defined by the max_num_dpa_groups capability (currently 15)

• Every partition also has an implicit hidden group, used when EU affinity is set to none

The total number of groups allowed on a device must be ≤ max_num_dpa_groups (15), and is calculated as:

(1)

Where:

• P – number of sub-partitions (excluding the default)

• RG – number of groups in the default (ROOT) partition

• G_i – number of groups in each sub-partition i

dpa-resource-mgmt Utility

The primary tool provided by SPRD is dpa-resource-mgmt, a Python 3-based CLI utility used by system administrators to configure and manage DPA resource allocations. It interfaces with the lower-level dpaeumgmt utility to perform hardware-level execution unit (EU) operations.

This utility takes as input:

• The InfiniBand (ibv) device name

• A YAML configuration file describing partition and application layout

• An optional output path where generated application configuration files will be saved (defaults to current working directory)

Each output file corresponds to a defined partition and contains the required configuration for applications that will run within that partition.

Operating Modes

config – Configure Partitions and Generate Application Files

Creates partitions and EU groups as defined in the YAML file, and generates corresponding application configuration files.

Options:

            

            
-d, --device DEVICE        ibv device name (required)
-f, --filename FILENAME    YAML configuration file (required)
-o, --output OUTPUT        Output directory for generated files (optional; default: current path)
-v, --verbose              Print underlying dpaeumgmt commands (optional)
        

query – Query Resource Status

Displays resource-related information such as chip-level capabilities, vHCA data, or DPA resource allocation. Output can be directed to a file and formatted in YAML or human-readable format.

Options:

            

            
-d, --device DEVICE        ibv device name (required)
-t, --type {chip,vhca,resources}
                           Type of information to display (required)
-f, --filename FILENAME    Output file (optional; default: stdout)
-y, --yaml-format          Output in YAML format (optional; default: human-readable)
-v, --verbose              Show executed commands (optional)
        

clear – Clean Up Existing Configuration

Destroys all partitions and groups associated with the given device.

Options:

            

            
-d, --device DEVICE        ibv device name (required)
-v, --verbose              Show executed commands (optional)
        

version – Print Tool Version

Displays the currently installed version of dpa-resource-mgmt.

Back-end

The dpa-resource-mgmt utility operates by interfacing with the dpaeumgmt tool to interact directly with the hardware. It performs the following key functions:

• System discovery – Retrieves detailed hardware and topology information from the chip, including:

  • Number of cores

  • Number of available EUs

  • vHCA identifiers and their parent-child relationships

• Configuration parsing and validation:

  • Reads the YAML configuration file provided via the --filename option

  • Validates the structure and content of the file

  • If any issue is detected (e.g., syntax error, invalid partition configuration), the utility exits with a descriptive error message

• Pre-configuration checks:

  • Checks for existing active partitions, running processes, and configured EU groups

  • If such elements are found, the utility prompts the administrator to remove them manually, then exits without making changes

• Partition setup – If no conflicts are found, the utility proceeds to:

  • Create EU partitions

  • Configure EU groups

  • Generate partition-specific application configuration files, which are saved in the output directory (one file per partition)

This structured backend workflow ensures consistent and safe allocation of DPA resources across different applications and hosts.

Examples of Running dpa-resource-mgmt

Query VHCA Information

            

            
$ dpa-resource-mgmt query -t vhca -d mlx5_0
└── VHCA_ID = 0x1
    FUNCTION_TYPE = ECPF
    PCI_BDF = 80:00.0
    VPORT_ID = 0x0
        │
        ├── VHCA_ID = 0x2
        │   FUNCTION_TYPE = PF
        │   PCI_BDF = 80:00.1
        │   VPORT_ID = 0x0
        │
        ├── VHCA_ID = 0x3
        │   FUNCTION_TYPE = PF
        │   PCI_BDF = 80:00.2
        │   VPORT_ID = 0x0
        │
        ├── VHCA_ID = 0x4
        │   FUNCTION_TYPE = PF
        │   PCI_BDF = 80:00.3
        │   VPORT_ID = 0x0
        │
...
        

Query DPA Chip Information

            

            
$ dpa-resource-mgmt query -t chip -d mlx5_0
Maximal number of DPA EU per group (max_num_dpa_eu_per_group): 190
Maximal number of active DPA EU (max_num_dpa_eu): 190
Maximal number of DPA EU partitions (max_num_dpa_eu_partitions): 15
Maximal number of VHCAs associated with a single partition (max_num_partition_vhca_id): 16
Maximal number of EU groups could be created (max_num_dpa_groups): 15
Heap maximal size (heap_max_size): 1073741824
Maximal number of EU groups by FirmWare (max_eu_groups): 16
Maximal number of processes per VHCA (max_process_per_vhca): 64
Maximal number of DPA processes (max_processes): 64
Maximal number of DPA threads (max_threads): 40000
Maximal number of DPA threads per process (max_threads_per_process): 20000
Number of cores (num_cores): 12
DPA thread stack size (thread_stack_size): 16384
Cores:
    ├── Core ID 0
    │   EUs number 16
    │   EUs IDs 0-15
    │   EUs indexes 0-15
    │   
    ├── Core ID 1
    │   EUs number 16
    │   EUs IDs 16-31
    │   EUs indexes 0-15
    │   
    ├── Core ID 2
    │   EUs number 16
    │   EUs IDs 32-47
    │   EUs indexes 0-15
    │   
...
        

Query DPA Resource Information

            

            
$ dpa-resource-mgmt query -t resources -d mlx5_0
Free EUs in ROOT partition 0-3,9-15,30,31,40-47,67-79,112-159,169
Cores available for use in ROOT partition 0-2,4,7-9,14
Free EUs in ROOT partition with groups 0-3,9-15,30,31,40-47,67-79,112-159,162-189
Cores available for use ROOT partition with groups 0-2,4,7-9,14,15
│
├── PARTITIONS:
│   │
│   ├── PARTITION_1:
│   │   partition_id: 1
│   │   vhca_id: 5
│   │   Range of EUs: 4-8,16-29,32-39
│   │   Cores in use: 0-2
│   │   GROUPS:
│   │   │
│   │   ├── name: EU1
│   │   │   group_id: 1
│   │   │   abs_EUs: 16,17,20-22,32
│   │   │   Relative EUs: 5,6,9-11,19
│   │   │   Cores in use: 1,2
│   │   │
│   │   └── name: EU1_1
│   │       group_id: 2
│   │       abs_EUs: 26-28
│   │       Relative EUs: 26-28
│   │       Cores in use: 1
│   │
│   ├── PARTITION_2:
│   │   partition_id: 2
│   │   vhca_id: 2
│   │   Range of EUs: 48-66
│   │   Cores in use: 3,4
│   │   GROUPS:
│   │   │
│   │   └── name: EU2
│   │       group_id: 1
│   │       abs_EUs: 48-51,64
│   │       Relative EUs: 0-3,16
│   │       Cores in use: 3,4
│   │
│   └── PARTITION_3:
│       partition_id: 3
│       vhca_id: 3,4,9-13
│       Range of EUs: 80-111,160,161
│       Cores in use: 5,6,14
│       GROUPS:
│       │
│       └── name: EU3
│           group_id: 1
│           abs_EUs: 80-96
│           Relative EUs: 0-16
│           Cores in use: 5,6
│
└── ROOT_PARTITION_GROUPS:
    │
    ├── name: RG0
    │   group_id: 1
    │   abs_EUs: 170-189
    │   Cores in use: 14,15
    │
    └── name: RG1
        group_id: 2
        abs_EUs: 162-168
        Cores in use: 14
 
Core's information:
├── Core #0, with 16 EUs, has 11 EUs available: 0-3,9-15.
├── Core #1, with 16 EUs, has 2 EUs available: 30,31.
├── Core #2, with 16 EUs, has 8 EUs available: 40-47.
├── Core #3, with 16 EUs, is fully utilized.
├── Core #4, with 16 EUs, has 13 EUs available: 67-79.
├── Core #5, with 16 EUs, is fully utilized.
├── Core #6, with 16 EUs, is fully utilized.
├── Core #7, with 16 EUs, is fully available.
├── Core #8, with 16 EUs, is fully available.
├── Core #9, with 16 EUs, is fully available.
├── Core #14, with 16 EUs, has one EU available: 169.
└── Core #15, with 14 EUs, is fully utilized.
 
VHCA information:
    10 unutilized VHCAs: 6-8,14-20
        

Clear Previously Allocated Configuration

            

            
$ dpa-resource-mgmt clear -d mlx5_0
Successfully destroyed all partitions and groups.
        

Config

            

            
$ dpa-resource-mgmt config -f config.yaml -d mlx5_0 -v
sudo /opt/mellanox/doca/tools/dpaeumgmt version
sudo /opt/mellanox/doca/tools/dpaeumgmt info status --dpa_device mlx5_0
sudo /opt/mellanox/doca/tools/dpaeumgmt info vhca --dpa_device mlx5_0
sudo /opt/mellanox/doca/tools/dpaeumgmt info chip --dpa_device mlx5_0
sudo /opt/mellanox/doca/tools/dpaeumgmt partition info --dpa_device mlx5_0
sudo /opt/mellanox/doca/tools/dpaeumgmt eu_group info --dpa_device mlx5_0
sudo /opt/mellanox/doca/tools/dpaeumgmt partition create --dpa_device mlx5_0 --vhca_list 5 --range_eus 4-8,16-29,32-39 --max_num_eu_group 2
sudo /opt/mellanox/doca/tools/dpaeumgmt partition create --dpa_device mlx5_0 --vhca_list 2 --range_eus 48-66 --max_num_eu_group 1
sudo /opt/mellanox/doca/tools/dpaeumgmt partition create --dpa_device mlx5_0 --vhca_list 3,4,9-13 --range_eus 80-111,160,161 --max_num_eu_group 1
sudo /opt/mellanox/doca/tools/dpaeumgmt eu_group create --dpa_device mlx5_0 --range 5,6,9-11,19 --id_partition 1 --name_group EU1
sudo /opt/mellanox/doca/tools/dpaeumgmt eu_group create --dpa_device mlx5_0 --range 15-17 --id_partition 1 --name_group EU1_1
sudo /opt/mellanox/doca/tools/dpaeumgmt eu_group create --dpa_device mlx5_0 --range 0-3,16 --id_partition 2 --name_group EU2
sudo /opt/mellanox/doca/tools/dpaeumgmt eu_group create --dpa_device mlx5_0 --range 0-16 --id_partition 3 --name_group EU3
sudo /opt/mellanox/doca/tools/dpaeumgmt eu_group create --dpa_device mlx5_0 --range 170-188 --name_group RG0
sudo /opt/mellanox/doca/tools/dpaeumgmt eu_group create --dpa_device mlx5_0 --range 162-168 --name_group RG1
        

Format of Input YAML File

The input YAML file is divided into two main parts:

1. Partition definitions

2. Application definitions (not covered in this document)

These parts are separated by the standard YAML --- divider.

Partition Definitions

This section defines how execution units (EUs) are assigned to partitions and groups.

Example:

            

            
version: 25.04
 
partitions:
  PARTITION_1:
    vhca_id: 1
    EU_allocation:
      - abs_EUs: 4-8
      - core: 1
        num_EUs: 14
      - core: 2
        num_EUs: 8
    groups:
      - name: EU1
        EUs:
          - abs_EUs: 16,17,20-22
          - core: 2
            num_EUs: 1
      - name: EU1_1
        EUs:
          - abs_EUs: 26-28
 
  PARTITION_2:
    vhca_id: 2
    EU_allocation:
      - core: 3
        num_EUs: 16
      - core: 4
        num_EUs: 3
    groups:
      - name: EU2
        EUs:
          - core: 3
            num_EUs: 4
          - core: 4
            num_EUs: 1
 
  PARTITION_3:
    vhca_id: [3, 4, 9, 10-13]
    EU_allocation:
      - core: 5
        num_EUs: 16
      - core: 6
        num_EUs: 16
    groups:
      - name: EU3
        EUs:
          - core: 5
            num_EUs: 16
          - core: 6
            num_EUs: 1
 
root_partition_groups:
  - name: RG0
    EUs:
      - abs_EUs: 170-188
  - name: RG1
    EUs:
      - core: 10
        num_EUs: 7
        

Partition Configuration Schema (Input YAML Format)

            

            
version: "string"  # Version identifier (e.g., "25.04")
# REQUIRED: version must be defined
 
partitions:  # Defines different partitions such as ARM, HOSTx86, etc.
  # Can be an empty dictionary: {}
  "<partition_name>":  # Dynamic key, replace with actual partition names
    vhca_id:  # Virtual Host Channel Adapter (VHCA) ID
      one_of:
        - type: "integer"  # Single VHCA ID (e.g., 1, 2)
        - type: "array"    # Multiple VHCA IDs (e.g., [3, 4, 9, 10-13])
          items: "integer"
 
    EU_allocation:  # List of Execution Unit (EU) allocations
      # REQUIRED: EU_allocation must be defined
      - abs_EUs: "string"  # Absolute EU range, e.g., "4-8" or "16,17,20-22"
      - core: "integer"    # Core ID to which EUs are allocated
        num_EUs: "integer"  # Number of EUs allocated
 
    groups:  # Defines groups of EUs within each partition
      - name: "string"  # Name of the EU group (e.g., "EU1", "EU2")
        EUs:  # List of Execution Units assigned to the group. Should be either abs_EUs or core with num_EUs.
          # REQUIRED: EUs must be defined
          - abs_EUs: "string"  # Absolute EU assignments (e.g., "26-28")
          - core: "integer"    # Core ID for EU allocation
            num_EUs: "integer"  # Number of EUs assigned to the core
 
root_partition_groups:  # Defines global root partition groups
  - name: "string"  # Name of the root partition group (e.g., "RG0")
    # REQUIRED: name must be defined
    EUs:  # List of Execution Units assigned to the group. Should be either abs_EUs or core with num_EUs.
      # REQUIRED: EUs must be defined
      - abs_EUs: "string"  # Absolute EU assignments (e.g., "170-188")
      - core: "integer"    # Core ID for EU allocation
        num_EUs: "integer"  # Number of EUs assigned to the core
        

Schema Description

Notes on Field Behavior

abs_EUs vs. core/num_EUs

• Use abs_EUs for precise EU selection.

• Use core + num_EUs for abstracted allocation based on availability.

• Cannot combine both methods within a single mapping item.

Default Partition Behavior

• EUs not explicitly assigned to custom partitions remain in the default ROOT partition.

• The default partition is auto-created on boot and operates over unallocated EUs.

Partition Constraints

• Sub-partitions may not overlap in EU assignment.

• On sub-partition deletion, its EUs are returned to the ROOT partition.

• Each partition has its own relative EU indexing starting at 0.

Group Constraints

• The number of allowed groups is limited by the max_num_dpa_groups capability (currently 15).

• Hidden default groups are internally used for affinity mode none.

Application Definitions (YAML: DPA_APPS)

This section describes how applications are mapped to partitions and which execution units (EUs) or groups they use. EU values are defined in absolute terms for clarity but are converted to relative indices in output files.

Example:

            

            
DPA_APPS:
  APP1:
    - partition: PARTITION_1
      affinity_EUs: [35, 37-39]
      groups: [EU1, EU1_1]
      affinity_core:
        - core: 1
          num_EUs: 4
    - partition: PARTITION_2
      affinity_EUs: [61, 62]
      groups: EU2
    - partition: ROOT
      groups: RG0
      affinity_EUs: [190, 191]
      affinity_core:
        - core: 0
          num_EUs: 2
  APP2:
    - partition: PARTITION_1
      affinity_EUs: [63]
      groups: EU2
  APP3:
    partition: PARTITION_3
    affinity_EUs: [97, 99]
  APP4:
    partition: PARTITION_3
    affinity_EUs: 98
    groups: EU3
        

Application-to-Partition Mapping Schema (Input YAML Format)

            

            
DPA_APPS:  # List of applications with their partition mappings
  "<app_name>":  # Dynamic key, replace with actual application names (e.g., APP1, APP2)
    one_of:
      - type: array  # If an application has multiple partitions
        items:
          partition: "string"  # Name of the partition (e.g., "PARTITION_1", "PARTITION_2", "ROOT")
          # REQUIRED: partition must be defined
 
          affinity_cores:  # List of core/num_EUs pairs assigned to this app
            - core: "integer"
              num_EUs: "integer"
 
          affinity_EUs:  # List of Execution Units (EUs) assigned to this app
            one_of:
              - type: "array"  # List of EUs (e.g., [35, 37-39])
                items: integer
              - type: "integer"  # Single EU value (e.g., 98)
              - type: "string"  # Absolute EU range, e.g., "4-8" or "16,17,20-22"
 
          groups:  # Groups assigned to this app
            one_of:
              - type: array  # Multiple groups (e.g., ["EU1", "EU1_1"])
                items: string
              - type: string  # Single group (e.g., "EU2")
 
      - type: object  # If an application has only one partition
        properties:
          partition: "string"
          affinity_cores:
            - core: "integer"
              num_EUs: "integer"
          affinity_EUs:
            one_of:
              - type: array
                items: integer
              - type: integer
          groups:
            one_of:
              - type: array
                items: string
              - type: string
        

Schema Overview

Notes

affinity_EUs vs affinity_cores

Using affinity_cores is recommended when the partition itself uses core/num_EUs style allocation.

Mixing affinity_EUs with Groups

Although supported, it's not recommended to mix strict affinity_EUs with group-based allocation (groups). Doing so may introduce conflicts during EU assignment but is not prohibited.

Using the ROOT Partition

Apps may be assigned to the ROOT partition. In this case:

• You must reference one of the root_partition_groups.

• You may use affinity_EUs or affinity_core — but only with EUs/cores not already allocated by sub-partitions.

Known Limitation

dpa-resource-mgmt does not validate whether a vhca_id belongs to a root PF in NIC mode or a VF. Errors will only occur during backend validation (via dpaeumgmt).

Output YAML files

After a successful run of dpa-resource-mgmt, the tool generates a YAML file for each partition defined in the input file. Each output file is named after its corresponding partition (e.g., PARTITION_1.yaml) and contains the list of applications assigned to that partition, along with their resolved EU and group mappings.

Example Output YAML file

            

            
version: 25.04
DPA_APPS:
  - name: APP1
    number_of_groups: 2
    # EU1, EU1_1
    groups: [1, 2]
    # absolute EUs: [16, 17, 18, 19, 20, 21, 32, 33, 35, 37, 38, 39]
    number_of_affinity_EUs: 12
    affinity_EUs: [5, 6, 7, 8, 9, 10, 19, 20, 22, 24, 25, 26]
 
  - name: APP2
    # absolute EUs: [16, 17, 22, 23, 24, 25, 26, 27, 34, 36]
    number_of_affinity_EUs: 10
    affinity_EUs: [5, 6, 11, 12, 13, 14, 15, 16, 21, 23]
 
  - name: APP3
    # absolute EUs: [16, 18, 19, 20, 21, 28, 29, 32, 33]
    number_of_affinity_EUs: 9
    affinity_EUs: [5, 7, 8, 9, 10, 17, 18, 19, 20]
        

Format Reference

Format of output YAML file

            

            
version: "string"  # Version identifier (e.g., "25.04")
        # REQUIRED: version must be defined
 
DPA_APPS:  # List of applications with their attributes
  - name: "string"  # Name of the application (e.g., "APP3", "APP4")
         # REQUIRED: name must be defined
 
    #  (Optional) Number of affinity Execution Units (EUs) assigned to the application
    number_of_affinity_EUs: "integer"
 
    #  (Optional) List of affinity EU identifiers
    affinity_EUs:
      type: array
      items: integer  # Example: [17, 19] or [18]
 
    # (Optional) Number of groups assigned to the application
    number_of_groups: "integer"
 
    # (Optional) List of group identifiers
    groups:
      type: array
      items: integer  # Example: [1] (corresponds to "EU3" in the comment)
        

Key Behaviors

• Relative EU IDs – EUs are converted to partition-relative indices; this improves portability and compatibility across deployments

• Group Mapping – Group names from the input YAML are mapped to numeric indices; the mapping is shown as comments for traceability

• Partition Isolation – Each output file corresponds to a single partition, containing only the apps assigned to that partition

All operations are performed using dpa-resource-mgmt -d mlx5_X, where mlx5_X is the root device name.

Gather Application Requirements

The system administrator receives the following details from users and developers:

• A list of applications to be used

• A list of devices on which the applications will run

• Resource requirements for each application (e.g., number of EUs, group needs)

Map Devices to VHCAs

Run the following command to determine the mapping between devices and VHCAs using the pci_bdf field:

            

            
dpa-resource-mgmt -d mlx5_X query -t vhca
        

You can also run sudo mst status -v from the MFT package to obtain device details.

Inspect Core and EU Layout

Run the following command to retrieve chip-level information such as core counts, EU layout, and absolute EU IDs:

            

            
dpa-resource-mgmt -d mlx5_X query -t chip
        

Create Partition Configuration

Using the gathered data, create a YAML configuration file with the following:

• Partition definitions.

• EU allocation (either by core/num_EUs or absolute EU IDs).

• EU groups within partitions (optional).

• Root partition groups (optional).

Define Application Assignments

Add the application mapping section to the YAML configuration file, based on:

• Application names

• Resource requirements

• Target partitions and group assignments

Validate Configuration

Run the following command to validate the YAML configuration:

            

            
dpa-resource-mgmt -d mlx5_X config -f <config.yaml>
        

Handle Conflicts (If Any)

If the tool returns an error due to existing partitions, groups, or active processes:

1. Clear the existing configuration:

   Copy

   Copied!

               
   
               
   dpa-resource-mgmt -d mlx5_X clear
           

2. If clearing does not resolve the issue, perform a full chip reset

Review the Resulting Setup

Once configuration is successful, analyze the resulting setup:

            

            
dpa-resource-mgmt -d mlx5_X query -t resources
        

Use this step to verify if EU and group allocations are optimal.

Iterate (If Needed)

If changes are required, modify the YAML file and revalidate configuration.

Distribute Output Files

After finalizing the configuration:

• Retrieve the output YAML files generated by dpa-resource-mgmt

• Distribute these files to the respective hosts where applications will run

• Notify users and developers to begin using their assigned resources

Revise as Needed

If any issues arise or new requirements are introduced, repeat the process from the start.

To integrate SPRD with a host application, the typical workflow is:

1. Read a binary resource file generated by the dpa-resource-mgmt utility.

2. Pass the contents to flexio_resources_get() to populate a flexio_res structure.

3. Use the accessor functions to obtain execution unit (EU) or execution group (EUG) information.

4. Use this data to configure affinity for creating a flexio_event_handler.

5. After use, release the allocated structure using flexio_resources_destroy().

Core API Functions

Main Functions

• flexio_resources_get

  Copy

  Copied!

              
  
              
  /**
   * Read resources for a given key from an SPRD resource buffer.
   *
   * @param[in] key      Application name as defined in the SPRD YAML output.
   * @param[in] buf      Binary buffer from dpa-resource-mgmt output.
   * @param[in] buf_len  Buffer size in bytes.
   * @param[out] res     Output pointer to a populated flexio_res structure.
   *
   * @return flexio_status enum value.
   */
  flexio_status flexio_resources_get(const char *key, const void *buf, size_t buf_len,
                                     struct flexio_res **res);
          

• flexio_resources_destroy

  Copy

  Copied!

              
  
              
  /**
   * Free memory allocated for a flexio_res structure.
   *
   * @param[in] res  Pointer to the structure to destroy.
   *
   * @return flexio_status enum value.
   */
  flexio_status flexio_resources_destroy(struct flexio_res *res);
          

Accessor Functions

• Get application name:

  Copy

  Copied!

              
  
              
  /**
   * @brief Get application name from a Flex IO resources struct.
   *
   * This function gets the application name from a Flex IO resources struct.
   *
   * @param[in] res - A pointer to a Flex IO resources struct.
   *
   * @return application name.
   */
  FLEXIO_EXPERIMENTAL char *flexio_resources_get_app_name(struct flexio_resource *res);
          

• Number of execution groups:

  Copy

  Copied!

              
  
              
  /**
   * @brief Get number of execution groups from a Flex IO resources struct.
   *
   * This function gets the number of execution groups from a Flex IO resources struct.
   *
   * @param[in] res - A pointer to a Flex IO resources struct.
   *
   * @return number of execution groups.
   */
  FLEXIO_EXPERIMENTAL int flexio_resources_get_eugs_num(struct flexio_res *res);
          

• Execution group list:

  Copy

  Copied!

              
  
              
  /**
   * @brief Get execution unit groups list from a Flex IO resources struct.
   *
   * This function gets the execution unit groups list from a Flex IO resources struct.
   *
   * @param[in] res - A pointer to a Flex IO resources struct.
   *
   * @return execution unit groups list.
   */
  FLEXIO_EXPERIMENTAL uint32_t *flexio_resources_get_eugs(struct flexio_res *res);
          

• Number of execution units:

  Copy

  Copied!

              
  
              
  /**
   * @brief Get execution units number from a Flex IO resources struct.
   *
   * This function gets the execution units number from a Flex IO resources struct.
   *
   * @param[in] res - A pointer to a Flex IO resources struct.
   *
   * @return execution units number.
   */
  FLEXIO_EXPERIMENTAL int flexio_resources_get_eus_num(struct flexio_res *res);
          

• Execution unit list:

  Copy

  Copied!

              
  
              
  /**
   * @brief Get execution units list from a Flex IO resources struct.
   *
   * This function gets the execution units list from a Flex IO resources struct.
   *
   * @param[in] res - A pointer to a Flex IO resources struct.
   *
   * @return execution units list.
   */
  FLEXIO_EXPERIMENTAL uint32_t *flexio_resources_get_eus(struct flexio_res *res);
          

Example of Using EU Resources

            

            
file = fopen(filename, "rb");
if (!file) {
        printf("Cannot open file!n");
        return ERROR;
}
 
fseek(file, 0, SEEK_END);
buf_len = ftell(file);
if (buf_len == 0) {
        printf("Empty file!\n");
        return ERROR;
}
fseek(file, 0, SEEK_SET);
 
buf = calloc(sizeof(char), buf_len);
if (!buf) {
        printf("Cannot allocate\n");
        return ERROR;
}
 
if (buf_len != fread(buf, sizeof(char), buf_len, file)) {
        printf("Incorrect read\n");
        return ERROR;
}
 
fclose(file);
 
/* ...............  */
 
ret = flexio_resources_get(key, buf, buf_len, &resourses);
 
if (ret != FLEXIO_STATUS_SUCCESS) {
        printf("Failed to read resources for key %s\n", key);
        return ERROR;
}
 
free(buf);
 
/* ...............  */
 
attr.affinity.type = FLEXIO_AFFINITY_GROUP;
attr.affinity.id = flexio_resourses_get_eugs(resourses)[0];
ret = flexio_event_handler_create(process, &attr, &eug_handle_id);
if (ret != FLEXIO_STATUS_SUCCESS) {
        printf("Failed to create event_handler");
        return ERROR;
}
 
attr.affinity.type = FLEXIO_AFFINITY_STRICT;
attr.affinity.id = flexio_resourses_get_eus(resourses)[0];
ret = flexio_event_handler_create(process, &attr, &eu_handle_id);
if (ret != FLEXIO_STATUS_SUCCESS) {
        printf("Failed to create event_handler");
        return ERROR;
}
 
/* ...............  */
 
ret = flexio_resources_destroy(resources);
if (ret != FLEXIO_STATUS_SUCCESS) {
        printf("Failed to free resources");
        return ERROR;
}
        

The dpaeumgmt tool enables management of DPA Execution Units (EUs), the fundamental compute resource of the Data Path Accelerator (DPA). It can run either on the host or on a target DPU and provides control over EU allocation, ensuring optimal resource distribution before using the DOCA FlexIO SDK API.

Without explicit EU allocation, a DPA software thread cannot execute, as it would lack access to pipeline or compute time resources.

Key use cases:

• Strict affinity execution – Run a DPA thread on a specifically assigned EU. dpaeumgmt can query the highest allowed EU ID for this purpose.

• Group Affinity Execution – Define EU groups. Once a group is created and assigned a unique ID, DPA threads can use group affinity to select an available EU from within the group.

• EU Partition Management – Manage EU partitions to logically separate compute resources across different virtual host channel adapters (VHCAs).

Execution Unit Objects

At system boot, a default EU partition is automatically created. This partition initially owns all system EUs and is managed exclusively by the DPA partition manager function.

• When a DPA thread runs with none affinity, an EU is selected from the default partition’s pool—excluding any EUs already allocated to groups.

• If no free EUs remain in the default pool, the thread fails to run.

dpaeumgmt CLI Reference

General Commands

EU Group Commands

EU Partition Commands

Info Commands

Common Flags and Options

vHCAs and Partitions

The following diagram illustrates the ownership and control of a partition by a vHCA and also which vHCAs have claim to (i.e., can use) a partition.

Known Limitations of dpaeumgmt