On This Page
This guide provides an overview and configuration instructions for DOCA Programmable Congestion Control (PCC) API.
The DOCA PCC library provides a high-level programming interface that allows users to implement their own customized congestion control (CC) algorithm.
The DOCA PCC library provides an API to:
Get the CC event/packet and access its fields.
Set a rate limit for a flow.
Maintain a context for each flow.
Initiate and configure CC algorithms.
This library uses the NVIDIA® BlueField®-3 DPU hardware acceleration for CC management, while providing an API that simplifies hardware complexity, allowing users to focus on the functionality of the CC algorithm.
DOCA PCC-based applications can run either on the host machine or on the NVIDIA® BlueField®-3 (or later) target DPU.
To enable PCC:
Run the following on the host/VM:
mlxconfig -d <mlx_device> -y s USER_PROGRAMMABLE_CC=
Power cycle the host.
The DPACC tool is used to compile and link user algorithm and device code with the DOCA PCC device library to get applications that can be loaded from the host program .
DPACC is bundled as part of the DOCA SDK installation package. For more information on DPACC, refer to NVIDIA DOCA DPACC Compiler.
DOCA PCC is composed of two libraries which are part of the DOCA SDK installation package :
Host/DPU library and header files
Device library and header files
Currently, the device library and the user algorithm are implemented and managed over the BlueField's data-path accelerator (DPA) subsystem.
For more info on DPA, refer to DPA Subsystem.
DOCA enables developers to program the congestion control algorithm into the system using the DOCA PCC library.
The following are the required steps to start programming:
(Optional) Implement CC algorithms using the API provided by the device header files to be run by the library.
Implement the following calls defined by the library: doca_pcc_dev_user_init(), doca_pcc_dev_user_set_algo_params(), doca_pcc_dev_user_algo().
Use DPACC to build a DPA program (i.e., a host library which contains an embedded device executable). Input for DPACC are the files containing the implementation of the previous steps.
Build host executable using a host compiler. Inputs for the host compiler are the DPA program generated in the previous step and the user application source files.
In the host executable, create and start a DOCA PCC context which is set with the DPA program containing the device code.
For a more descriptive example, refer to NVIDIA DOCA PCC Application Guide.
The library requires firmware version 32.38.1000 and higher.
For the library API reference, refer to PCC API documentation in the NVIDIA DOCA Library APIs.
The following sections provide additional details about the library API.
The host library API consists of calls to set the PCC context attributes and observe availability of the process.
To perform PCC operations, a device must be selected. To select a device, users may iterate over all DOCA devices using doca_devinfo_list_create() and check whether the device supports PCC using doca_devinfo_get_is_pcc_supported() .
After selecting a DOCA device, a PCC context can be created using doca_pcc_create().
Afterwards, the following attributes must be set for the PCC context:
Context app – the name of the DPA program compiled using DPACC, consisting of the device algorithm and code. This is set using the call doca_pcc_set_app().
Context threads – the affinity of DPA threads to be used to handle CC events. This is set using the call doca_pcc_set_thread_affinity(). The number of threads to be used must be constrained between the minimum and maximum number of threads allowed to run the PCC process (see doca_pcc_get_min_num_threads()and doca_pcc_get_max_num_threads()). The availability and usage of the threads for PCC is dependent on the complexity of the CC algorithm, link rate, and other potential DPA users.Warning
Users can manage DPA threads in the system using EU pre-configuration with the dpaeumgmt tool. For more information, refer to NVIDIA DOCA DPA Execution Unit Management Tool.
After setting up the context attributes, the context can be started using doca_pcc_start(). Starting the context initiates the CC algorithm supplied by the user.
The DOCA PCC library provides a set of debugging APIs to allow the user to diagnose and troubleshoot any issues on the device, as well as accessing real-time information from the running application:
doca_pcc_set_dev_coredump_file() – API to set a filename to write crash data and core dump into should a fatal error occur on the device side of the application. The data written into the file would include a memory snapshot at the time of the crash, which would contain information instrumental in pinpointing the cause of a crash (e.g., the program's state, variable values, and the call stack).
doca_pcc_set_trace_message() – API to enable tracing on the device side of the application by setting trace message formats that can be printed from the device. The tracer provided by the library is of high-frequency and is designed to not have significant impact on the application's performance. This API can help the user to monitor and gain insight into the behavior of the running device algorithm, identify performance bottlenecks, and diagnose issues, w ithout incurring any notable performance degradation.
doca_pcc_set_print_buffer_size() – API to set the buffer size to be printed by the print API provided by the device library.
The DOCA PCC library provides a set of APIs for sending and receiving messages through a mailbox. This service allows communication between the host and device :
doca_pcc_set_mailbox() – API to set the mailbox attributes for the process .
doca_pcc_mailbox_get_request_buffer() and doca_pcc_mailbox_get_response_buffer() – API to get the buffers with which the communication will be handled . User can set the request he wants to send to the device, and get a response back.
doca_pcc_mailbox_send() – API to send the mailbox request to the device. This is a blocking call which invokes a callback on the device doca_pcc_dev_user_mailbox_handle() which user can handle.
The DOCA PCC library provides high availability, allowing fast recovery should the running PCC process malfunction. High availability can be achieved by running multiple PCC processes in parallel.
When calling doca_pcc_start(), the library registers the process with the BlueField firmware such that the first PCC process to be registered becomes the ACTIVE PCC process (i.e., actually runs on DPA and handles CC events).
The other processes operate in STANDBY mode. If the ACTIVE process stops processing events or hits an error, the firmware replaces it with one of the standby processes, making it ACTIVE.
The defunct process should call doca_pcc_destroy() to free its resources.
The state of the process may be observed periodically using doca_pcc_get_process_state(). A change in the state of the process returns the call doca_pcc_wait().
The following values describe the state of the PCC process at any point:
DOCA_PCC_PS_ACTIVE = 0,
/**< The process handles CC events (only one process is active at a given time) */
DOCA_PCC_PS_STANDBY = 1,
/**< The process is in standby mode (another process is already ACTIVE)*/
DOCA_PCC_PS_DEACTIVATED = 2,
/**< The process was deactivated by NIC FW and should be destroyed */
DOCA_PCC_PS_ERROR = 3,
/**< The process is in error state and should be destroyed */
The device library API consists of calls to setup the CC algorithm to handle CC events arriving on hardware.
The device library API provides a set of functions to initiate and and identify the different CC algorithms.
The DOCA PCC library is designed to support more than one PCC algorithm. The library comes with a default algorithm which can be used fully or partially by the user using doca_pcc_dev_default_internal_algo() , alongside other CC algorithms supplied by the user . This can be useful for fast comparative runs between the different algorithms. Each algorithm can run on a different device port using doca_pcc_dev_init_algo_slot() .
The algorithm can supply its own identifier, initiate its parameter (using doca_pcc_dev_algo_init_param()), counter (using doca_pcc_dev_algo_init_counter()), and metadata base (using doca_pcc_dev_algo_init_metadata()).
The device library API provides a set of optimized CC event access functions. These functions serve as helpers to build the CC algorithm and to provide runtime data to analyze and inspect CC events arriving on hardware.
The device library API provides a set of optimized utility macros that are set to support programming the CC algorithm. Such utilities are composed of fixed point operations, memory space fences, and more.
The device library API consists of specific user callbacks used by the library to initiate and run the CC algorithm. These callbacks must be implemented by the user and, to be part of the DPA program, compiled by DPACC to provide to the DOCA PCC context.
The set of callbacks to be implemented is as follows:
doca_pcc_dev_user_init() – this is called on PCC process load and should initialize the data of all user algorithms.
doca_pcc_dev_user_algo() – entry point to the user algorithm handling code.
doca_pcc_dev_user_set_algo_params() – called when the parameter change is set externally.
The device library API provides an API to sample the network interface controller (NIC) bytes counters. These counters help monitor the amount of data transmitted and received through the NIC.
The user can prepare the list of counters to read using doca_pcc_dev_nic_counters_config() and sample the new counters values with the call doca_pcc_dev_nic_counters_sample() .