|SUCCESS| [7/7] net/ice: pin outer Ethertype for L2TPv2 flow rules

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/163304

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-04-27

commit a1b2c3d4e5f6
Author: Shaiq Wani <shaiq.wani at intel.com>

net/ice: use granular PTYPEs for L2TPv2 PPP

All L2TPv2 PPP variants map to ICE_MAC_IPV4_L2TPV2 (398), so inner
protocol type is not differentiated, allowing cross-protocol flow
matches (e.g. a PPP/IPv4 rule hitting a PPP/IPv6 packet).

Fix ice_ptype_map[] to use the 30 granular L2TPv2 PTYPEs (396-425)
defined by the DDP package. Also add PPP inner protocol flow types to
ice_fdir_gen_l2tpv2_pkt() so training packets get dynamically built
L2TPv2 headers instead of static templates.

> diff --git a/drivers/net/intel/ice/base/ice_fdir.c b/drivers/net/intel/ice/base/ice_fdir.c
> index 1846fbc515..a30e87ddcc 100644
> --- a/drivers/net/intel/ice/base/ice_fdir.c
> +++ b/drivers/net/intel/ice/base/ice_fdir.c
> @@ -3886,6 +3886,12 @@ ice_fdir_get_gen_prgm_pkt(struct ice_hw *hw, struct ice_fdir_fltr *input,
>  		case ICE_FLTR_PTYPE_NONF_IPV4_L2TPV2_CONTROL:
>  		case ICE_FLTR_PTYPE_NONF_IPV4_L2TPV2:
>  		case ICE_FLTR_PTYPE_NONF_IPV4_L2TPV2_PPP:
> +		case ICE_FLTR_PTYPE_NONF_IPV4_L2TPV2_PPP_IPV4:
> +		case ICE_FLTR_PTYPE_NONF_IPV4_L2TPV2_PPP_IPV4_UDP:
> +		case ICE_FLTR_PTYPE_NONF_IPV4_L2TPV2_PPP_IPV4_TCP:
> +		case ICE_FLTR_PTYPE_NONF_IPV4_L2TPV2_PPP_IPV6:
> +		case ICE_FLTR_PTYPE_NONF_IPV4_L2TPV2_PPP_IPV6_UDP:
> +		case ICE_FLTR_PTYPE_NONF_IPV4_L2TPV2_PPP_IPV6_TCP:
>  			offset = ICE_FDIR_IPV4_L2TPV2_PPP_PKT_OFF;
>  			ice_fdir_gen_l2tpv2_pkt(pkt, &input->l2tpv2_data,
>  						idx, offset, tun);
> @@ -3893,6 +3899,12 @@ ice_fdir_get_gen_prgm_pkt(struct ice_hw *hw, struct ice_fdir_fltr *input,
>  		case ICE_FLTR_PTYPE_NONF_IPV6_L2TPV2_CONTROL:
>  		case ICE_FLTR_PTYPE_NONF_IPV6_L2TPV2:
>  		case ICE_FLTR_PTYPE_NONF_IPV6_L2TPV2_PPP:
> +		case ICE_FLTR_PTYPE_NONF_IPV6_L2TPV2_PPP_IPV4:
> +		case ICE_FLTR_PTYPE_NONF_IPV6_L2TPV2_PPP_IPV4_UDP:
> +		case ICE_FLTR_PTYPE_NONF_IPV6_L2TPV2_PPP_IPV4_TCP:
> +		case ICE_FLTR_PTYPE_NONF_IPV6_L2TPV2_PPP_IPV6:
> +		case ICE_FLTR_PTYPE_NONF_IPV6_L2TPV2_PPP_IPV6_UDP:
> +		case ICE_FLTR_PTYPE_NONF_IPV6_L2TPV2_PPP_IPV6_TCP:
>  			offset = ICE_FDIR_IPV6_L2TPV2_PPP_PKT_OFF;
>  			ice_fdir_gen_l2tpv2_pkt(pkt, &input->l2tpv2_data,
>  						idx, offset, tun);

[ ... ]

> diff --git a/drivers/net/intel/ice/ice_generic_flow.c b/drivers/net/intel/ice/ice_generic_flow.c
> index 62f0c334a1..f838a987e7 100644
> --- a/drivers/net/intel/ice/ice_generic_flow.c
> +++ b/drivers/net/intel/ice/ice_generic_flow.c
> @@ -2183,21 +2183,21 @@ static struct ice_ptype_match ice_ptype_map[] = {
>  	{pattern_eth_ipv4_ah,				ICE_MAC_IPV4_AH},
>  	{pattern_eth_ipv4_l2tp,				ICE_MAC_IPV4_L2TPV3},
>  	{pattern_eth_ipv4_udp_l2tpv2,		ICE_MAC_IPV4_L2TPV2},
> -	{pattern_eth_ipv4_udp_l2tpv2_ppp,		ICE_MAC_IPV4_L2TPV2},
> -	{pattern_eth_ipv4_udp_l2tpv2_ppp_ipv4,		ICE_MAC_IPV4_L2TPV2},
> -	{pattern_eth_ipv4_udp_l2tpv2_ppp_ipv4_udp,	ICE_MAC_IPV4_L2TPV2},
> -	{pattern_eth_ipv4_udp_l2tpv2_ppp_ipv4_tcp,	ICE_MAC_IPV4_L2TPV2},
> -	{pattern_eth_ipv4_udp_l2tpv2_ppp_ipv6,		ICE_MAC_IPV4_L2TPV2},
> -	{pattern_eth_ipv4_udp_l2tpv2_ppp_ipv6_udp,	ICE_MAC_IPV4_L2TPV2},
> -	{pattern_eth_ipv4_udp_l2tpv2_ppp_ipv6_tcp,	ICE_MAC_IPV4_L2TPV2},
> +	{pattern_eth_ipv4_udp_l2tpv2_ppp,		ICE_MAC_IPV4_PPPOL2TPV2},
> +	{pattern_eth_ipv4_udp_l2tpv2_ppp_ipv4,		ICE_MAC_IPV4_PPPOL2TPV2_IPV4_PAY},
> +	{pattern_eth_ipv4_udp_l2tpv2_ppp_ipv4_udp,	ICE_MAC_IPV4_PPPOL2TPV2_IPV4_UDP_PAY},
> +	{pattern_eth_ipv4_udp_l2tpv2_ppp_ipv4_tcp,	ICE_MAC_IPV4_PPPOL2TPV2_IPV4_TCP},
> +	{pattern_eth_ipv4_udp_l2tpv2_ppp_ipv6,		ICE_MAC_IPV4_PPPOL2TPV2_IPV6_PAY},
> +	{pattern_eth_ipv4_udp_l2tpv2_ppp_ipv6_udp,	ICE_MAC_IPV4_PPPOL2TPV2_IPV6_UDP_PAY},
> +	{pattern_eth_ipv4_udp_l2tpv2_ppp_ipv6_tcp,	ICE_MAC_IPV4_PPPOL2TPV2_IPV6_TCP},

Does this code have a validation path that ensures these new PTYPE
constants are actually defined in the DDP package? Can the driver load
with a mismatched or older DDP version that lacks these PTYPEs?

>  	{pattern_eth_ipv6_udp_l2tpv2,		ICE_MAC_IPV6_L2TPV2},
> -	{pattern_eth_ipv6_udp_l2tpv2_ppp,		ICE_MAC_IPV6_L2TPV2},
> -	{pattern_eth_ipv6_udp_l2tpv2_ppp_ipv4,		ICE_MAC_IPV6_L2TPV2},
> -	{pattern_eth_ipv6_udp_l2tpv2_ppp_ipv4_udp,	ICE_MAC_IPV6_L2TPV2},
> -	{pattern_eth_ipv6_udp_l2tpv2_ppp_ipv4_tcp,	ICE_MAC_IPV6_L2TPV2},
> -	{pattern_eth_ipv6_udp_l2tpv2_ppp_ipv6,		ICE_MAC_IPV6_L2TPV2},
> -	{pattern_eth_ipv6_udp_l2tpv2_ppp_ipv6_udp,	ICE_MAC_IPV6_L2TPV2},
> -	{pattern_eth_ipv6_udp_l2tpv2_ppp_ipv6_tcp,	ICE_MAC_IPV6_L2TPV2},
> +	{pattern_eth_ipv6_udp_l2tpv2_ppp,		ICE_MAC_IPV6_PPPOL2TPV2},
> +	{pattern_eth_ipv6_udp_l2tpv2_ppp_ipv4,		ICE_MAC_IPV6_PPPOL2TPV2_IPV4_PAY},
> +	{pattern_eth_ipv6_udp_l2tpv2_ppp_ipv4_udp,	ICE_MAC_IPV6_PPPOL2TPV2_IPV4_UDP_PAY},
> +	{pattern_eth_ipv6_udp_l2tpv2_ppp_ipv4_tcp,	ICE_MAC_IPV6_PPPOL2TPV2_IPV4_TCP},
> +	{pattern_eth_ipv6_udp_l2tpv2_ppp_ipv6,		ICE_MAC_IPV6_PPPOL2TPV2_IPV6_PAY},
> +	{pattern_eth_ipv6_udp_l2tpv2_ppp_ipv6_udp,	ICE_MAC_IPV6_PPPOL2TPV2_IPV6_UDP_PAY},
> +	{pattern_eth_ipv6_udp_l2tpv2_ppp_ipv6_tcp,	ICE_MAC_IPV6_PPPOL2TPV2_IPV6_TCP},

[ ... ]

commit b2c3d4e5f607
Author: Shaiq Wani <shaiq.wani at intel.com>

net/ice: add tunnel inset bits to flow input set map

[ ... ]

> diff --git a/drivers/net/intel/ice/ice_fdir_filter.c b/drivers/net/intel/ice/ice_fdir_filter.c
> index ce80213429..5ee9edc442 100644
> --- a/drivers/net/intel/ice/ice_fdir_filter.c
> +++ b/drivers/net/intel/ice/ice_fdir_filter.c
> @@ -1004,6 +1004,14 @@ ice_fdir_input_set_parse(uint64_t inset, enum ice_flow_field *field)
>  		{ICE_INSET_NAT_T_ESP_SPI, ICE_FLOW_FIELD_IDX_NAT_T_ESP_SPI},
>  		{ICE_INSET_L2TPV2OIP_SESSION_ID, ICE_FLOW_FIELD_IDX_L2TPV2_SESS_ID},
>  		{ICE_INSET_L2TPV2OIP_LEN_SESSION_ID, ICE_FLOW_FIELD_IDX_L2TPV2_LEN_SESS_ID},
> +		{ICE_INSET_TUN_IPV4_SRC, ICE_FLOW_FIELD_IDX_IPV4_SA},
> +		{ICE_INSET_TUN_IPV4_DST, ICE_FLOW_FIELD_IDX_IPV4_DA},
> +		{ICE_INSET_TUN_IPV6_SRC, ICE_FLOW_FIELD_IDX_IPV6_SA},
> +		{ICE_INSET_TUN_IPV6_DST, ICE_FLOW_FIELD_IDX_IPV6_DA},
> +		{ICE_INSET_TUN_TCP_SRC_PORT, ICE_FLOW_FIELD_IDX_TCP_SRC_PORT},
> +		{ICE_INSET_TUN_TCP_DST_PORT, ICE_FLOW_FIELD_IDX_TCP_DST_PORT},
> +		{ICE_INSET_TUN_UDP_SRC_PORT, ICE_FLOW_FIELD_IDX_UDP_SRC_PORT},
> +		{ICE_INSET_TUN_UDP_DST_PORT, ICE_FLOW_FIELD_IDX_UDP_DST_PORT},
>  	};

Does this mapping correctly resolve conflicts when both outer and inner
fields share the same ICE_FLOW_FIELD_IDX? For example, does this code
distinguish between TUN_IPV4_SRC and a non-tunnel IPV4_SRC?

[ ... ]

commit c3d4e5f60718
Author: Shaiq Wani <shaiq.wani at intel.com>

net/ice: fix L2TPv2 inner segment header setup

[ ... ]

> diff --git a/drivers/net/intel/ice/ice_fdir_filter.c b/drivers/net/intel/ice/ice_fdir_filter.c
> index 5ee9edc442..a0cddaeaef 100644
> --- a/drivers/net/intel/ice/ice_fdir_filter.c
> +++ b/drivers/net/intel/ice/ice_fdir_filter.c
> @@ -1022,7 +1022,8 @@ ice_fdir_input_set_parse(uint64_t inset, enum ice_flow_field *field)
>  }
>  
>  static void
> -ice_fdir_input_set_hdrs(enum ice_fltr_ptype flow, struct ice_flow_seg_info *seg)
> +ice_fdir_input_set_hdrs(enum ice_fltr_ptype flow, struct ice_flow_seg_info *seg,
> +		       int seg_idx)

Does this function ever get called with a negative seg_idx? Can seg_idx
be validated?

[ ... ]

> @@ -1192,15 +1315,22 @@ ice_fdir_input_set_conf(struct ice_pf *pf, enum ice_