[PATCH v2] net/intel: deprecate some SSE paths
Kevin Traynor
ktraynor at redhat.com
Fri Jul 18 18:05:45 CEST 2025
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.loftus at 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.
> /Bruce
>
More information about the dev
mailing list