|SUCCESS| net/ice: fix L2TPv2 outer MAC address in training packet
dpdklab at iol.unh.edu
dpdklab at iol.unh.edu
Thu Apr 9 03:35:37 CEST 2026
Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/162857
_AI Code Review_
=== Patch Review: series.patch (via Claude) ===
Review date: 2026-04-09
I will now review the patch file 'series.patch' against the DPDK coding standards and contribution guidelines.
---
git sha: 20260406081355.3241393-1-shaiq.wani at intel.com
Author: Shaiq Wani <shaiq.wani at intel.com>
Subject: [PATCH] net/ice: fix L2TPv2 outer MAC address in training packet
This patch fixes an issue where L2TPv2 flow rules fail to match due to
outer MAC addresses being written to the wrong location in the training
packet. The fix adds L2TPv2 detection in the pre-scan loop and corrects
the pointer usage for MAC insertion.
> diff --git a/drivers/net/intel/ice/base/ice_fdir.c b/drivers/net/intel/ice/base/ice_fdir.c
> index 2c0cb99854..e1d8b65972 100644
> --- a/drivers/net/intel/ice/base/ice_fdir.c
> +++ b/drivers/net/intel/ice/base/ice_fdir.c
> @@ -4599,16 +4599,16 @@ ice_fdir_get_gen_prgm_pkt(struct ice_hw *hw, struct ice_fdir_fltr *input,
> input->ip.v6.tc);
> break;
> case ICE_FLTR_PTYPE_NONF_IPV4_L2TPV2_CONTROL:
> - ice_pkt_insert_mac_addr(loc, input->ext_data_outer.dst_mac);
> - ice_pkt_insert_mac_addr(loc + ETH_ALEN,
> + ice_pkt_insert_mac_addr(pkt, input->ext_data_outer.dst_mac);
> + ice_pkt_insert_mac_addr(pkt + ETH_ALEN,
> input->ext_data_outer.src_mac);
> ice_pkt_insert_u16(loc, ICE_IPV4_L2TPV2_LEN_SESS_ID_OFFSET,
> input->l2tpv2_data.session_id);
> break;
> case ICE_FLTR_PTYPE_NONF_IPV4_L2TPV2:
> case ICE_FLTR_PTYPE_NONF_IPV4_L2TPV2_PPP:
> - ice_pkt_insert_mac_addr(loc, input->ext_data_outer.dst_mac);
> - ice_pkt_insert_mac_addr(loc + ETH_ALEN,
> + ice_pkt_insert_mac_addr(pkt, input->ext_data_outer.dst_mac);
> + ice_pkt_insert_mac_addr(pkt + ETH_ALEN,
> input->ext_data_outer.src_mac);
> flags_version = BE16_TO_CPU(input->l2tpv2_data.flags_version);
> if (flags_version & ICE_L2TPV2_FLAGS_LEN) {
Does this code need to check that pkt is non-NULL before dereferencing?
Looking at ice_fdir_get_gen_prgm_pkt(), can pkt ever be NULL at this
point?
> @@ -4622,16 +4622,16 @@ ice_fdir_get_gen_prgm_pkt(struct ice_hw *hw, struct ice_fdir_fltr *input,
> }
> break;
> case ICE_FLTR_PTYPE_NONF_IPV6_L2TPV2_CONTROL:
> - ice_pkt_insert_mac_addr(loc, input->ext_data_outer.dst_mac);
> - ice_pkt_insert_mac_addr(loc + ETH_ALEN,
> + ice_pkt_insert_mac_addr(pkt, input->ext_data_outer.dst_mac);
> + ice_pkt_insert_mac_addr(pkt + ETH_ALEN,
> input->ext_data_outer.src_mac);
> ice_pkt_insert_u16(loc, ICE_IPV6_L2TPV2_LEN_SESS_ID_OFFSET,
> input->l2tpv2_data.session_id);
> break;
> case ICE_FLTR_PTYPE_NONF_IPV6_L2TPV2:
> case ICE_FLTR_PTYPE_NONF_IPV6_L2TPV2_PPP:
> - ice_pkt_insert_mac_addr(loc, input->ext_data_outer.dst_mac);
> - ice_pkt_insert_mac_addr(loc + ETH_ALEN,
> + ice_pkt_insert_mac_addr(pkt, input->ext_data_outer.dst_mac);
> + ice_pkt_insert_mac_addr(pkt + ETH_ALEN,
> input->ext_data_outer.src_mac);
> flags_version = BE16_TO_CPU(input->l2tpv2_data.flags_version);
> if (flags_version & ICE_L2TPV2_FLAGS_LEN) {
> diff --git a/drivers/net/intel/ice/ice_fdir_filter.c b/drivers/net/intel/ice/ice_fdir_filter.c
> index 3522d77123..1cbc613020 100644
> --- a/drivers/net/intel/ice/ice_fdir_filter.c
> +++ b/drivers/net/intel/ice/ice_fdir_filter.c
> @@ -1911,6 +1911,8 @@ ice_fdir_parse_pattern(__rte_unused struct ice_adapter *ad,
> for (item = pattern; item->type != RTE_FLOW_ITEM_TYPE_END; item++) {
> if (item->type == RTE_FLOW_ITEM_TYPE_VXLAN)
> tunnel_type = ICE_FDIR_TUNNEL_TYPE_VXLAN;
> + if (item->type == RTE_FLOW_ITEM_TYPE_L2TPV2)
> + tunnel_type = ICE_FDIR_TUNNEL_TYPE_L2TPV2;
> /* To align with shared code behavior, save gtpu outer
> * fields in inner struct.
> */
Does this code preserve the existing tunnel_type if both VXLAN and
L2TPV2 items are present in the pattern? Should there be an else-if
relationship, or is it valid to process both in sequence?
More information about the test-report
mailing list