[PATCH iwl-net v2] ice: fix empty PTYPE set for GTP RSS profiles

[PATCH iwl-net v2] ice: fix empty PTYPE set for GTP RSS profiles

[Takeru Hayasaka]

Configuring RSS for GTP flows via ethtool, e.g.

  ethtool -N <if> rx-flow-hash gtpu4 sde

is accepted but has no effect: the hash of GTP-U packets does not
include the TEID, so all traffic between a given SGW/PGW pair lands on
a single Rx queue. The GTP RSS configurations the driver installs by
default at VSI init are affected the same way.

ice_flow_set_rss_seg_info() does not set IPV_OTHER on GTP segments, and
such a segment carries no L4 header bit either. ice_flow_proc_seg_hdrs()
therefore takes the "no L4" branch and ANDs the PTYPE set with
ice_ptypes_ipv4_ofos_no_l4, or ice_ptypes_ipv4_il_no_l4 for the inner
segment. Neither holds a GTP PTYPE, so ANDing with ice_ptypes_gtpu
leaves the set empty: the profile matches no packet at all and the
configured TEID field never enters the hash.

Set IPV_OTHER on GTP segments so that the tunnel-inclusive PTYPE sets
are selected instead, which do contain the GTP PTYPEs. Skip segments
that carry an L4 header bit, because the VF path strips IPV_OTHER from
those on purpose.

Verified on E810 (kernel 7.2-rc2, COMMS DDP 1.3.63.0) by reading the RSS
hash from the Rx descriptor: GTP-U traffic varying only the TEID goes
from one constant hash on a single Rx queue to 4096 distinct hashes
across all Rx queues. The same holds for inner IPv6 (gtpu6) and for a
PDU session container extension header (gtpu4e); plain UDP flows are
unaffected.

Signed-off-by: Takeru Hayasaka <hayatake396@gmail.com>
---
v2:
 - Ignore IPV_OTHER in ice_get_rss_cfg() so "ethtool -n" reports the
   GTP fields again (reported by Intel validation)
 - Do not set IPV_OTHER on GTP segments that carry an L4 header bit
v1: https://lore.kernel.org/intel-wired-lan/20260714192302.631428-1-hayatake396@gmail.com/

 drivers/net/ethernet/intel/ice/ice_flow.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_flow.c b/drivers/net/ethernet/intel/ice/ice_flow.c
index 121552c644cd..27de6048ebcc 100644
--- a/drivers/net/ethernet/intel/ice/ice_flow.c
+++ b/drivers/net/ethernet/intel/ice/ice_flow.c
@@ -2088,6 +2088,15 @@ ice_flow_set_rss_seg_info(struct ice_flow_seg_info *segs, u8 seg_cnt,
 
 	ICE_FLOW_SET_HDRS(seg, cfg->addl_hdrs);
 
+	/* A GTP segment without an L4 header bit would select the "no L4"
+	 * PTYPE sets, which hold no GTP PTYPE at all. VF requests that do
+	 * carry an L4 bit drop IPV_OTHER on purpose, so leave those alone.
+	 */
+	if ((seg->hdrs & (ICE_FLOW_SEG_HDR_GTPU | ICE_FLOW_SEG_HDR_GTPC |
+			  ICE_FLOW_SEG_HDR_GTPC_TEID)) &&
+	    !(seg->hdrs & ICE_FLOW_SEG_HDRS_L4_MASK_NO_OTHER))
+		seg->hdrs |= ICE_FLOW_SEG_HDR_IPV_OTHER;
+
 	/* set outer most header */
 	if (cfg->hdr_type == ICE_RSS_INNER_HEADERS_W_OUTER_IPV4)
 		segs[ICE_RSS_OUTER_HEADERS].hdrs |= ICE_FLOW_SEG_HDR_IPV4 |
@@ -3002,9 +3011,10 @@ u64 ice_get_rss_cfg(struct ice_hw *hw, u16 vsi_handle, u32 hdrs, bool *symm)
 		return ICE_HASH_INVALID;
 
 	mutex_lock(&hw->rss_locks);
+	/* IPV_OTHER is set on GTP segments internally, ethtool never asks for it */
 	list_for_each_entry(r, &hw->rss_list_head, l_entry)
 		if (test_bit(vsi_handle, r->vsis) &&
-		    r->hash.addl_hdrs == hdrs) {
+		    (r->hash.addl_hdrs & ~ICE_FLOW_SEG_HDR_IPV_OTHER) == hdrs) {
 			rss_hash = r->hash.hash_flds;
 			*symm = r->hash.symm;
 			break;

base-commit: 1cd23ca80784223fa2204e16203f754da4e821f8
-- 
2.43.0