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 <[email protected]> --- 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/[email protected]/ 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
