Customer Affecting Changes

DOCA Flow 3.1.0

Conflicting L3 and L4 types aren't allowed in RSS configuration.

Users should create RSS with flags that contain either IPv4 layer flags, IPv6 layer flags or neither, but not both. Likewise with TCP and UDP flags.

Enhanced VNF hairpin approach

• DOCA Flow configures the hairpin internally, so users should remove the existing code of hairpin queues creation through DPDK in the App.

• After the Ports are paired, the users can configure forward to the paired Port (to send the packet out directly) or to the paired Port’s Egress root Pipe.

• The doca_flow_port_pair is unidirectional now, means when port X is paired with port Y , only port X forward to port Y is allowed. Port is automatically self paired after the Port start.

Command line interface updates for DOCA Flow reference programs

The command line interface (CLI) for DOCA Flow reference programs (samples & applications) was updated. An extensive description of the new commands is detailed in the respective user guides.

Removed "mark" field from struct doca_flow_metato simplify the DOCA Flow API

Users using the set mark action must move to a different metadata field .

• Moved "mark" field in CT struct doca_flow_ct_meta::meta to doca_flow_ct_meta. Users using CT to set the mark must change their code accordingly.

Removed the flow direction to simplify DOCA Flow API

Users no longer need to specify the direction for their pipes.

The following API was removed:

            

            
enum doca_flow_direction_info {
    DOCA_FLOW_DIRECTION_BIDIRECTIONAL = 0,
    DOCA_FLOW_DIRECTION_NETWORK_TO_HOST,
    DOCA_FLOW_DIRECTION_HOST_TO_NETWORK,
};
 
doca_error_t doca_flow_pipe_cfg_set_dir_info(struct doca_flow_pipe_cfg *cfg, enum doca_flow_direction_info dir_info);
        

DOCA-Host 3.1.0

DOCA-OFED profile

Deprecation of openvswitch component, and replacing it with doca-openvswitch component. The content and supported features are the same, yet customer using openvswitch component will need to re-build with the new package new doca-openvswitch.

Shared RO

The Shared RO feature has been replaced by the "memory consumption reduction for representors" feature. As a result:

• The esw_pet_insert devlink parameter is no longer available.

• Setting ALLOW_SHARED_RQ in /etc/mellanox/mlnx-bf.conf will have no effect.

DOCA-Flow 3.2 (Oct 2025)

Deprecating DOCA_FLOW_SHARED_RESOURCE_MIRROR type with the correlated struct doca_flow_resource_mirror_cfg.

The same functionality can be achieved by DOCA_FLOW_PIPE_HASH pipe type with DOCA_FLOW_PIPE_HASH_MAP_ALGORITHM_FLOODING, starting from DOCA-Flow 3.1 (Jul 2025).

Action: Users must deprecate the following experimental APIs:

            

            
doca_error_t doca_flow_cfg_set_default_rss(struct doca_flow_cfg *cfg, const struct doca_flow_resource_rss_cfg *rss);
doca_error_t doca_flow_port_cfg_set_rss_cfg(struct doca_flow_port_cfg *cfg, const struct doca_flow_resource_rss_cfg *rss_cfg);
        

To strengthen the security of DPA-based applications, NVIDIA introduces the concept of DPA application attributes. Developers must create a dpa-app-attributes file for each application and compile it alongside the application to explicitly declare the app’s permissions.

Action: When updating the BF-Bundle (or firmware on ConnectX devices), users must also update the DOCA Host components included in the release. As part of this update, each DPA application must be rebuilt with its corresponding dpa-app-attributes file.

If the user does not supply a dpa-app-attributes file, a default manifest with all permissions enabled will be applied automatically.

Undocumented and deprecated DPA/FlexIO APIs will be removed.

Action: Users who used those APIs must remove them from their code and re-build their application.

DOCA-Host 3.2 (Oct 2025)

Deprecating phy counters:

            

            
# cat /sys/class/net/<interface_name>/phy_stats/
rx_bytes
rx_packets
tx_bytes
tx_packets
        

And replacing them with:

            

            
# ethtool -S <interface_name> | egrep 'packets_phy|bytes_phy'
     tx_packets_phy: 
     rx_packets_phy: 
     tx_bytes_phy: 
     rx_bytes_phy:
        

Deprecating has_smi sysfs:

            

            
# cat /sys/class/infiniband/mlx5_0/ports/1/has_smi
        

And replacing it with ib_stat.

The customer is advised to parse it as follow:

• Capability mask: <capability_mask_value>

• Bit #1 IsSM

• Bit #10 IsSMdisabled

Deprecating sysfs set/show hfunc:

            

            
# cat /sys/class/net/<interface_name>/settings/hfunc 
Operational hfunc: toeplitz
Supported hfuncs: xor toeplitz
        

And replacing it with:

            

            
# ethtool -x|--show-rxfh-indir|--show-rxfh devname
        

And:

            

            
# echo [hfunc]  > /sys/class/net/<interface_name>/settings/hfunc 
# ethtool -X|--set-rxfh-indir|--rxfh devname [hfunc FUNC]
        

Deprecating pfc_stall_prevention:

            

            
# cat /sys/class/net/<interface_name>/settings/pfc_stall_prevention 
default
        

and replacing it with:

            

            
# ethtool --get-tunable <interface_name> pfc-prevention-tout
pfc-prevention-tout: <value>
        

And:

            

            
# echo [default/auto] > /sys/class/net/<interface_name>/settings/pfc_stall_prevention
        

Where:

• "default" is mapped to 8000 msec per critical prevention

• "auto" is mapped to 100 msec per critical prevention

With:

            

            
# ethtool -X | --set-tunable devname [rx-copybreak N] [tx-copybreak N] [tx-buf-size N] [pfc-prevention-tout N
        

Deprecating sysfs which displays VF statistics by VF:

            

            
# cat /sys/class/infiniband/mlx5_2/device/sriov/2/stats
        

The user is advised to use:

            

            
# /opt/mellanox/iproute2/sbin/ip -s link show dev <VF interface name>
        

VGT+ capability will no longer be supported as of October 2025.

"Per Channel Statistics" ethtool private-flag will no longer be supported as of October 2025.

Deprecation of commands_cache sysfs.

DKMS (Dynamic Kernel Module Support) capability integration - DKMS allows customers to build DOCA-Host packages on their own. as part of the DKMS build the signing of the drivers is removed and the customer will need to sign the drivers on their own.

Deprecation the mlxdevm tool (part of DOCA-Host) - use only DevLink that is already included in DOCA-Host (mlxdevm is redundant with the exact same functionality as Devlink)

October 2025 (32.47.1xxx)

Starting with the October 2025 firmware release, and for all subsequent versions, compatibility with the older MFT releases (4.31.0-149 and 4.30.0-139) is no longer supported.

DOCA-Host 3.3.0 (Jan 2026)

Starting with DOCA-Host 3.3.0 (January 2026), the use of SYSFS for configuring the MR cache will be deprecated and will be replaced by the "rdma" resource command. Any users or scripts relying on this SYSFS interface will need to be updated to use the new API.

DOCA 3.3 (Jan 2026)

Deprecating DPDK based HW acceleration in openvswitch & doca-openvswitch (a.k.a. DPDK NETDEV DPIF / OVS-DPDK).

Starting with DOCA 3.3.0 (January 2026), we will be retiring the current hardware acceleration method based on DPDK NETDEV DPIF (also known as OVS-DPDK) in our openvswitch packages.

Customers who use this mode (OVS-DPDK) should either transition to DOCA-DPIF (recommended), or maintain their setup with DOCA 3.2 LTS (Maintenance Mode).

This change affects the followings:

- doca-openvswitch .rpm/.deb in BF-Bundle (BFB) and DOCA-Networking and DOCA-All Host Profiles

- openvswitch .rpm/.deb in DOCA-OFED Host profile

DOCA 3.3 (Jan 2026)

MLNX DPDK end-of-life (EOL) and transition to upstream DPDK.

Starting with DOCA 3.3.0 (January 2026), DOCA packages that previously included MLNX_DPDK will transition to using the upstream DPDK, specifically the community LTS version 25.11.

This change will apply to the DOCA-HOST (Networking/All) and BF-Budnle (BFB) packages, supporting both ConnectX and BlueField adapters. It will enable DPDK users to take advantage of the latest community driven

features and improvements, with no expected loss of functionality, as all existing MLNX_DPDK capabilities will be included in the upstream version.

DOCA 3.2 would be the final LTS release that includes MLNX_DPDK_22.11_xx (scheduled for Oct’25).

DOCA-HOST 3.0.0 (April 2025)

mlxdevm tool

The mlxdevm tool is now aligned with devlink v6.12 where zero rate values indicate "unlimited" and are omitted from the port function rate display. As a result, when using mlxdevm port function rate show, tx_rate and tx_max will be omitted if their values are zero. Additionally, the driver accepts only tx_rate and tx_max values that are multiples of 1 megabit per second.

The mlxdevm tool is now aligned with devlink v6.12 and conforms to the specifications in the man page.

• The correct format for setting the port function rate is:port function rate set [DEV/PORT_INDEX | DEV/NODE_NAME] tx_max VALUE

  • DEV/PORT_INDEX refers to a devlink leaf rate object

  • DEV/NODE_NAME refers to a devlink node rate object

  • VALUE is a numeric value that may include an optional prefix (none, k, m, g, t) and unit (bps or bit). Examples: 7Gbit, 7000Mbit, 7000000000. The value is case-insensitive (bps and Bps are equivalent), and if no prefix is specified, the default unit is bits per second.

• The correct format for showing the port function rate is: mlxdevm port function rate show [DEV/PORT_INDEX | DEV/NODE_NAME]

  • The [DEV/PORT_INDEX | DEV/NODE_NAME] parameter is optional. If provided, the command displays rate information for the specified rate object. If omitted, it lists all available rate objects.

DOCA-HOST 2.10.0 (Jan 2025)

When Dynamic Interrupt Moderation (DIM) is enabled, static coalescing parameters cannot be set, as their values will be overridden by the dynamic algorithm.

Disable Dynamic Interrupt Moderation (DIM) to set the coalescing parameters.

ConnectX-4 adapter cards family is no longer supported.

N/A

Removed support for the following OSes:

• RHEL8.0

• RHEL8.1

• RHEL8.3

• RHEL8.5

• RHEL8.7

• RHEL9.1

• RHEL9.3

• OL 7.9

N/A

DOCA-FLOW 2.10.0

The following features are NOT supported in DOCA 2.10 release (The features would be supported in DOCA 3.0 April/25 release):

ACL pipe, LPM pipe, CT pipe, ordered_list pipe, external send queue (SQ), pipe resize

Users can not use these DOCA Flow features. For applications that require this functionality, please use DOCA FLOW 2.9.1

Removed the need to use a dummy_id in IPsec encryption action during pipe creation.

When creating a pipe with crypto action, UINT32_MAX will represent a changeable shared object. Otherwise, 0<crypto_id<UINT32_MAX will indicate a constant. No use of dummy_id.

The memory for modify field and encap actions needs to be allocated upfront per port

The doca_flow_port_cfg_set_actions_mem_size() function must be called to configure the size in case these actions are needed. The recommended initial memory size to provide can be calculated by: num_of_entries * DOCA_FLOW_MAX_ENTRY_ACTIONS_MEM_SIZE. This can be tuned later to achieve better memory consumption.

Strict matching is no longer supported

The doca_flow_pipe_cfg_set_enable_strict_matching() function is deprecated.

Setting enable_strict_matching to true in doca_flow_pipe_cfg_set_enable_strict_matching() is not supported anymore

Users need to do relaxed matching. More details and usage examples can be seen in section DOCA Flow>Relaxed Match.

The aging mechanism no longer relies on DPDK, thus the DPDK arg service_core=<num cores>, svc_cycle_time=<cycle time> are no longer supported

Users should use the following new API instead:

• doca_flow_port_cfg_set_service_threads_core() API to set the core number used for counter service

• doca_flow_port_cfg_set_service_threads_interval() API to set the counter service cycle interval

The doca_flow_parser_meta.random field is changed to big-endian

Users should update it to big-endian. The recommended way is to use DOCA_HTOBE16 for that.

Refactored RSS config API to adhere to other resource types

Users have to specify whether the RSS is shared or non-shared.

Usage examples can be found in various samples (e.g., flow_switch_rss_sample).

Enumeration values were changed

Users need to recompile the app lication since the following enums values were changed:

• enum doca_flow_l2_meta

• enum doca_flow_meter_color

DOCA Flow Tune is at Alpha level, and switch visualization is not supported

N/A

Match fields parser_meta.outer_l4_ok and parser_meta.inner_l4_ok no longer check that the L4 checksum is valid

User needs to use parser_meta.outer_l4_checksum_ok and parser_meta.inner_l4_checksum_ok to check if checksum is valid

Before 2.10.0: During DOCA Flow initialization, the programs register a callback for processing important "life events" in the cycle of the entry. This callback is invoked upon "entry add" and "entry removal".

Starting 2.10.0: The callback is also invoked also upon "port stop" during the removal of pipe entries. Thus, user context should be still defined.

DOCA-ETH 2.10.0

The following samples are NOT supported: eth_rxq_managed_mempool_receive and eth_rxq_regular_receive

Users can not use these DOCA samples. If these are needed, please use DOCA FLOW 2.9.1

DOCA 2.9.0 (Oct 2024)

DPA Outbox Blocking-Mode

Due to a silicon issue, as of firmware version 28.43.2026, the DPA outbox is configured to operate in non-blocking mode, causing DPA outbox requests to complete immediately without waiting for actual completion. As a result, the DPA stack must poll a "busy" bit before initiating another DPA outbox operation.

Update the firmware version to 28.43.2026 or higher or update the BF-Bundle (containing this firmware) and DOCA-Host to 2.9.x or higher.

This is mandatory for customers programming the DPA (e.g., DPA with DOCA PCC, or using NVIDIA turn-key apps which utilize the DPA (virtio-net/blk/fs, NVMe).

DPA Thread Context

Due to internal-stack API changes, as of firmware v28.43.2026, DPA thread context is changed in the DPA. This affects the overlying DPA stack.

As of firmware version 28.43.2026, internal-stack API changes have altered the DPA thread context, impacting the overlying DPA stack.