<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="en-IL" link="#0563C1" vlink="#954F72" style="word-wrap:break-word"> <div class="WordSection1"> Please find below NVIDIA roadmap for 23.11 release:<o:p></o:p> <o:p></o:p> A. rte_flow new APIs<o:p></o:p> =================<o:p></o:p> <ol style="margin-top:0cm" start="1" type="1"> <li class="MsoNormal" style="mso-list:l7 level1 lfo1;vertical-align:middle">Support color-aware mode for meters in shared actions list<o:p></o:p></li></ol> Support meter color updates based on traffic BW. Additionally, enable use of shared (indirect) meters as part of shared action lists<o:p></o:p> <o:p></o:p> <ol style="margin-top:0cm" start="2" type="1"> <li class="MsoNormal" style="mso-list:l1 level1 lfo2;vertical-align:middle">Add IPv6 extension push & remove actions.<o:p></o:p></li></ol> Add new rte_flow actions to support push/remove IPv6 extension header. <o:p></o:p> <o:p> </o:p> <ol style="margin-top:0cm" start="3" type="1"> <li class="MsoNormal" style="mso-list:l12 level1 lfo3;vertical-align:middle">Add template API new rte_flow function for hash calculation to enable SW applications to use the same hash as calculated in HW.<o:p></o:p></li></ol> This capabiity enables alignment of hash values between HW pipelines and SW pipelines, so partial offloads pipes can be aligned with offloaded pipes and use the same hash value. <o:p></o:p> When an application uses hash-based insert by index, the flow of the packet depends on the calculated hash. For packets that belong to the same flow <o:p></o:p> but passed through the SW such hash was not calculated. In this case, application can calculate the same hash as the HW does before sending it to the wire.<o:p></o:p> <o:p></o:p> <ol style="margin-top:0cm" start="4" type="1"> <li class="MsoListParagraphCxSpFirst" style="margin-left:0cm;mso-add-space:auto;mso-list:l12 level1 lfo3"> Support group default missaction<o:p></o:p></li></ol> A group's miss actions are a set of actions to be performed in case of a miss on a group, meaning a packet didn't hit any rules in the group.<o:p></o:p> This new API function allows a user to set a group's miss actions in an explicit way, reducing number of hops and increasing pps in case of handling misses. <o:p></o:p> <o:p> </o:p> <ol style="margin-top:0cm" start="5" type="1"> <li class="MsoNormal" style="mso-list:l6 level1 lfo4;vertical-align:middle">Add RTE_FLOW_ITEM_TYPE_PTYPE to allow matching on L2/L3/L4 and tunnel information as defined in mbuf.<o:p></o:p></li></ol> The packet type matching provides quick way of finding out L2/L3/L4 protocols in each packet. <o:p></o:p> That helps with optimized flow rules matching, eliminating the need of stacking all the packet headers in the matching criteria.<o:p></o:p> As part of this feature a new packet type will be added for ESP.<o:p></o:p> <o:p> </o:p> <ol style="margin-top:0cm" start="6" type="1"> <li class="MsoListParagraph" style="margin-bottom:0cm;margin-left:0cm;mso-add-space:auto;line-height:normal;mso-list:l6 level1 lfo4;vertical-align:middle"> Adding NAT64 action<o:p></o:p></li></ol> Adding a new action for header re-write of NAT64. <o:p></o:p> NAT64 (Network Address Translation 64) is a networking technology that facilitates communication between IPv6 and IPv4 networks.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> B. Net/mlx5 PMD updates<o:p></o:p> =====================<o:p></o:p> All new APIs implemented above will be supported in mlx5.<o:p></o:p> Other features described below:<o:p></o:p> <o:p> </o:p> <ol style="margin-top:0cm" start="1" type="1"> <li class="MsoNormal" style="mso-list:l10 level1 lfo5;vertical-align:middle">Provide additional 3 tags in the new generation NICs with rte_flow template API.<o:p></o:p></li></ol> 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, <o:p></o:p> 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 <o:p></o:p> accommodate a wide range of use cases by enriching the packets with contextual data. This enables better abstraction of applications and streamlines the pipelines. <o:p></o:p> <o:p></o:p> <ol style="margin-top:0cm" start="2" type="1"> <li class="MsoNormal" style="mso-list:l3 level1 lfo6;vertical-align:middle">Support parsing of VXLAN-gpe with NSH<o:p></o:p></li></ol> VXLAN-gpe with variable Network Service Headers (NSH) offers greater flexibility compared to certain other protocols, such as GRE.<o:p></o:p> The presence of an NSH header can be checked and matched, without matching any specific field of the NSH. Then the inner header can also be matched and used as RSS fields. <o:p></o:p> The VXLAN-gpe with a variable NSH can be parsed and recognized by the NIC. In the rte_flow non-template API, the presence of NSH can be matched.<o:p></o:p> The inner header after VXLAN-gpe and NSH can be used for matching and for RSS hash fields.<o:p></o:p> In the rte_flow non-template API, The VXLAN-gpe with a variable NSH can be parsed and recognized by the NIC. The presence of NSH header can be <o:p></o:p> matched and the inner header after VXLAN-gpe and NSH can be used for matching and for RSS hash fields.<o:p></o:p> <o:p></o:p> <ol style="margin-top:0cm" start="3" type="1"> <li class="MsoNormal" style="mso-list:l4 level1 lfo7;vertical-align:middle">Support Geneve encap/decap and modify actions.<o:p></o:p></li></ol> Added support for Geneve raw_encap/decap as well as Geneve options modify with template API in addition to previously supported match on Geneve options.<o:p></o:p> <o:p></o:p> <ol style="margin-top:0cm" start="4" type="1"> <li class="MsoNormal" style="mso-list:l0 level1 lfo8;vertical-align:middle">Extend mirror action to support mirroring from FDB to queue/RSS.<o:p></o:p></li></ol> Enable packets steering from FDB domain to SW through supporting explicit PORT_REPRESENTOR action for steering to SW. Useful for mirroring use case in which mirrored packets need to be destined to the SW for diagnostic.<o:p></o:p> <o:p></o:p> <ol style="margin-top:0cm" start="5" type="1"> <li class="MsoNormal" style="mso-list:l9 level1 lfo9;vertical-align:middle">Support sharing raw_encap/decap action with indirect action handle.<o:p></o:p></li></ol> In some cases when using template API, large number of rules have the same encap/decap actions characteristics. To reduce the number of encap/decap instances, we provide a method to share the <o:p></o:p> encap/decap actions amongst the different rules through definition of these shared encap/decap actions as indirect (stand-alone) entities that are reused and shared by multiple rules. <o:p></o:p> This indirect encap/decap action will be shared by different flow rules among different tables. <o:p></o:p> Using this method, memory footprint and cache-misses would be reduced, increasing overall PPS and enabling use of higher scale of flows through optimized resources. <o:p></o:p> <o:p> </o:p> <ol style="margin-top:0cm" start="6" type="1"> <li class="MsoNormal" style="mso-list:l11 level1 lfo10;vertical-align:middle">Reuse encap/modify actions for different templates.<o:p></o:p></li></ol> Allows for a reduction in memory footprint when *multiple* action *templates* with encap/modify actions are shared for the same match. Rather than allocating memory and <o:p></o:p> 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.<o:p></o:p> <o:p></o:p> <ol style="margin-top:0cm" start="7" type="1"> <li class="MsoNormal" style="mso-list:l8 level1 lfo11;vertical-align:middle">Return detailed error if the match pattern cannot be created due to matching fields limit.<o:p></o:p></li></ol> Different NIC generations has different matching size limits (number of matching fields).<o:p></o:p> Once application receive such error, it should perform relevant enhancements to build an alternate matching pipe that fits to the NIC’s limits.<o:p></o:p> <o:p></o:p> <ol style="margin-top:0cm" start="8" type="1"> <li class="MsoNormal" style="mso-list:l2 level1 lfo12;vertical-align:middle">Support hairpin with 4 physical ports<o:p></o:p></li></ol> For Connectx -7 Nic's that support 4 physical ports, detect port number, and update hairpin logic to enable use of all ports. Current testpmd <o:p></o:p> enable sequential pair for hairpin, this feature is meant to enable any pair.<o:p></o:p> <o:p> </o:p> <ol style="margin-top:0cm" start="9" type="1"> <li class="MsoListParagraphCxSpFirst" style="margin-bottom:0cm;margin-left:0cm;mso-add-space:auto;line-height:normal;mso-list:l2 level1 lfo12;vertical-align:middle"> Add queue counter statistics to hairpin queues. <o:p></o:p></li></ol> For Connectx-7 and above, enable SW to query hairpin drops per queue instead of a global counter.<o:p></o:p> <o:p></o:p> <ol style="margin-top:0cm" start="10" type="1"> <li class="MsoListParagraph" style="margin-bottom:0cm;margin-left:0cm;mso-add-space:auto;line-height:normal;mso-list:l2 level1 lfo12;vertical-align:middle"> Multiport e-switch support<o:p></o:p></li></ol> Enable e-switch to route traffic between 2 different physical ports.<o:p></o:p> Before, FDB implementation was per PF. This feature implements a shared FDB that allows entering rules that apply to <o:p></o:p> different PF's such that the traffic could be routed to any of these PF's.<o:p></o:p> <o:p> </o:p> <ol style="margin-top:0cm" start="11" type="1"> <li class="MsoNormal" style="mso-list:l2 level1 lfo12;vertical-align:middle">Support shared indirect QUOTA action.<o:p></o:p></li></ol> <o:p></o:p> <o:p> </o:p> C. Test apps updates <o:p></o:p> ================= <o:p></o:p> <ol style="margin-top:0cm" start="1" type="1"> <li class="MsoNormal" style="mso-list:l5 level1 lfo13;vertical-align:middle">Support the changes in rte_flow listed above in testpmd. <o:p></o:p></li></ol> Including verify of IPv6 extension push & remove actions.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Regards,<o:p></o:p> Maayan Kashani<o:p></o:p> <o:p> </o:p> </div> </body> </html>