NVIDIA Docs Hub NVIDIA Networking Networking Software Adapter Software NVIDIA DPDK Documentation MLNX_DPDK_22.11_2310.5.1 LTS Changes and New Features History

Changes and New Features History

Feature/Change	Description
Rev. MLNX_DPDK_22.11_2310.4.1
General	Updated firmware and MLNX_OFED versions. See Release Notes.
Rev. MLNX_DPDK 22.11_2310.3.0
General	Updated firmware and MLNX_OFED versions. See Release Notes.
Rev. MLNX_DPDK_22.11_2310.1.0
Extended Support for SEND_TO_KERNEL Action	`RTE_FLOW_ACTION_TYPE_SEND_TO_KERNEL` action is extended to support both NIC Tx and FDB domains on top of the existing NIC Rx. The extension is added in the template API, as a parity of that in the non-template flow API. For further information, see Packet Re-Routing to the Kernel.
Enhanced Hairpin Port Re-Configuration	In previous release, when hairpin queues were bound between two separate ports, reconfiguring one of the ports required stopping both. Simply restarting a single port was insufficient, and this resulted in the hairpin functionality not functioning. With this newly introduced feature enhancement, we enable reconfiguration of one of the paired ports without the necessity of stopping both. This provides greater flexibility for port to reconfiguration when using cross-ports hairpin. This capability is controlled through the `hp_rebind` device argument. Setting it to a non-zero value indicates that the application will enable this functionality when probing a device. For further information on the devargs limitation, see “doc/guides/nics/mlx5.rst”.
Hairpin Mesh Testing	When using ConnectX-7 adapter cards with 4 ports or 2 ports with split-cable, dpdk-testpmd can now support a complex mesh configuration of hairpin among all ports but not only between the 2 ports nearby. This new functionality will allow the user to easily verify the hairpin functionality before implementing the configuration in the application. For further information, see Hairpin Mesh Configuration and Testing.
Set Group Miss Actions Support	Added support for explicitly configuring flow actions executed on packets which do not match on any flow rule in a flow group. All missed packets will execute the preset action(s) controlled by the application instead of the unpredictable ones from the lower layers. Configuration can be done through the `rte_flow_group_set_miss_actions()` API. Note: This feature is currently supported for template API users. For further information of its usage, see “Group Miss Actions” section in https://doc.dpdk.org/guides/prog_guide/rte_flow.html.
SRv6 Push/Remove Actions Support (a.k.a Inline mode Encapsulation/Decapsulation)	Added support for pushing/removing IPv6 extension header into/from the original IPv6 packets directly. This method is more efficient than using tunnel encap/decap (e.g. VxLAN) with SRv6 in the outer header. Note: The maximal pushing length should be <= 128B (overall headers length). The application should make sure that the SRv6 is the only present extension header after pushing (no fragmentation either). Only TCP and UDP protocols are supported in L4 now. To generate the correct checksum after pushing, the application should set IPv6 Hardware requirements: REMOVE action: ConnectX-6 Dx and above PUSH action: ConnectX-7 and above For further information, see SRv6 Push/Remove Actions.
Data Path Hash Calculation	Data Path Hash is used by the application to predict what hash will be calculated for a received packet that is detected as if the packet has passed the hardware. The application can decide how to handle the calculation process based on the hash value, (e.g., forwarding to a specific port). The received packet in the slow path, (e.g., the first or the fragmented packet without hitting any offloading rule), can have the same handling as the following packets offloaded. This behavior removes some inconsistent behavior issue between slow path and data path, like the packets reordering within the same traffic flow. For further information, see Data Path Hash Calculation.
Support Flow Table Resize	The current template API supports fixed table size in the initial design, that means the maximal number of rules in a table should be predictable by the application. There would be an error when the application tries inserting a new rule exceeding the table’s capacity. This feature added support for resizing the table during runtime to allow more rules to be inserted. The table resize and rules migration have no downtime or interference to the traffic. Multiple tables can be resized simultaneously. For further information, see Flow Table Resize.
Add Random Item Support	Added support for `RTE_FLOW_ITEM_TYPE_RANDOM`. For each packet, a random value will be set per each hash. It can be used for statistic calculation over the packets, for example, setting one bit in the mask can match half of the traffic in a flow randomly. For more details, refer to: doc/guides/prog_guide/rte_flow.rst doc/guides/nics/mlx5.rst For further information, see Matching Random Value.
Support Hairpin Mesh Testing	Added support for the new ConnectX-7 NICs to include 4 ports or 2 ports with the split-cable. The dpdk-testpmd can support a complex mesh configuration of hairpin among all ports and not only between the 2 ports nearby. It will be easy for the user to verify the hairpin functionality before implementing the configuration in the application. For further information, see Hairpin Mesh Configuration and Testing.
Steering by Packet Type	Added support for the new flow item RTE_FLOW_ITEM_TYPE_PTYPE, which provides a quick way of finding out L2/L3/L4 protocols in each packet. This helps with optimized flow rules matching, eliminating the need of stacking all the packet headers in the matching criteria. PTYPE matching is only supported with template API now. For further information, see Steering by Packet Type.
Bug Fixes	See Bug Fixes.

Feature/Change	Description
Rev. MLNX_DPDK_22.11_2307.2.0
AES GCM Crypto	Enables encryption and integrity check of Additional Authenticated Data (AAD) with AES GCM. This extends the application’s flexibility to be better equipped and support advanced security requirements. Refer to the links below for more information: http://doc.dpdk.org/guides/prog_guide/cryptodev_lib.html http://doc.dpdk.org/guides/cryptodevs/mlx5.html For further information, see DPDK AES-GCM Crypto.
Network Service Header (NSH)	Network Service Header (NSH) provides a mechanism for metadata exchange along the instantiated service paths. The NSH is the Service Function Chaining (SFC) encapsulation required to support the SFC architecture (defined in RFC 7665). VXLAN-GPE with the NSHNetwork Service Headers (NSH) variable provides more flexibility than other protocols such as GRE and can be parsed and recognized by the NIC in the rte_flow non-template API now. The presence of NSH header can be matched, and the inner header created after VXLAN-gpe and NSH can be used for matching and for RSS hash fields. Note: The fields within the NSH header cannot be matched in the current implementation. For further information, see Matching Network Service Header (NSH).
Mirror Extension to Port Representor	Allows for the redirection of packets from the FDB domain to software by incorporating the PORT_REPRESENTOR action, enabling effective steering towards software. This capability holds significance in situations involving packet mirroring, where diagnostic requirements mandate the directed flow of mirrored packets to the software platform. For further information, see Mirror Extension to Port Representor.
Indirect Action List	Extended Indirect action to support an indirect action list (multiple actions in a list), to enable multiple flows to reuse the same list of actions. When utilizing the indirect action list, the application can share fixed actions along with flow-specific changeable ones (same action type, different attribute value). These values are provided during the offloading and reusing of the indirect action list. Note: METER_MARK is the sole attribute currently available for changes. The use of indirect action list allows efficient utilization when used and shared by mass number of rules in cases where the action list needs to be modified. In such case, the indirect action list is modified once and influences all the rules that reuse it instead of updating mass number of rules with similar action list scheme. For further information, see Indirect Actions List.
raw_encap/decap Action with Indirect Action Handle	When employing shared Encap/decap actions (with matching variants) within a table, the result is a considerable reduction in the number of required rules compared to the alternative approach. Pre-allocating the reformat actions with this number is a misusage of hardware resources therefore, indirect action for encap/decap is recommended in such scenarios. An indirect encap/decap action can be shared by different flow rules among different tables, thus, it reduces any memory footprint and cache-misses, increases overall PPS and enables use of higher scale of flows through optimized resources. For further information, see raw_encap/decap Action with Indirect Action Handle.
Reuse of encap/modify Actions for Different Templates	Reduces memory footprint when multiple action templates with encap/modify actions are shared for the same match. Rather than allocating memory and hardware resources separately for each action template, this enables efficient sharing of resource allocation for all the action templates, resulting in more optimized resource utilization. For further information, see Multi-Pattern HWS Table Actions.
Additional Flow Tags with rte_flow Template API for New Generation NICs	With template API, 3 tags are available in extended meta mode (dv_xmeta_en=4) and 5 tags are available in legacy mode for offloading. Starting with ConnectX-7 / BlueField-3, additional 3 tags are exposed and can be used for matching and modification as the other tags. By incorporating additional tags, the application gains greater flexibility to accommodate a wide range of use cases by enriching the packets with contextual data. This enables better abstraction of applications and streamlines the pipelines. This capability is supported, starting with firmware version xx.38.1002. For further information about the metadata mode, see: http://doc.dpdk.org/guides/nics/mlx5.html
Color-Aware mode: init_color per Rule of METER_MARK Action	The `"init_color"` and `"init_color_valid"` members are removed from the `"rte_flow_action_meter_mark"` struct. To enhances the Color-Aware mode with a single meter, a new structure `"rte_flow_indirect_update_flow_meter_mark"` is introduced with the `"init_color"` as its member. Different flow rules using a single meter can specify different initial colors as the input via the indirect action list API support. This will help to guarantee the minimal bandwidth of one rule (with green as init_color) among different rules (others without green as init_color) using the same meter. For further information about the Color-Aware mode, refer to the RFC 2697, RFC 2698 and RFC 4115. For further information, see METER_MARK Action API Change.
Arm Power Management	By using Wait For Event (WFE) instruction to suspend the lcore execution and Send Event (SEV) instruction to wake up the lcore, the OS can better manage the Arm cores power consumption without wrongly assuming there is a heavy load even if the traffic is idle. Then power consumption will be reduced when running on the Arm cores with a light load. For further information, see: https://doc.dpdk.org/guides/prog_guide/power_man.html
Geneve encap/decap and modify Actions	Added support for Geneve encap/decap as well as Geneve options modify with template API in addition to previously supported match on Geneve options.
Bug Fixes	See Bug Fixes.
Rev. MLNX_DPDK_22.11_2.0.0
Flex Item Matching	*[For BlueField- DPUs]** Enables the hardware to recognize the user's self-defined network header, and to match/modify sample data fields per flow rules. The header layout is fed via a JSON file in the fields: "header length"/"identification from preceding header"/"next header starting"/"next header type"/"header sample data".
Packet re-routing to the kernel	Added a flow action that routes packets to kernel over template rte_flow API. For further information, see Packet Re-Routing to the Kernel.
Matching RoCE IB BTH	Added support for a new RTE_ITEM (`RTE_FLOW_ITEM_TYPE_IB_BTH`) to match the RoCE IB BTH. Currently it supports only RoCEv2, opcode, and dst_qp fields. For further information, see Matching RoCE IB BTH opcode/dest_qp.
Live Upgrade	Added support for "standby" and "active" flow engine modes to support PMD live upgrades. For further information, see Live Upgrade.
Local/Remote Mirroring	The mirror action creates a number of cloned packets as well as keeps the original copy. Each of cloned packet can have different flow actions and destination, while the original packet resumes normal packet path.
RTE Flow Rule Update	The new rte_flow_update() API allows users to update the action list in the already existing rule. Flow rules can be updated now without the need to destroy the rule first and create a new one instead. A single API call ensures that no packets are lost by guaranteeing atomicity and flow state correctness. For further information, see Updating Flow Rule.
Multiprotocol Label Switching (MPLS)	This version present a new capability for matching MPLS tunnel over UDP when in HW steering mode. It supports multiple MPLS headers for matching as well as encapsulation/decapsulation. The maximum supported MPLS headers is 5. For further information, see Multiprotocol Label Switching.
Range Matching of IP Length Fields	Added support for IP length range matching. The user can use the `"mask"` and `"last"` fields in a `rte_flow_item` when creating a pattern template to indicate which parts will be used for range matching. When inserting a flow rule, the `"spec"` is used to specify the start value of the range, and the `"last"` is used to specify the end value. For further information, see Range Matching.
Adapter Cards	ConnectX-5 adapter card is not supported in MLNX_DPDK 22.11 branch.
Bug Fixes	See Bug Fixes.
Rev. MLNX_DPDK_22.11_1.0.0
Port Affinity Match	Added indication in the DPDK level to which physical port the packet belongs to. This capability is available by using a new pattern item type for port affinity. Its value reflects the physical port affinity of the received packets. Additionally, tx_affinity setting was added in the Tx queue, the affinity value reflects the physical port the packets will be sent to. This new capability is enables the app to receive the ingress port of a packet, and send the ACK out on the same port when dual ports devices are configured as a bond in Linux. For further information, see Port Affinity Match.
mlx5 Tx Datapath Tracing	The mlx5 Tx data-path tracing capability enables the user to gather the comprehensive information about packets' handling in PMD with timings, including the packet sending completion ones. For further information, see mlx5 Tx Datapath Tracing.
SRV6 Encapsulation/Decapsulation Offload	Enables the user to identify the IPv6 routing extension header's presence and match the 1st 32bits. In testpmd CLI, the user can specify the desired encapsulation pattern of IPv6 routing extension for `raw_encap`. `raw_decap` will remove it automatically if present. For further information, see SRV6 Encapsulation/Decapsulation Offload.
Support Range based Matching	Enables the user to match an item with a range of values, and not just a single value. The minimum value is set in the `"spec"` and the maximum is set in the `"last"`.