On 18/07/2025 17:13, Bruce Richardson wrote: > On Fri, Jul 18, 2025 at 05:05:45PM +0100, Kevin Traynor wrote: >> On 18/07/2025 16:19, Bruce Richardson wrote: >>> On Fri, Jul 18, 2025 at 04:03:17PM +0100, Kevin Traynor wrote: >>>> On 03/07/2025 15:31, Ciara Loftus wrote: >>>>> The SSE rx and tx paths will be removed from the i40e, iavf and ice >>>>> drivers in the 25.11 release. Each of these drivers have faster >>>>> vector paths (AVX2 and AVX-512) which have feature parity with the >>>>> soon to be removed SSE paths. In environments where AVX2 or AVX-512 >>>>> are not supported, the scalar path will still be used, which also has >>>>> feature parity. >>>>> >>>>> Signed-off-by: Ciara Loftus <ciara.lof...@intel.com> --- >>>>> doc/guides/rel_notes/deprecation.rst | 7 +++++++ 1 file changed, 7 >>>>> insertions(+) >>>>> >>>>> diff --git a/doc/guides/rel_notes/deprecation.rst >>>>> b/doc/guides/rel_notes/deprecation.rst index e2d4125308..0d020c9c1f >>>>> 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ >>>>> b/doc/guides/rel_notes/deprecation.rst @@ -80,6 +80,13 @@ Deprecation >>>>> Notices and the header struct ``rte_vxlan_gpe_hdr`` with the macro >>>>> ``RTE_ETHER_VXLAN_GPE_HLEN`` will be removed in DPDK 25.11. >>>>> >>>>> +* net/intel: drivers that have an SSE vector path alongside other >>>>> vector paths, + namely i40e, iavf and ice, will have their SSE >>>>> vector paths removed in DPDK 25.11. + Modern x86 systems all >>>>> support AVX2, if not AVX-512, so the SSE path is no longer + widely >>>>> used. This change will not result in any feature loss, as the >>>>> fallback + scalar paths which have feature parity with SSE will be >>>>> used in the cases where + the SSE paths would have been used. + * >>>>> ethdev: The flow API matching pattern structures, ``struct >>>>> rte_flow_item_*``, should start with relevant protocol header >>>>> structure from lib/net/. The individual protocol header fields and >>>>> the protocol header struct >>>> >>>> I'm not aware of anyone using hardware that old and relying on SSE, >>>> but it seems a bit short notice for a patch to remove hardware >>>> support. >>>> >>>> Would it hurt much to give it a longer deprecation so anyone who needs >>>> to prepare by upgrade, or taking 25.11 with support etc. can do that ? >>>> >>> Do we think that will make a difference? After all, dropping the SSE >>> path won't break DPDK on older hardware, it will only run a bit slower >>> using the scalar path. Beyond that, it would only affect deployments >>> with new/latest DPDK on old hardware - obviously old hardware running >>> older DPDK would be unaffected. >>> >> >> Don't disagree, and it does seem a bit of mismatch using old hw and new >> DPDK, but I needed to spend a bit of time to try and check if this would >> impact wrt systems used, compile options, product upgrade paths etc. so >> others might be in same boat. >> >> Alternatively, could put the deprecation now and revisit if anyone >> complains before 25.11. >> > Sure. Let's deprecate now and if there are any objections or we decide to > postpone the removal in 25.11 that is fine. >
Sounds good. Acked-by: Kevin Traynor <ktray...@redhat.com> > /Bruce >
