From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BAD8C3EBF16 for ; Fri, 20 Feb 2026 07:30:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.9 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771572629; cv=none; b=MMqKtnBVTxFpr1k3zcJX1EYnmp+dfwts1+xkI7ha5Z1sHOMZIRbNa8yIfMzxXDnuXGIaEuSjlFULeKdtRG7ZUHz0tkhI3wB5uDgv+7lcxkAI9M+o/IlXIVeDmUux5YfxoP5jCIHKASO7I9gg8yQ+KNCF+6bbpRaeRR7F578xlYE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771572629; c=relaxed/simple; bh=lyp5Xhf9Uz/O9UFSOZCogRvPaliG7+luXfZB0IaqxBM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=MqzXCEeYWFwfCtz1xcl0tEEofH0+XJ5Yb4oISzSHEuvDyLKWalHijVtHUppCewlzWe7pc/aCEGa2uba6OqpGLV4Usl4IWIBsvnXxE9oSj+jRPo10UqO7qUJDMNXCa4Pqj4qgbSgMgVswLag21jEXPQRcdfVRrnxxdLkItTBDpEI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=aqVr2yZz; arc=none smtp.client-ip=198.175.65.9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="aqVr2yZz" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1771572629; x=1803108629; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=lyp5Xhf9Uz/O9UFSOZCogRvPaliG7+luXfZB0IaqxBM=; b=aqVr2yZz6XYwLcur0CdX9i+HWM6vrSdmAo2qq2nrB1ekME5KTsfqiLae jl1BfeD71ILYXKJGrNQxcOp+6w4ho8GQXAaaFDwzwTTAOOPUZXxAE+cCI hLLr1gBk4km5I4hkr5H0dAalng4od57mSt8WF6jC4H0BQWQirNTM8xCah auqHb08ahURQ07kRg+rOt40TMToq8We8JlVeQ+4HIQuFFpjHRfti0QqGI Osa9VeWX81ouCFAYjtK+/uX8rNucsHniSJeifr/SHl5TfTqeP7bMpBan/ cwc9TmlOCIhxx8dFYRlKznkecC6IODmnJinSnyb4OhyijoXqBOJjnB2CM g==; X-CSE-ConnectionGUID: 2OKjL6+6QHCjT2F9S69kOg== X-CSE-MsgGUID: QIE1ZIp9T12d9h2FFZAU5g== X-IronPort-AV: E=McAfee;i="6800,10657,11706"; a="95286632" X-IronPort-AV: E=Sophos;i="6.21,301,1763452800"; d="scan'208";a="95286632" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2026 23:30:29 -0800 X-CSE-ConnectionGUID: S34A9OsoSzmWV9puGqNVmA== X-CSE-MsgGUID: r4Sjk7xSQ+uXnwaujUPQQw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,301,1763452800"; d="scan'208";a="219289830" Received: from amlin-019-225.igk.intel.com ([10.102.19.225]) by orviesa004.jf.intel.com with ESMTP; 19 Feb 2026 23:30:26 -0800 From: Aleksandr Loktionov To: intel-wired-lan@lists.osuosl.org Cc: netdev@vger.kernel.org, anthony.l.nguyen@intel.com, horms@kernel.org, marcin.szycik@linux.intel.com Subject: [PATCH iwl-next v3 0/2] ice: implement symmetric RSS hash configuration Date: Fri, 20 Feb 2026 08:30:23 +0100 Message-ID: <20260220073025.654391-1-aleksandr.loktionov@intel.com> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The ice driver has advertised symmetric RSS support via supported_input_xfrm since the capability was added, but ice_set_rxfh() ignored the input_xfrm parameter entirely, so enabling symmetric hashing had no actual effect. This series fixes that. Patch 1 extends the ethtool core so that drivers hashing GTP flows on TEID can report it honestly without blocking symmetric-xor configuration. Patch 2 wires up the ice driver. The need for patch 1 surfaced because GTP flow profiles in ice always include TEID in the hash. ethtool_check_flow_types() calls get_rxfh_fields() for every hashable flow type before allowing symmetric-xor; ethtool_rxfh_config_is_sym() rejected any bitmap containing RXH_GTP_TEID since it has no src/dst counterpart. TEID is the same value in both tunnel directions, so this rejection is incorrect: including it does not break symmetry. Rather than hiding TEID from the reported fields (which would silently misrepresent hardware behaviour), patch 1 fixes the validator, and patch 2 reports TEID honestly. Tested with tools/testing/selftests/drivers/net/hw/rss_input_xfrm.py on an E810 card running kernel 6.19-rc8. --- v2 -> v3: - Split into 2 patches: ethtool core fix separate from driver change - Drop the RXH_GTP_TEID stripping workaround from the driver; instead fix ethtool_rxfh_config_is_sym() to accept TEID as intrinsically symmetric (patch 1) - Fix ice_get_rxfh_fields(): the v2 unconditional assignment "nfc->data = ICE_RSS_ALLOWED_FIELDS" clobbered fields set earlier in the same function; replaced with pair-completion using |= so only the missing half of a partial pair is filled in - Remove ICE_RSS_ALLOWED_FIELDS define (no longer needed) - Report RXH_GTP_TEID honestly for GTP flow types v1 -> v2: - Preserve valid symmetric RSS fields instead of overwriting nfc->data unconditionally Aleksandr Loktionov (2): ethtool: treat RXH_GTP_TEID as intrinsically symmetric ice: implement symmetric RSS hash configuration drivers/net/ethernet/intel/ice/ice_ethtool.c | 48 +++++++++++++--- drivers/net/ethernet/intel/ice/ice_lib.c | 7 ++- drivers/net/ethernet/intel/ice/ice_lib.h | 1 + net/ethtool/common.c | 3 + 4 files changed, 47 insertions(+), 12 deletions(-) -- 2.43.0