[PATCH 24.11] net/mlx5/hws: fix ESP header match in strict mode

Kevin Traynor ktraynor at redhat.com
Wed Nov 12 13:15:33 CET 2025


On 12/11/2025 07:35, Viacheslav Ovsiienko wrote:
> [ upstream commit 4237d1efa6e3f7f18ba809aa2073640fb034ae8d ]
> 

Hi Slava. I just noticed while checking this commit, there are two
commits of the same name, and as result I only sent a note about one
needing rebase.

f2f75ffe14 net/mlx5/hws: fix ESP header match in strict mode
https://git.dpdk.org/dpdk/commit/?id=f2f75ffe14
I sent this one in list of commits needing rebase, as the function did
not exist. Not sure if that's something you want to do or just drop.

4237d1efa6 net/mlx5/hws: fix ESP header match in strict mode
https://git.dpdk.org/dpdk/commit/?id=4237d1efa6
I missed to send this in the list needing rebase. It applied but not
building, so I needed to remove. I saw other commit of same name in list
of commits for rebase and assumed it was the same one. Now I have
backport I will apply.

thanks,
Kevin.

> The pattern like "eth / ipv6 / esp / end" matched on any IPv6
> packet in strict mode, because there was no implicit match on the
> IP.proto forced.
> 
> This patch adds the implicit match on IP.proto with value 50 (ESP)
> and adds implicit match on UDP.dport with value 4500 for the case
> ESP over UDP.
> 
> Fixes: 81cf20a25abf ("net/mlx5/hws: support match on ESP item")
> Cc: stable at dpdk.org
> 
> Signed-off-by: Viacheslav Ovsiienko <viacheslavo at nvidia.com>
> Acked-by: Matan Azrad <matan at nvidia.com>
> ---
>  drivers/net/mlx5/hws/mlx5dr_definer.c | 29 +++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/net/mlx5/hws/mlx5dr_definer.c b/drivers/net/mlx5/hws/mlx5dr_definer.c
> index 4af24c788a..25d7f729c5 100644
> --- a/drivers/net/mlx5/hws/mlx5dr_definer.c
> +++ b/drivers/net/mlx5/hws/mlx5dr_definer.c
> @@ -14,6 +14,7 @@
>  #define UDP_VXLAN_PORT	4789
>  #define UDP_VXLAN_GPE_PORT	4790
>  #define UDP_GTPU_PORT	2152
> +#define UDP_ESP_PORT	4500
>  #define UDP_PORT_MPLS	6635
>  #define UDP_GENEVE_PORT 6081
>  #define UDP_ROCEV2_PORT	4791
> @@ -230,6 +231,8 @@ struct mlx5dr_definer_conv_data {
>  	X(SET_BE16,	nvgre_protocol,		v->protocol,		rte_flow_item_nvgre) \
>  	X(SET_BE32P,	nvgre_dw1,		&v->tni[0],		rte_flow_item_nvgre) \
>  	X(SET,		meter_color,		rte_col_2_mlx5_col(v->color),	rte_flow_item_meter_color) \
> +	X(SET,		ipsec_protocol,		IPPROTO_ESP,		rte_flow_item_esp) \
> +	X(SET,		ipsec_udp_port,		UDP_ESP_PORT,		rte_flow_item_esp) \
>  	X(SET_BE32,     ipsec_spi,              v->hdr.spi,             rte_flow_item_esp) \
>  	X(SET_BE32,     ipsec_sequence_number,  v->hdr.seq,             rte_flow_item_esp) \
>  	X(SET,		ib_l4_udp_port,		UDP_ROCEV2_PORT,	rte_flow_item_ib_bth) \
> @@ -2804,6 +2807,32 @@ mlx5dr_definer_conv_item_esp(struct mlx5dr_definer_conv_data *cd,
>  	const struct rte_flow_item_esp *m = item->mask;
>  	struct mlx5dr_definer_fc *fc;
>  
> +	/* To match on ESP we must match on ip_protocol and optionally on l4_dport */
> +	if (!cd->relaxed) {
> +		bool over_udp;
> +
> +		fc = &cd->fc[DR_CALC_FNAME(IP_PROTOCOL, false)];
> +		over_udp = fc->tag_set == &mlx5dr_definer_udp_protocol_set;
> +
> +		if (over_udp) {
> +			fc = &cd->fc[DR_CALC_FNAME(L4_DPORT, false)];
> +			if (!fc->tag_set) {
> +				fc->item_idx = item_idx;
> +				fc->tag_mask_set = &mlx5dr_definer_ones_set;
> +				fc->tag_set = &mlx5dr_definer_ipsec_udp_port_set;
> +				DR_CALC_SET(fc, eth_l4, destination_port, false);
> +			}
> +		} else {
> +			fc = &cd->fc[DR_CALC_FNAME(IP_PROTOCOL, false)];
> +			if (!fc->tag_set) {
> +				fc->item_idx = item_idx;
> +				fc->tag_set = &mlx5dr_definer_ipsec_protocol_set;
> +				fc->tag_mask_set = &mlx5dr_definer_ones_set;
> +				DR_CALC_SET(fc, eth_l3, protocol_next_header, false);
> +			}
> +		}
> +	}
> +
>  	if (!m)
>  		return 0;
>  	if (m->hdr.spi) {



More information about the stable mailing list