| Message ID | 20260920072127.1278984-1-hayatake396@gmail.com |
|---|---|
| State | Under Review |
| Delegated to: | Anthony Nguyen |
| Headers | show |
| Series | [iwl-net,v2] ice: fix empty PTYPE set for GTP RSS profiles | expand |
> -----Original Message----- > From: Takeru Hayasaka <hayatake396@gmail.com> > Sent: 20 September 2026 12:51 > To: intel-wired-lan@lists.osuosl.org > Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; netdev@vger.kernel.org; marcin.szycik@linux.intel.com; Nowlin, Alexander <alexander.nowlin@intel.com>; Takeru > Hayasaka <hayatake396@gmail.com> > Subject: [PATCH iwl-net v2] ice: fix empty PTYPE set for GTP RSS profiles > > 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(-) > Tested-by: Singh, Ayush1X < ayush1x.singh@intel.com > (A Contingent worker at Intel)
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;
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(-) base-commit: 1cd23ca80784223fa2204e16203f754da4e821f8