From nobody Sat Feb 7 11:38:20 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (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 4A0E33F075E; Tue, 20 Jan 2026 10:34:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768905287; cv=none; b=nYMRgKi0vN/wtofAHVvcIh9ZdzYQcQmWZqAYY1ypmrQgMrJRV5zIX8uv/OlkusMrYn++CTs8Um8eY+HfsbjHEa4cYwZ5zt1j+OhkSVsH62jYdcMPflpRWJoEPZT7WgiUjcXeewvv/MzGP/o+UMdiqcKfimVzOS5kvPQNuvw4l6c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768905287; c=relaxed/simple; bh=AwWlBBz026f2nkwvTcJ3OLUW52WxYFLm2Wz5hZ0v4yo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=G51fN7Z8tpnbmu2xk1vjukGj16UdK54O1oIiwzpS0lJ8RXhM04bClxtR93dR4C2poipCdCYQudWfxy4X/l+1Dui7s0Q+iWcaOpywwlfVEDJYBvauTCYWNoLNeLdSgvYxUpqp4UPoZ0R6oU/CURs+KZZIpqP5V87sQAKwjrgHMDs= 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=VJPrHc7I; arc=none smtp.client-ip=198.175.65.18 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="VJPrHc7I" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1768905285; x=1800441285; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=AwWlBBz026f2nkwvTcJ3OLUW52WxYFLm2Wz5hZ0v4yo=; b=VJPrHc7IZ+ZCdKPevHmiBsBAWR6h0jwgVuuvcnKT83f9eFctmrDJFGK4 mcegvTU12+DW/J7dtGEC0ERogG5FbkPQZMlB2kuYxB6nBQg4bV8LTls9S PJ37Yata+ojfzLZ4JBl+XXbg+Zgtavo4+kXsMD9L+9zzioiSVn0gPzLYt CmzdfBhZLS76dwllMI7YNLnkGnp0bOxnSITzjiSMpE7Kgi8qdOScOSA9C WJfJrHNw4OykNFovIchDGF6p2Q7xFF836tNxGvB3ej9rBRZ3qv4AQujkP 7ETaR9jZcg4gL9GA8fC/yqgY71iFaJ2/iXpGlVLknCHZ+A3Vb0Wub9Ct/ Q==; X-CSE-ConnectionGUID: 05l9kJCDQJO/J9Rg7iXS+A== X-CSE-MsgGUID: u70CkskgSJGIlsnwA6rvjA== X-IronPort-AV: E=McAfee;i="6800,10657,11676"; a="70161731" X-IronPort-AV: E=Sophos;i="6.21,240,1763452800"; d="scan'208";a="70161731" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2026 02:34:44 -0800 X-CSE-ConnectionGUID: 4BGJFGOEQIiU8fDqeyCbuQ== X-CSE-MsgGUID: ghSQDjC1Qvq1JstJpuIj2w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,240,1763452800"; d="scan'208";a="210935842" Received: from hpe-dl385gen10.igk.intel.com ([10.91.240.117]) by fmviesa004.fm.intel.com with ESMTP; 20 Jan 2026 02:34:43 -0800 From: Jakub Slepecki To: intel-wired-lan@lists.osuosl.org Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, przemyslaw.kitszel@intel.com, anthony.l.nguyen@intel.com, michal.swiatkowski@linux.intel.com, jakub.slepecki@intel.com, aleksandr.loktionov@intel.com Subject: [PATCH iwl-next v3 1/8] ice: in dvm, use outer VLAN in MAC,VLAN lookup Date: Tue, 20 Jan 2026 11:34:32 +0100 Message-ID: <20260120103440.892326-2-jakub.slepecki@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260120103440.892326-1-jakub.slepecki@intel.com> References: <20260120103440.892326-1-jakub.slepecki@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Organization: Intel Technology Poland sp. z o.o. - ul. Slowackiego 173, 80-298 Gdansk - KRS 101882 - NIP 957-07-52-316 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" In double VLAN mode (DVM), outer VLAN is located a word earlier in the field vector compared to the single VLAN mode. We already modify ICE_SW_LKUP_VLAN to use it but ICE_SW_LKUP_MAC_VLAN was left untouched, causing the lookup to match any packet with one or no layer of Dot1q. This change enables to fix cross-vlan loopback traffic using MAC,VLAN lookups. Reviewed-by: Aleksandr Loktionov Reviewed-by: Michal Swiatkowski Signed-off-by: Jakub Slepecki --- No changes in v3. No changes in v2. --- drivers/net/ethernet/intel/ice/ice_vlan_mode.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/net/ethernet/intel/ice/ice_vlan_mode.c b/drivers/net/e= thernet/intel/ice/ice_vlan_mode.c index fb526cb84776..68a7b05de44e 100644 --- a/drivers/net/ethernet/intel/ice/ice_vlan_mode.c +++ b/drivers/net/ethernet/intel/ice/ice_vlan_mode.c @@ -198,6 +198,7 @@ static bool ice_is_dvm_supported(struct ice_hw *hw) #define ICE_SW_LKUP_VLAN_LOC_LKUP_IDX 1 #define ICE_SW_LKUP_VLAN_PKT_FLAGS_LKUP_IDX 2 #define ICE_SW_LKUP_PROMISC_VLAN_LOC_LKUP_IDX 2 +#define ICE_SW_LKUP_MAC_VLAN_LOC_LKUP_IDX 4 #define ICE_PKT_FLAGS_0_TO_15_FV_IDX 1 static struct ice_update_recipe_lkup_idx_params ice_dvm_dflt_recipes[] =3D= { { @@ -234,6 +235,17 @@ static struct ice_update_recipe_lkup_idx_params ice_dv= m_dflt_recipes[] =3D { .mask_valid =3D false, /* use pre-existing mask */ .lkup_idx =3D ICE_SW_LKUP_PROMISC_VLAN_LOC_LKUP_IDX, }, + { + /* Similarly to ICE_SW_LKUP_VLAN, change to outer/single VLAN in + * DVM + */ + .rid =3D ICE_SW_LKUP_MAC_VLAN, + .fv_idx =3D ICE_EXTERNAL_VLAN_ID_FV_IDX, + .ignore_valid =3D true, + .mask =3D 0, + .mask_valid =3D false, + .lkup_idx =3D ICE_SW_LKUP_MAC_VLAN_LOC_LKUP_IDX, + }, }; =20 /** --=20 2.43.0 From nobody Sat Feb 7 11:38:20 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (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 06B2D40F8E6; Tue, 20 Jan 2026 10:34:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768905288; cv=none; b=lAZukqtVotMuzDrx2UBbbhXnJDlu5T3j9MMQx64bM9f4PE/S0rEWOGWkQaKV73a9WPw+AWMQtm0iiezYfV6yHoeVh0R5tEbQensxFJ0ayBML+MG8QwmlqkjRzDiNERiY2Og58qO3tRkwIaD3SZxx2pXCUt3f1xZl1p7GNTKv0M0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768905288; c=relaxed/simple; bh=e0OB/xX+CgF3GE3pSfyBLVlvom42Si0uRCJQfxycEa4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CtJ4gIePOdYI/GK4dA3EknijJACc2W8UXxTh4Ed6OWZDtpXjNnEZ9Q1dq6DvSlMS7MfkPeL0j450UrmRpg9L21ABvwAB/VFpuGAzFrbviQ4IMm/JlORdIh8sq0IkBIdvVwZsj9pQQsbvn89vEXOm8VNAS1NuIywxra9rPDDl8xg= 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=RP2yD6kV; arc=none smtp.client-ip=198.175.65.18 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="RP2yD6kV" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1768905287; x=1800441287; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=e0OB/xX+CgF3GE3pSfyBLVlvom42Si0uRCJQfxycEa4=; b=RP2yD6kV6jSzepB9aehx4vO75s4scFJnEIIMAAm4LvXOpX7yOyjAtgIK H2luVgyIE2sX0wAwwjp/qobS0dQB0BgUkpWj/0m2hwEA00LTIf1VldOKc IJ5qLbLlyIkKf51dtV9tX++3itFJls4N6906uKPVsejgM8O0vYpfJeKzR D+9lXmZJPsx44efV7g+XBp/WOEtbg0fLzzZV3t2oeUFyujjSYanPrFpNP kIhFyZ+0JxlttolQKVq8F7lxpT4kBXJrwcJkPfg//+161kaJOyC6o+XeH jeHqOYkiYsj8zaL+MaNNtqdlMmGKjNMYDtxbIgJOID7J3ZMv4dIfoqTtU A==; X-CSE-ConnectionGUID: rVfoYeOuTDaHPEn1brPqGg== X-CSE-MsgGUID: uNCnUbKtRLWxi8bLbQvbpg== X-IronPort-AV: E=McAfee;i="6800,10657,11676"; a="70161736" X-IronPort-AV: E=Sophos;i="6.21,240,1763452800"; d="scan'208";a="70161736" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2026 02:34:46 -0800 X-CSE-ConnectionGUID: CKLd6RpjRg+Pt+CqhN9/FQ== X-CSE-MsgGUID: 8WrafF7ES8+s/ZTOJtjQIQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,240,1763452800"; d="scan'208";a="210935849" Received: from hpe-dl385gen10.igk.intel.com ([10.91.240.117]) by fmviesa004.fm.intel.com with ESMTP; 20 Jan 2026 02:34:45 -0800 From: Jakub Slepecki To: intel-wired-lan@lists.osuosl.org Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, przemyslaw.kitszel@intel.com, anthony.l.nguyen@intel.com, michal.swiatkowski@linux.intel.com, jakub.slepecki@intel.com, aleksandr.loktionov@intel.com Subject: [PATCH iwl-next v3 2/8] ice: allow creating mac,vlan filters along mac filters Date: Tue, 20 Jan 2026 11:34:33 +0100 Message-ID: <20260120103440.892326-3-jakub.slepecki@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260120103440.892326-1-jakub.slepecki@intel.com> References: <20260120103440.892326-1-jakub.slepecki@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Organization: Intel Technology Poland sp. z o.o. - ul. Slowackiego 173, 80-298 Gdansk - KRS 101882 - NIP 957-07-52-316 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Among other uses, MAC filters are currently used to forward loopback traffic between VSIs. However, they only match destination MAC addresses making them prone to mistakes when handling traffic within multiple VLANs and especially across the boundaries. Allows the driver to create MAC,VLAN filters in the same flow as MAC-only filters completely interchangeably. This is intended to be used to forward the loopback traffic only within the boundaries of particular VLANs. Reviewed-by: Michal Swiatkowski Reviewed-by: Aleksandr Loktionov Signed-off-by: Jakub Slepecki --- No changes in v3. No changes in v2. --- drivers/net/ethernet/intel/ice/ice_switch.c | 48 ++++++++++++++++----- 1 file changed, 38 insertions(+), 10 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethe= rnet/intel/ice/ice_switch.c index 84848f0123e7..0275e2910c6b 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.c +++ b/drivers/net/ethernet/intel/ice/ice_switch.c @@ -3606,6 +3606,29 @@ bool ice_vlan_fltr_exist(struct ice_hw *hw, u16 vlan= _id, u16 vsi_handle) return false; } =20 +/** + * ice_fltr_mac_address - Find MAC in filter + * @dst: output MAC address + * @info: information struct for the filter in question + * + * Return: 0 for success, %-ENXIO if no address was found in the filter + * information. + */ +static +int ice_fltr_mac_address(u8 *dst, struct ice_fltr_info *info) +{ + switch (info->lkup_type) { + case ICE_SW_LKUP_MAC: + ether_addr_copy(dst, info->l_data.mac.mac_addr); + return 0; + case ICE_SW_LKUP_MAC_VLAN: + ether_addr_copy(dst, info->l_data.mac_vlan.mac_addr); + return 0; + default: + return -ENXIO; + } +} + /** * ice_add_mac - Add a MAC address based filter rule * @hw: pointer to the hardware structure @@ -3614,16 +3637,19 @@ bool ice_vlan_fltr_exist(struct ice_hw *hw, u16 vla= n_id, u16 vsi_handle) int ice_add_mac(struct ice_hw *hw, struct list_head *m_list) { struct ice_fltr_list_entry *m_list_itr; - int status =3D 0; + int err; =20 if (!m_list || !hw) return -EINVAL; =20 list_for_each_entry(m_list_itr, m_list, list_entry) { - u8 *add =3D &m_list_itr->fltr_info.l_data.mac.mac_addr[0]; + u8 addr[ETH_ALEN]; u16 vsi_handle; u16 hw_vsi_id; =20 + err =3D ice_fltr_mac_address(addr, &m_list_itr->fltr_info); + if (err || is_zero_ether_addr(addr)) + return -EINVAL; m_list_itr->fltr_info.flag =3D ICE_FLTR_TX; vsi_handle =3D m_list_itr->fltr_info.vsi_handle; if (!ice_is_vsi_valid(hw, vsi_handle)) @@ -3634,17 +3660,19 @@ int ice_add_mac(struct ice_hw *hw, struct list_head= *m_list) if (m_list_itr->fltr_info.src_id !=3D ICE_SRC_ID_VSI) return -EINVAL; m_list_itr->fltr_info.src =3D hw_vsi_id; - if (m_list_itr->fltr_info.lkup_type !=3D ICE_SW_LKUP_MAC || - is_zero_ether_addr(add)) + if (m_list_itr->fltr_info.lkup_type !=3D ICE_SW_LKUP_MAC && + m_list_itr->fltr_info.lkup_type !=3D ICE_SW_LKUP_MAC_VLAN) return -EINVAL; =20 - m_list_itr->status =3D ice_add_rule_internal(hw, ICE_SW_LKUP_MAC, - m_list_itr); + m_list_itr->status =3D + ice_add_rule_internal(hw, + m_list_itr->fltr_info.lkup_type, + m_list_itr); if (m_list_itr->status) return m_list_itr->status; } =20 - return status; + return 0; } =20 /** @@ -4055,7 +4083,7 @@ int ice_remove_mac(struct ice_hw *hw, struct list_hea= d *m_list) enum ice_sw_lkup_type l_type =3D list_itr->fltr_info.lkup_type; u16 vsi_handle; =20 - if (l_type !=3D ICE_SW_LKUP_MAC) + if (l_type !=3D ICE_SW_LKUP_MAC && l_type !=3D ICE_SW_LKUP_MAC_VLAN) return -EINVAL; =20 vsi_handle =3D list_itr->fltr_info.vsi_handle; @@ -4066,7 +4094,7 @@ int ice_remove_mac(struct ice_hw *hw, struct list_hea= d *m_list) ice_get_hw_vsi_num(hw, vsi_handle); =20 list_itr->status =3D ice_remove_rule_internal(hw, - ICE_SW_LKUP_MAC, + l_type, list_itr); if (list_itr->status) return list_itr->status; @@ -4507,6 +4535,7 @@ ice_remove_vsi_lkup_fltr(struct ice_hw *hw, u16 vsi_h= andle, =20 switch (lkup) { case ICE_SW_LKUP_MAC: + case ICE_SW_LKUP_MAC_VLAN: ice_remove_mac(hw, &remove_list_head); break; case ICE_SW_LKUP_VLAN: @@ -4516,7 +4545,6 @@ ice_remove_vsi_lkup_fltr(struct ice_hw *hw, u16 vsi_h= andle, case ICE_SW_LKUP_PROMISC_VLAN: ice_remove_promisc(hw, lkup, &remove_list_head); break; - case ICE_SW_LKUP_MAC_VLAN: case ICE_SW_LKUP_ETHERTYPE: case ICE_SW_LKUP_ETHERTYPE_MAC: case ICE_SW_LKUP_DFLT: --=20 2.43.0 From nobody Sat Feb 7 11:38:20 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (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 E38F040FD93; Tue, 20 Jan 2026 10:34:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768905290; cv=none; b=QJZ2WHpWi4t47wMiNfld+Y/vpVJMt4FrnpXWV9ZBUStCTRnazDJVhXqSzaLW+gkQ+AkaRUJufU926NMc2SJ2/rwC0f4H1BiNrp+o9AKteDb0ByImyAqnRgjwA2QG5sQgrtNwzrJbBWAP6a3Xx66wwjnEUT/u73MWTG42xb1CPnY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768905290; c=relaxed/simple; bh=aDADJULyrOXAsvln2yMJyhXY1pU5VH5XFxcMbCSZkys=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kVlroVf1w235hsLpQ5e5LFLlZ+K44fa5ynTKc+IfhFxLlSm6ODoo+kf/LZ8hwKiLOWGOh8D1xlhayT7xK+CBu4AbncXyGv4zcJZMKxS3gePdk+IX0wwYKKrfL5HNauBxwjH82Ig8nLq1RkPARKSzHjEPAb7TJgNI9OCuOD2P99w= 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=L2VZe6kN; arc=none smtp.client-ip=198.175.65.18 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="L2VZe6kN" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1768905289; x=1800441289; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=aDADJULyrOXAsvln2yMJyhXY1pU5VH5XFxcMbCSZkys=; b=L2VZe6kNCM3mJ5p2XUQYmtvbF113TMRABVW4SztMA2iipDstGV9BCu3v ZeXpvUzu5ojQwSgV8yvqtaDpdz1HNUZYaXnnTXmLRTTQoBVm+xjxggJH+ lY3BOJxnX+GU1MRkYaJe3iYlJL88+wWaA4olK5HakOUxlCiLVfTNDpyHC yNzh//oTEzv9C5Uet77aNJLM27oTuI3gkzeGMcG1hh4ra0WpRGYOqq85L oruSY7VweHb45MKeCOw9Jegl8YO+qBqL5FRW65QGrjXDAAIWRzjRS/5vT x4b32FCGeGcaBC6fxGXdY4fSI9rQowrEdKM2D1iHjQsqHGqWbm1H6h2Ub A==; X-CSE-ConnectionGUID: nEmRUv3TRMCqFe9v7pFLHA== X-CSE-MsgGUID: UKNwLt+JQwWnbAYwjCuRGQ== X-IronPort-AV: E=McAfee;i="6800,10657,11676"; a="70161741" X-IronPort-AV: E=Sophos;i="6.21,240,1763452800"; d="scan'208";a="70161741" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2026 02:34:48 -0800 X-CSE-ConnectionGUID: NvYLKDxGQyWBfxmtwkNDqA== X-CSE-MsgGUID: fapk4ngNSNiiB7Fsj00qqg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,240,1763452800"; d="scan'208";a="210935853" Received: from hpe-dl385gen10.igk.intel.com ([10.91.240.117]) by fmviesa004.fm.intel.com with ESMTP; 20 Jan 2026 02:34:47 -0800 From: Jakub Slepecki To: intel-wired-lan@lists.osuosl.org Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, przemyslaw.kitszel@intel.com, anthony.l.nguyen@intel.com, michal.swiatkowski@linux.intel.com, jakub.slepecki@intel.com, aleksandr.loktionov@intel.com Subject: [PATCH iwl-next v3 3/8] ice: do not check for zero mac when creating mac filters Date: Tue, 20 Jan 2026 11:34:34 +0100 Message-ID: <20260120103440.892326-4-jakub.slepecki@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260120103440.892326-1-jakub.slepecki@intel.com> References: <20260120103440.892326-1-jakub.slepecki@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Organization: Intel Technology Poland sp. z o.o. - ul. Slowackiego 173, 80-298 Gdansk - KRS 101882 - NIP 957-07-52-316 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" A zero MAC address was considered a special case while creating a new MAC filter. There is no particular reason for that other than the fact that the union containing it was assumed to be zeroed out. Now, address is pulled out of the union by ice_fltr_mac_address which checks all of the previously assumed zero-address cases and returns an error if they are hit. Reviewed-by: Aleksandr Loktionov Reviewed-by: Michal Swiatkowski Signed-off-by: Jakub Slepecki --- No changes in v3. No changes in v2. --- drivers/net/ethernet/intel/ice/ice_switch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethe= rnet/intel/ice/ice_switch.c index 0275e2910c6b..04e5d653efce 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.c +++ b/drivers/net/ethernet/intel/ice/ice_switch.c @@ -3648,7 +3648,7 @@ int ice_add_mac(struct ice_hw *hw, struct list_head *= m_list) u16 hw_vsi_id; =20 err =3D ice_fltr_mac_address(addr, &m_list_itr->fltr_info); - if (err || is_zero_ether_addr(addr)) + if (err) return -EINVAL; m_list_itr->fltr_info.flag =3D ICE_FLTR_TX; vsi_handle =3D m_list_itr->fltr_info.vsi_handle; --=20 2.43.0 From nobody Sat Feb 7 11:38:20 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (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 F3993410D07; Tue, 20 Jan 2026 10:34:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768905293; cv=none; b=hXIjOuASiqb08Zeyz2e5CAulO/9OTVW9/3lIO0L8bOB1nbBXxvmvBI60pHP3vZIgUlQ/HGzl58KzfPO2yH34GxfUSkMS8bhe2WfKf4hOFSZz3Ydy2h5b7gQEOWO/BINq7ZCWmOhk7ChNgOGfu9fNbsg5KxvqsEWFTq2KyaRhBrI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768905293; c=relaxed/simple; bh=iC3XdbETtmivl7MiNG080jOCyV8qw/2J329iqKv9uzM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nM2emJbyuABxov+wc7DmL0w78vXhsNwyDwsECgLCnnCEzjtr5Z8tOnBi6CVymDVf4g3u49qBSx0FzhdkDNOOLgE6gULvmj8ShBPb0Za0ar4bWAD9Lh8mUVuSXmITzmcwEkXbFVRYdP2+bWbiOIdLEVswkJI17w6IbQ9fSBAr8OI= 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=iNdSpgAi; arc=none smtp.client-ip=198.175.65.18 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="iNdSpgAi" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1768905291; x=1800441291; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=iC3XdbETtmivl7MiNG080jOCyV8qw/2J329iqKv9uzM=; b=iNdSpgAi/sqn5rIcrW5PUkrN0VK6FUT4ymjyDxSVU3rJ8KsGK9JrURKr AOj+BMxuyVimwOcBCbd1RkKV/geDBS8VIauSN7Z+2nm/tUSpFyCuSG/of 80aQkqfHvOkUfS10FMlPaNcCBlFC+DnUTXLTiqJxu7nNkWL4CNW0JXCjC JllZ6xhWbFUWdQev5n2e4vAgLT/o844dUbl4DDzOaCIrHUSaYmX21YxuJ BpdDi2ni95p9oYfgpnjH4p1V4m6zR/02CqyaLEGCcIMuCX34yMTEJoWxb dNlqz2rz6z9lXyOdXQHt0p3IskkzJ++LGEQq47CE7iZ4E7G7831A3ZsBU A==; X-CSE-ConnectionGUID: soH+Eci3RLaWgBE4ArP2Vg== X-CSE-MsgGUID: eXxREXPlQmq3puwiNU8lUg== X-IronPort-AV: E=McAfee;i="6800,10657,11676"; a="70161748" X-IronPort-AV: E=Sophos;i="6.21,240,1763452800"; d="scan'208";a="70161748" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2026 02:34:50 -0800 X-CSE-ConnectionGUID: ipVBg8rASC6sTNAfBhD0LA== X-CSE-MsgGUID: lNdC1XsPSC+zrigQGNbj/g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,240,1763452800"; d="scan'208";a="210935856" Received: from hpe-dl385gen10.igk.intel.com ([10.91.240.117]) by fmviesa004.fm.intel.com with ESMTP; 20 Jan 2026 02:34:49 -0800 From: Jakub Slepecki To: intel-wired-lan@lists.osuosl.org Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, przemyslaw.kitszel@intel.com, anthony.l.nguyen@intel.com, michal.swiatkowski@linux.intel.com, jakub.slepecki@intel.com, aleksandr.loktionov@intel.com Subject: [PATCH iwl-next v3 4/8] ice: allow overriding lan_en, lb_en in switch Date: Tue, 20 Jan 2026 11:34:35 +0100 Message-ID: <20260120103440.892326-5-jakub.slepecki@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260120103440.892326-1-jakub.slepecki@intel.com> References: <20260120103440.892326-1-jakub.slepecki@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Organization: Intel Technology Poland sp. z o.o. - ul. Slowackiego 173, 80-298 Gdansk - KRS 101882 - NIP 957-07-52-316 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Currently, lan_en and lb_en are determined based on switching mode, destination MAC, and the lookup type, action type and flags of the rule in question. This gives little to no options for the user (such as ice_fltr.c) to enforce rules to behave in a specific way. Such functionality is needed to work with pairs of rules, for example, when handling MAC forward to LAN together with MAC,VLAN forward to loopback rules pair. This case could not be easily deduced in a context of a single filter without adding some guessing logic or a specialized flag. Add a slightly more generic flag to the lan_en and lb_en themselves for the ice_fltr.c to request specific destination flags later on, for example, to override both values: struct ice_fltr_info fi; fi.lb_en =3D ICE_FLTR_INFO_LB_LAN_FORCE_ENABLED; fi.lan_en =3D ICE_FLTR_INFO_LB_LAN_FORCE_DISABLED; Signed-off-by: Jakub Slepecki --- I considered a resend or bumping the old thread, because we did not finish the discussion last time with Aleksandr, but I feel like this version addresses most if not all of the points that were made. One exception is that I did not split the fields, but that was only one of the solutions. Nonetheless, this should be overall a good starting point for a discussion. Changes in v3: - LB_LAN masks and values no longer rely on boolean promotion. - ice_fill_sw_info() deals with u8 the entire time instead of building building lb_en and lan_en values at the end from booleans. Changes in v2: - Use FIELD_GET et al. when handling fi.lb_en and fi.lan_en. - Rename /LB_LAN/s/_MASK/_M/ because one of uses would need to break line --- drivers/net/ethernet/intel/ice/ice_switch.c | 25 +++++++++++++-------- drivers/net/ethernet/intel/ice/ice_switch.h | 19 +++++++++++++--- 2 files changed, 32 insertions(+), 12 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethe= rnet/intel/ice/ice_switch.c index 04e5d653efce..3caccd798220 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.c +++ b/drivers/net/ethernet/intel/ice/ice_switch.c @@ -2534,12 +2534,14 @@ int ice_get_initial_sw_cfg(struct ice_hw *hw) * * This helper function populates the lb_en and lan_en elements of the pro= vided * ice_fltr_info struct using the switch's type and characteristics of the - * switch rule being configured. + * switch rule being configured. Elements are updated only if their FORCE= bit + * is not set. */ static void ice_fill_sw_info(struct ice_hw *hw, struct ice_fltr_info *fi) { - fi->lb_en =3D false; - fi->lan_en =3D false; + u8 lan_en =3D fi->lan_en; + u8 lb_en =3D fi->lb_en; + if ((fi->flag & ICE_FLTR_TX) && (fi->fltr_act =3D=3D ICE_FWD_TO_VSI || fi->fltr_act =3D=3D ICE_FWD_TO_VSI_LIST || @@ -2549,7 +2551,7 @@ static void ice_fill_sw_info(struct ice_hw *hw, struc= t ice_fltr_info *fi) * packets to the internal switch that will be dropped. */ if (fi->lkup_type !=3D ICE_SW_LKUP_VLAN) - fi->lb_en =3D true; + FIELD_MODIFY(ICE_FLTR_INFO_LB_LAN_VALUE_M, &lb_en, 1); =20 /* Set lan_en to TRUE if * 1. The switch is a VEB AND @@ -2578,14 +2580,19 @@ static void ice_fill_sw_info(struct ice_hw *hw, str= uct ice_fltr_info *fi) !is_unicast_ether_addr(fi->l_data.mac.mac_addr)) || (fi->lkup_type =3D=3D ICE_SW_LKUP_MAC_VLAN && !is_unicast_ether_addr(fi->l_data.mac.mac_addr))) - fi->lan_en =3D true; + FIELD_MODIFY(ICE_FLTR_INFO_LB_LAN_VALUE_M, + &lan_en, 1); } else { - fi->lan_en =3D true; + FIELD_MODIFY(ICE_FLTR_INFO_LB_LAN_VALUE_M, &lan_en, 1); } } =20 if (fi->flag & ICE_FLTR_TX_ONLY) - fi->lan_en =3D false; + FIELD_MODIFY(ICE_FLTR_INFO_LB_LAN_VALUE_M, &lan_en, 0); + if (!FIELD_GET(ICE_FLTR_INFO_LB_LAN_FORCE_M, lb_en)) + fi->lb_en =3D lb_en; + if (!FIELD_GET(ICE_FLTR_INFO_LB_LAN_FORCE_M, lan_en)) + fi->lan_en =3D lan_en; } =20 /** @@ -2669,9 +2676,9 @@ ice_fill_sw_rule(struct ice_hw *hw, struct ice_fltr_i= nfo *f_info, return; } =20 - if (f_info->lb_en) + if (FIELD_GET(ICE_FLTR_INFO_LB_LAN_VALUE_M, f_info->lb_en)) act |=3D ICE_SINGLE_ACT_LB_ENABLE; - if (f_info->lan_en) + if (FIELD_GET(ICE_FLTR_INFO_LB_LAN_VALUE_M, f_info->lan_en)) act |=3D ICE_SINGLE_ACT_LAN_ENABLE; =20 switch (f_info->lkup_type) { diff --git a/drivers/net/ethernet/intel/ice/ice_switch.h b/drivers/net/ethe= rnet/intel/ice/ice_switch.h index 671d7a5f359f..137eae878ab1 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.h +++ b/drivers/net/ethernet/intel/ice/ice_switch.h @@ -72,6 +72,14 @@ enum ice_src_id { ICE_SRC_ID_LPORT, }; =20 +#define ICE_FLTR_INFO_LB_LAN_VALUE_M BIT(0) +#define ICE_FLTR_INFO_LB_LAN_FORCE_M BIT(1) +#define ICE_FLTR_INFO_LB_LAN_FORCE_ENABLED \ + (FIELD_PREP_CONST(ICE_FLTR_INFO_LB_LAN_VALUE_M, 1) | \ + FIELD_PREP_CONST(ICE_FLTR_INFO_LB_LAN_FORCE_M, 1)) +#define ICE_FLTR_INFO_LB_LAN_FORCE_DISABLED \ + (FIELD_PREP_CONST(ICE_FLTR_INFO_LB_LAN_FORCE_M, 1)) + struct ice_fltr_info { /* Look up information: how to look up packet */ enum ice_sw_lkup_type lkup_type; @@ -131,9 +139,14 @@ struct ice_fltr_info { */ u8 qgrp_size; =20 - /* Rule creations populate these indicators basing on the switch type */ - u8 lb_en; /* Indicate if packet can be looped back */ - u8 lan_en; /* Indicate if packet can be forwarded to the uplink */ + /* Following members have two bits: VALUE and FORCE. Rule creation will + * populate VALUE bit of these members based on switch type, but only if + * their FORCE bit is not set. + * + * See ICE_FLTR_INFO_LB_LAN_VALUE_M and ICE_FLTR_INFO_LB_LAN_FORCE_M. + */ + u8 lb_en; /* VALUE bit: packet can be looped back */ + u8 lan_en; /* VALUE bit: packet can be forwarded to the uplink */ }; =20 struct ice_update_recipe_lkup_idx_params { --=20 2.43.0 From nobody Sat Feb 7 11:38:20 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (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 182CF410D2D; Tue, 20 Jan 2026 10:34:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768905295; cv=none; b=CD5ozQSgqzhKrJT/J6ChUdVcDttgl+fz/OM8xeqwIi2oqtYSmckWW6kdCp/c4/Rbw7vJBX0GhsZ51L1HwyW5W+oCYSUmrqd3l3qlOvHyhvGAx6kY1Jxu+TUEK/v4p1h9+fguK2ftzvqa9PLT5+uNmqgp5KtMkqoRZQA0cMF722s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768905295; c=relaxed/simple; bh=fHx6D75nNH7UK7zPn0EFhSdI4CnOvj2IIm7MiYdVpPI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FVhM8d4/r9z9o+lOnmMLi39piB3BN81jdPo7OkkZexaBaKzz/xnGO1DOTSWiODuj1mdIUs9kFFYrswCcgM8TJbSzqmBL78VaQ47HFrYsRgElRGIG8YicPWf0RVrmt8ukcWM8mxzUvNfVop3ix5pl7wwjggg0unC2EtaS0jPr1/Q= 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=BFlf03Oi; arc=none smtp.client-ip=198.175.65.18 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="BFlf03Oi" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1768905293; x=1800441293; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=fHx6D75nNH7UK7zPn0EFhSdI4CnOvj2IIm7MiYdVpPI=; b=BFlf03OiZqETRQ6OWNMccVMPEdY0wBX1c9B022CxVMIWwKx+EAIDTXXs lpDzWM6PF0DfjF9NA7PO04XUsnoartmLowqfR+ZYr9YqkFBSqGWlq+xO2 FdC3aZ+jsT5xshpsPTyNob+UA9ZKFmGSjJQSbevadJB9x3jv2HxU+ebqC AQUiumOr3KZ++j5iEY7FahebfQPTxvktx1YEdn3RjbQ9gl0dgrOxAFjKJ 1hxAYLRU6o/BUg2ltvjOQJP8q8PldaJ5g7kmopjB8aIOdcB9UXEQTAruQ JOzY6p+gE6T7u5rDrDcqpNefD70bgM6kKiDcJymALQRx5bxSs0gb9Nf9j Q==; X-CSE-ConnectionGUID: Y6isOIuLS2y2vqeNY5uq8w== X-CSE-MsgGUID: cOU/PzzmROmBc9FLAosnrA== X-IronPort-AV: E=McAfee;i="6800,10657,11676"; a="70161752" X-IronPort-AV: E=Sophos;i="6.21,240,1763452800"; d="scan'208";a="70161752" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2026 02:34:52 -0800 X-CSE-ConnectionGUID: MJ7YMCojQBuS26sLDqT3KA== X-CSE-MsgGUID: SsQNjIDISziwqr3UjNXIaw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,240,1763452800"; d="scan'208";a="210935866" Received: from hpe-dl385gen10.igk.intel.com ([10.91.240.117]) by fmviesa004.fm.intel.com with ESMTP; 20 Jan 2026 02:34:51 -0800 From: Jakub Slepecki To: intel-wired-lan@lists.osuosl.org Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, przemyslaw.kitszel@intel.com, anthony.l.nguyen@intel.com, michal.swiatkowski@linux.intel.com, jakub.slepecki@intel.com, aleksandr.loktionov@intel.com Subject: [PATCH iwl-next v3 5/8] ice: update mac,vlan rules when toggling between VEB and VEPA Date: Tue, 20 Jan 2026 11:34:36 +0100 Message-ID: <20260120103440.892326-6-jakub.slepecki@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260120103440.892326-1-jakub.slepecki@intel.com> References: <20260120103440.892326-1-jakub.slepecki@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Organization: Intel Technology Poland sp. z o.o. - ul. Slowackiego 173, 80-298 Gdansk - KRS 101882 - NIP 957-07-52-316 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When changing into VEPA mode MAC rules are modified to forward all traffic to the wire instead of allowing some packets to go into the loopback. MAC,VLAN rules may and will also be used to forward loopback traffic in VEB, so when we switch to VEPA, we want them to behave similarly to MAC-only rules. ice_vsi_update_bridge_mode() will now attempt a rollback of switch filters in case an update fails. If the rollback also fails, we will now return the rollback error instead of the initial error. Reviewed-by: Aleksandr Loktionov Signed-off-by: Jakub Slepecki --- Kept Aleksandr's reviewed-by per discussion. Testing hints: MAC,VLAN rules are created only if entire series is applied. The easiest way to test that rules were adjusted is to run traffic and observe what packets are sent to LAN. VEPA is expected to behave same as before the series. VEB is expected to (a) behave like VEPA if loopback traffic would cross VLANs, or (b) behave as before. Traffic from/to external hosts is expected to remain unchanged. =20 Refer to cover letter (0/8) for full network configuration. To change hwmode use: # bridge link set dev $pf hwmode {veb,vepa} Changes in v3: - Refer to reproduction in cover letter in current 5/8. Changes in v2: - Close open parenthesis in ice_vsi_update_bridge_mode() description. - Explain returns in ice_vsi_update_bridge_mode(). --- drivers/net/ethernet/intel/ice/ice_main.c | 48 +++++++++++++++++---- drivers/net/ethernet/intel/ice/ice_switch.c | 8 ++-- drivers/net/ethernet/intel/ice/ice_switch.h | 3 +- 3 files changed, 46 insertions(+), 13 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethern= et/intel/ice/ice_main.c index cb80b77d29fd..7b3ab69b8300 100644 --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -8208,8 +8208,16 @@ static int ice_vsi_update_bridge_mode(struct ice_vsi= *vsi, u16 bmode) * * Sets the bridge mode (VEB/VEPA) of the switch to which the netdev (VSI)= is * hooked up to. Iterates through the PF VSI list and sets the loopback mo= de (if - * not already set for all VSIs connected to this switch. And also update = the + * not already set for all VSIs connected to this switch). And also update= the * unicast switch filter rules for the corresponding switch of the netdev. + * + * Return: + * * %0 if mode was set, propagated to VSIs, and changes to filters were a= ll + * successful, + * * %-EINVAL if requested netlink attributes or bridge mode were invalid, + * * otherwise an error from VSI update, filter rollback, or filter update= is + * forwarded. This may include %-EINVAL. See ice_vsi_update_bridge_mode(= ) and + * ice_update_sw_rule_bridge_mode(). */ static int ice_bridge_setlink(struct net_device *dev, struct nlmsghdr *nlh, @@ -8219,8 +8227,8 @@ ice_bridge_setlink(struct net_device *dev, struct nlm= sghdr *nlh, struct ice_pf *pf =3D ice_netdev_to_pf(dev); struct nlattr *attr, *br_spec; struct ice_hw *hw =3D &pf->hw; + int rem, v, rb_err, err =3D 0; struct ice_sw *pf_sw; - int rem, v, err =3D 0; =20 pf_sw =3D pf->first_sw; /* find the attribute in the netlink message */ @@ -8230,6 +8238,7 @@ ice_bridge_setlink(struct net_device *dev, struct nlm= sghdr *nlh, =20 nla_for_each_nested_type(attr, IFLA_BRIDGE_MODE, br_spec, rem) { __u16 mode =3D nla_get_u16(attr); + u8 old_evb_veb =3D hw->evb_veb; =20 if (mode !=3D BRIDGE_MODE_VEPA && mode !=3D BRIDGE_MODE_VEB) return -EINVAL; @@ -8251,17 +8260,38 @@ ice_bridge_setlink(struct net_device *dev, struct n= lmsghdr *nlh, /* Update the unicast switch filter rules for the corresponding * switch of the netdev */ - err =3D ice_update_sw_rule_bridge_mode(hw); + err =3D ice_update_sw_rule_bridge_mode(hw, ICE_SW_LKUP_MAC); + if (err) { + /* evb_veb is expected to be already reverted in error + * path because of the potential rollback. + */ + hw->evb_veb =3D old_evb_veb; + goto err_without_rollback; + } + err =3D ice_update_sw_rule_bridge_mode(hw, ICE_SW_LKUP_MAC_VLAN); if (err) { - netdev_err(dev, "switch rule update failed, mode =3D %d err %d aq_err %= s\n", - mode, err, + /* ice_update_sw_rule_bridge_mode looks this up, so we + * must revert it before attempting a rollback. + */ + hw->evb_veb =3D old_evb_veb; + goto err_rollback_mac; + } + pf_sw->bridge_mode =3D mode; + continue; + +err_rollback_mac: + rb_err =3D ice_update_sw_rule_bridge_mode(hw, ICE_SW_LKUP_MAC); + if (rb_err) { + netdev_err(dev, "switch rule update failed, mode =3D %d err %d; rollbac= k failed, err %d aq_err %s\n", + mode, err, rb_err, libie_aq_str(hw->adminq.sq_last_status)); - /* revert hw->evb_veb */ - hw->evb_veb =3D (pf_sw->bridge_mode =3D=3D BRIDGE_MODE_VEB); - return err; + return rb_err; } =20 - pf_sw->bridge_mode =3D mode; +err_without_rollback: + netdev_err(dev, "switch rule update failed, mode =3D %d err %d aq_err %s= \n", + mode, err, libie_aq_str(hw->adminq.sq_last_status)); + return err; } =20 return 0; diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethe= rnet/intel/ice/ice_switch.c index 3caccd798220..3b526383b8ed 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.c +++ b/drivers/net/ethernet/intel/ice/ice_switch.c @@ -3067,10 +3067,12 @@ ice_update_pkt_fwd_rule(struct ice_hw *hw, struct i= ce_fltr_info *f_info) /** * ice_update_sw_rule_bridge_mode * @hw: pointer to the HW struct + * @lkup: recipe/lookup type to update * * Updates unicast switch filter rules based on VEB/VEPA mode */ -int ice_update_sw_rule_bridge_mode(struct ice_hw *hw) +int ice_update_sw_rule_bridge_mode(struct ice_hw *hw, + enum ice_sw_lkup_type lkup) { struct ice_switch_info *sw =3D hw->switch_info; struct ice_fltr_mgmt_list_entry *fm_entry; @@ -3078,8 +3080,8 @@ int ice_update_sw_rule_bridge_mode(struct ice_hw *hw) struct mutex *rule_lock; /* Lock to protect filter rule list */ int status =3D 0; =20 - rule_lock =3D &sw->recp_list[ICE_SW_LKUP_MAC].filt_rule_lock; - rule_head =3D &sw->recp_list[ICE_SW_LKUP_MAC].filt_rules; + rule_lock =3D &sw->recp_list[lkup].filt_rule_lock; + rule_head =3D &sw->recp_list[lkup].filt_rules; =20 mutex_lock(rule_lock); list_for_each_entry(fm_entry, rule_head, list_entry) { diff --git a/drivers/net/ethernet/intel/ice/ice_switch.h b/drivers/net/ethe= rnet/intel/ice/ice_switch.h index 137eae878ab1..b442db4a2ce5 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.h +++ b/drivers/net/ethernet/intel/ice/ice_switch.h @@ -366,7 +366,8 @@ int ice_add_adv_rule(struct ice_hw *hw, struct ice_adv_lkup_elem *lkups, u16 lkups_cnt, struct ice_adv_rule_info *rinfo, struct ice_rule_query_data *added_entry); -int ice_update_sw_rule_bridge_mode(struct ice_hw *hw); +int ice_update_sw_rule_bridge_mode(struct ice_hw *hw, + enum ice_sw_lkup_type lkup); int ice_add_vlan(struct ice_hw *hw, struct list_head *m_list); int ice_remove_vlan(struct ice_hw *hw, struct list_head *v_list); int ice_add_mac(struct ice_hw *hw, struct list_head *m_lst); --=20 2.43.0 From nobody Sat Feb 7 11:38:20 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (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 4061A3D6673; Tue, 20 Jan 2026 10:34:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768905297; cv=none; b=EcTQfaX0nmXkF+bvmGoWowMgllfMTueIO4RUkPfrxCaIpEJDK8e2JiNg7GWEHh7UD+Rx37lQd/4VFxsZZEn913OKBtcBsAR+/OpuzqftFLk8ISvrpkTE1gJrg9yxYITuwN20dw0APsVs9kXay4QfPW9y0MrYIUdI2q+OYUmGiYA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768905297; c=relaxed/simple; bh=oHweYp6PS9TtuF1WSau2FriMx/zNUIIprGncg141AXg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DkvCu8egdu/nl7/+WTdiYYLfqj+3d4gh5xqITIGFnrG4B9QdDvdAsGSPAz34zu6Jm5JY8tgG//Pan24Sw/X51ddwf9Ustm04JGHaoP5BKME2py2Ao6lBsgjrqcAuxo1zoo1DLtLyXTfKyO5hj/BFAYG6F7Kkr7TEFFXhR99rQrM= 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=Tm2/SXkN; arc=none smtp.client-ip=198.175.65.18 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="Tm2/SXkN" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1768905295; x=1800441295; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=oHweYp6PS9TtuF1WSau2FriMx/zNUIIprGncg141AXg=; b=Tm2/SXkNtbMPwRFs8xsY14verrSwnDrkbGcCWQuCQCY4Gd6KxPSt2yNi 0MJ/mtMxyincer9pX8c+zL44lOkvMspYS5cYrStQV+Gi5BratxUuTCcSD VGlPL+Qa1RN2w8cxkPS5zqIVoJLXef7YaBCmHl2ct8DLPI+n2VmWOBs0C UZimxxzoxnJvm7ttWwOTgCSMEBHUGh4g9ILXr8T18O+8yuAGjrMeZOJOU r+oltvSKpJHrRX9LrTjgprD51Cw6KiKsv/mVXoA9+bF199THByBSlZBkQ AneipnpwsumWimLegRKsFJxMzrwF+RiNgdxlU2oY1c3miIKL7AaGgRtwP w==; X-CSE-ConnectionGUID: NNeqE8s0TWeiZbRFtqMpHg== X-CSE-MsgGUID: uEH68fBwRia6q84iXOaPQg== X-IronPort-AV: E=McAfee;i="6800,10657,11676"; a="70161761" X-IronPort-AV: E=Sophos;i="6.21,240,1763452800"; d="scan'208";a="70161761" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2026 02:34:54 -0800 X-CSE-ConnectionGUID: aaZi9RX4Qvi+fkH9AuIx7w== X-CSE-MsgGUID: ysbXjQQjQPa08hbaFOLtxg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,240,1763452800"; d="scan'208";a="210935871" Received: from hpe-dl385gen10.igk.intel.com ([10.91.240.117]) by fmviesa004.fm.intel.com with ESMTP; 20 Jan 2026 02:34:53 -0800 From: Jakub Slepecki To: intel-wired-lan@lists.osuosl.org Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, przemyslaw.kitszel@intel.com, anthony.l.nguyen@intel.com, michal.swiatkowski@linux.intel.com, jakub.slepecki@intel.com, aleksandr.loktionov@intel.com Subject: [PATCH iwl-next v3 6/8] ice: add functions to query for vsi's pvids Date: Tue, 20 Jan 2026 11:34:37 +0100 Message-ID: <20260120103440.892326-7-jakub.slepecki@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260120103440.892326-1-jakub.slepecki@intel.com> References: <20260120103440.892326-1-jakub.slepecki@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Organization: Intel Technology Poland sp. z o.o. - ul. Slowackiego 173, 80-298 Gdansk - KRS 101882 - NIP 957-07-52-316 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" PVID information is set across two structs and several members depending primarily on DVM support and VSI type. Add function that guess whether PVID is set and where and allow to access raw VLAN ID set. This is intended to be used later on to decide what MAC{,VLAN} filters to set for a VSI. Reviewed-by: Michal Swiatkowski Reviewed-by: Aleksandr Loktionov Signed-off-by: Jakub Slepecki --- No changes in v3. No changes in v2. --- drivers/net/ethernet/intel/ice/ice_lib.c | 56 ++++++++++++++++++++++++ drivers/net/ethernet/intel/ice/ice_lib.h | 2 + 2 files changed, 58 insertions(+) diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/etherne= t/intel/ice/ice_lib.c index 041278caf8e3..ff4763cea2e5 100644 --- a/drivers/net/ethernet/intel/ice/ice_lib.c +++ b/drivers/net/ethernet/intel/ice/ice_lib.c @@ -4136,3 +4136,59 @@ void ice_vsi_update_l2tsel(struct ice_vsi *vsi, enum= ice_l2tsel l2tsel) wr32(hw, qrx_context_offset, regval); } } + +/** + * ice_vsi_has_outer_pvid - check if VSI has outer Port VLAN ID assigned + * @info: props of VSI in question + * + * Return: true if VSI has outer PVID, false otherwise. + */ +static bool +ice_vsi_has_outer_pvid(const struct ice_aqc_vsi_props *info) +{ + return info->outer_vlan_flags & ICE_AQ_VSI_OUTER_VLAN_PORT_BASED_INSERT; +} + +/** + * ice_vsi_has_inner_pvid - check if VSI has inner Port VLAN ID assigned + * @info: props of VSI in question + * + * Return: true if VSI has inner PVID, false otherwise. + */ +static bool +ice_vsi_has_inner_pvid(const struct ice_aqc_vsi_props *info) +{ + return info->inner_vlan_flags & ICE_AQ_VSI_INNER_VLAN_INSERT_PVID; +} + +/** + * ice_vsi_has_pvid - check if VSI has Port VLAN ID assigned + * @vsi: VSI in question + * + * Return: true if VSI has either outer or inner PVID, false otherwise. + */ +bool +ice_vsi_has_pvid(struct ice_vsi *vsi) +{ + return ice_vsi_has_outer_pvid(&vsi->info) || + ice_vsi_has_inner_pvid(&vsi->info); +} + +/** + * ice_vsi_pvid - retrieve VSI's Port VLAN ID + * @vsi: VSI in question + * + * Return: VSI's PVID; it is valid only if ice_vsi_has_pvid is true. + */ +u16 +ice_vsi_pvid(struct ice_vsi *vsi) +{ + __le16 vlan_info =3D 0; + + if (ice_vsi_has_outer_pvid(&vsi->info)) + vlan_info =3D vsi->info.port_based_outer_vlan; + else if (ice_vsi_has_inner_pvid(&vsi->info)) + vlan_info =3D vsi->info.port_based_inner_vlan; + + return le16_to_cpu(vlan_info) & VLAN_VID_MASK; +} diff --git a/drivers/net/ethernet/intel/ice/ice_lib.h b/drivers/net/etherne= t/intel/ice/ice_lib.h index 2d3168458891..46152e26a995 100644 --- a/drivers/net/ethernet/intel/ice/ice_lib.h +++ b/drivers/net/ethernet/intel/ice/ice_lib.h @@ -134,6 +134,8 @@ void ice_clear_feature_support(struct ice_pf *pf, enum = ice_feature f); void ice_init_feature_support(struct ice_pf *pf); bool ice_vsi_is_rx_queue_active(struct ice_vsi *vsi); void ice_vsi_update_l2tsel(struct ice_vsi *vsi, enum ice_l2tsel l2tsel); +bool ice_vsi_has_pvid(struct ice_vsi *vsi); +u16 ice_vsi_pvid(struct ice_vsi *vsi); =20 extern const struct netdev_queue_mgmt_ops ice_queue_mgmt_ops; =20 --=20 2.43.0 From nobody Sat Feb 7 11:38:20 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (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 D55B8413255; Tue, 20 Jan 2026 10:34:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768905300; cv=none; b=UngQuXiVitPwa+p/0fwPLuZYa6UhcPcOVvjrAoE1EjWDG7/YH05qdZgtesqA4vzj/ZHtDamw4oohTKm8hNFn9X5IisEEs6/sPBIKOBrt7vSqFE83n4pGe4vPjuGNgVpEOkkkMrGFjEG0wx5eQYecZSxg8RazBbK6vIlFdd7WLso= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768905300; c=relaxed/simple; bh=pEOvEWrWvAzUY/Vx8v3pEaX80dY9YG1DYZdtnpg8TcY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ivq+uzbc3n1WCQDxp94QRyg6AoOwYlXPynDMg2Div8h5PIoj2VRbJp1q0/XdCH+G8j7HMFdCEHjGTo0uW72xq9g2Hndqws2ZuJ+3UrihDPOKjzmGTj4nplsLnVjzSRuZ11bhEHgZ49eUStYybY6XacNnY+61KNHW/qb9ZqDFDMQ= 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=jreuQVAJ; arc=none smtp.client-ip=198.175.65.18 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="jreuQVAJ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1768905298; x=1800441298; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=pEOvEWrWvAzUY/Vx8v3pEaX80dY9YG1DYZdtnpg8TcY=; b=jreuQVAJtndGkfJ0oBZlPa6qB5Z3RTMCfWkuLuoYDbnxe04uh6053zGF F+u621TA4BnlVo6N3cUExNfZaWcyqzvGKLkVXC64IFe/mJjTgdn8q7Ky4 itiwQYEe6WZehUtwrzcZpo2uc/Za8l9MmeagHZgxADoqt8EO1zuiTHgTf fTiIdtmjHqCgyvvOK48PSy2stIkS5sqgRcRBccHFcZqPB8I1xQ0tB5dFu ssT7PFlHYKLgXHSXVes4e0ePW4wtsMiZy2ty7kPgoegWCahFmqmXdjvch sXBo9WBpjRWsZw8+3C1stoYW9TRbGczQVFBKNLnl8kmUiRhq2YQujq2O+ A==; X-CSE-ConnectionGUID: vzyx6o1JQB6f7q75k8ft3Q== X-CSE-MsgGUID: Yyh+XIsUStahzjNOQ47ivQ== X-IronPort-AV: E=McAfee;i="6800,10657,11676"; a="70161767" X-IronPort-AV: E=Sophos;i="6.21,240,1763452800"; d="scan'208";a="70161767" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2026 02:34:57 -0800 X-CSE-ConnectionGUID: CKrV8l4zQEq7xLATbK2FzA== X-CSE-MsgGUID: wPqCkBK3Sq6vg5fEjhWwNA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,240,1763452800"; d="scan'208";a="210935876" Received: from hpe-dl385gen10.igk.intel.com ([10.91.240.117]) by fmviesa004.fm.intel.com with ESMTP; 20 Jan 2026 02:34:55 -0800 From: Jakub Slepecki To: intel-wired-lan@lists.osuosl.org Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, przemyslaw.kitszel@intel.com, anthony.l.nguyen@intel.com, michal.swiatkowski@linux.intel.com, jakub.slepecki@intel.com, aleksandr.loktionov@intel.com Subject: [PATCH iwl-next v3 7/8] ice: add mac vlan to filter API Date: Tue, 20 Jan 2026 11:34:38 +0100 Message-ID: <20260120103440.892326-8-jakub.slepecki@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260120103440.892326-1-jakub.slepecki@intel.com> References: <20260120103440.892326-1-jakub.slepecki@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Organization: Intel Technology Poland sp. z o.o. - ul. Slowackiego 173, 80-298 Gdansk - KRS 101882 - NIP 957-07-52-316 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Michal Swiatkowski Allow mac vlan filters to be managed by filters API in ice driver. Together with mac-only filters they will be used to forward traffic intended for loopback in VEB mode. Signed-off-by: Michal Swiatkowski Reviewed-by: Aleksandr Loktionov Signed-off-by: Jakub Slepecki --- No changes in v3. No changes in v2. --- drivers/net/ethernet/intel/ice/ice_fltr.c | 33 +++++++++++++++++++++++ drivers/net/ethernet/intel/ice/ice_fltr.h | 4 +++ 2 files changed, 37 insertions(+) diff --git a/drivers/net/ethernet/intel/ice/ice_fltr.c b/drivers/net/ethern= et/intel/ice/ice_fltr.c index aff7a141c30d..96a4e4b1b3fc 100644 --- a/drivers/net/ethernet/intel/ice/ice_fltr.c +++ b/drivers/net/ethernet/intel/ice/ice_fltr.c @@ -240,6 +240,39 @@ ice_fltr_add_mac_to_list(struct ice_vsi *vsi, struct l= ist_head *list, list); } =20 +/** + * ice_fltr_add_mac_vlan_to_list - add MAC VLAN filter info to + * existing list + * @vsi: pointer to VSI struct + * @list: list to add filter info to + * @mac: MAC address to add + * @vlan_id: VLAN id to add + * @action: filter action + * + * Return: + * * 0 if entry for filter was added, or + * * %-ENOMEM if entry could not be allocated. + */ +int +ice_fltr_add_mac_vlan_to_list(struct ice_vsi *vsi, struct list_head *list, + const u8 *mac, u16 vlan_id, + enum ice_sw_fwd_act_type action) +{ + struct ice_fltr_info info =3D {}; + + info.flag =3D ICE_FLTR_TX; + info.src_id =3D ICE_SRC_ID_VSI; + info.lkup_type =3D ICE_SW_LKUP_MAC_VLAN; + info.fltr_act =3D action; + info.vsi_handle =3D vsi->idx; + + info.l_data.mac_vlan.vlan_id =3D vlan_id; + ether_addr_copy(info.l_data.mac_vlan.mac_addr, mac); + + return ice_fltr_add_entry_to_list(ice_pf_to_dev(vsi->back), &info, + list); +} + /** * ice_fltr_add_vlan_to_list - add VLAN filter info to exsisting list * @vsi: pointer to VSI struct diff --git a/drivers/net/ethernet/intel/ice/ice_fltr.h b/drivers/net/ethern= et/intel/ice/ice_fltr.h index 0f3dbc308eec..fb9ffb39be50 100644 --- a/drivers/net/ethernet/intel/ice/ice_fltr.h +++ b/drivers/net/ethernet/intel/ice/ice_fltr.h @@ -23,6 +23,10 @@ int ice_fltr_add_mac_to_list(struct ice_vsi *vsi, struct list_head *list, const u8 *mac, enum ice_sw_fwd_act_type action); int +ice_fltr_add_mac_vlan_to_list(struct ice_vsi *vsi, struct list_head *list, + const u8 *mac, u16 vlan_id, + enum ice_sw_fwd_act_type action); +int ice_fltr_add_mac(struct ice_vsi *vsi, const u8 *mac, enum ice_sw_fwd_act_type action); int --=20 2.43.0 From nobody Sat Feb 7 11:38:20 2026 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) (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 D959741B34A; Tue, 20 Jan 2026 10:34:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768905302; cv=none; b=fV9MNnKhTZW55R4r22FPR4OYNJmsQoxLd4mT0innw9gpr0HKqlwxRz5sGCD5gG7hvZs2ksARQGyB+1VAp8OSAvw+tyx34uv31xuX/3rDpT8GyuvLvV6S+Cah69rEZGxkqgQ2s57mO6PK9Aof0uJ1n0RGa7QpPrrWSi7DzF/fOFc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768905302; c=relaxed/simple; bh=v6eGLM6s8MQw6+0ZyixU2n5g7+P4fHodPqCgJhZy+8M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SsIb+MSr1fePsa4o9UnzCU0noKrbU7xPueh0yxfYxIQ+ugEtqvLw0ADyOSB6npidlUOvn8nVKhWQKYjlahv6eGfvTK1BBRNrK17XHBlxEti0OSte2m6YATkR1v/ZklXqfGpjngBGXJTLhGPEsirXwC1ikqsB/IbI1m7m4kvKOA0= 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=D0c74EmC; arc=none smtp.client-ip=198.175.65.18 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="D0c74EmC" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1768905300; x=1800441300; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=v6eGLM6s8MQw6+0ZyixU2n5g7+P4fHodPqCgJhZy+8M=; b=D0c74EmCw1f9wTA4baC6Cc+FrkMP1KENhyc5n8SZ/sukLkznAj0c3p2L 1+7L/geCYeXGkPU5hkTObNvPEEFCrwrbK0Cw3rpqSKwl3RDMjbYQabz68 nxiNJe9ySiVCpXHWRKq0vW+YsbnM8PEHQy4YMTIhnBYHS4GiwSyakBnDz LD+XUCSW3cS8sY16LB9JEyL+m8jfqr8CPHHd1Y1BbIf6NzL+wq7GxGtzE UK3ooe18zlVm5kL8lN/IObeip4OhafMKuA7i3h/Br/JmCTSsbJE/Ap1Hy yKawtNR6SNvHSfzu/5WNwOXfs52GCgh9r2ZyhGQC29FGc/DH2OWoj6d3N Q==; X-CSE-ConnectionGUID: 2KEPnX9NQkKimb+QHNg6mg== X-CSE-MsgGUID: I04LFAgiS9Ohqmb0kEpZmw== X-IronPort-AV: E=McAfee;i="6800,10657,11676"; a="70161776" X-IronPort-AV: E=Sophos;i="6.21,240,1763452800"; d="scan'208";a="70161776" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2026 02:34:59 -0800 X-CSE-ConnectionGUID: JbQbzabDT4OZ32GBl8wl7w== X-CSE-MsgGUID: U1XkXp2VQauzU7F/+qcPGA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,240,1763452800"; d="scan'208";a="210935879" Received: from hpe-dl385gen10.igk.intel.com ([10.91.240.117]) by fmviesa004.fm.intel.com with ESMTP; 20 Jan 2026 02:34:57 -0800 From: Jakub Slepecki To: intel-wired-lan@lists.osuosl.org Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, przemyslaw.kitszel@intel.com, anthony.l.nguyen@intel.com, michal.swiatkowski@linux.intel.com, jakub.slepecki@intel.com, aleksandr.loktionov@intel.com Subject: [PATCH iwl-next v3 8/8] ice: in VEB, prevent "cross-vlan" traffic from hitting loopback Date: Tue, 20 Jan 2026 11:34:39 +0100 Message-ID: <20260120103440.892326-9-jakub.slepecki@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260120103440.892326-1-jakub.slepecki@intel.com> References: <20260120103440.892326-1-jakub.slepecki@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Organization: Intel Technology Poland sp. z o.o. - ul. Slowackiego 173, 80-298 Gdansk - KRS 101882 - NIP 957-07-52-316 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" In Virtual Ethernet Bridge (VEB) mode, we use MAC filters to forward traffic between two VFs. We also use VLAN filters to prune potential destinations, so that they don't cross VLANs. In case a VF in VLAN X sends a packet to a MAC address matching another VF but in VLAN Y, both these filters will be hit. Packet will be sent to loopback-only to VF in VLAN Y, but VLAN filter will prune its VSI from the destination list leaving the packet stranded in the internal switch and thus dropped. Since there is no destination for the packet in the VLAN X, it should instead be sent to the wire. To fix this, we introduce MAC,VLAN filters in place of MAC-only filters if VSI is part of any VLAN. We consider VSI part of a VLAN if it has a PVID set, or if it has a specific VLAN filter and does not have a VLAN 0 filter. This approach does not attempt to fix interactions with upper devices. If an upper vlan device requests a separate MAC address filter resulting in a call to __dev_uc_sync, the VSI will start receiving all packets destined for this MAC and not just within the VLAN. I don't see a straight-forward way to resolve this: information about MAC and VLAN filters coming from kernel to driver is disconnected from one another and from the device that requests it. It could be worked around by, for example, tracking all upper devices with netdev notifications and adjusting the filters there. Hence, the scope is limited to VF traffic. Following situations were considered for VLAN filters additions, removal, or changes: 1. ice changes VF's vlan 2. VF is reset and rebuilt 3. vlan device attaches above a PF or a VF And same for MAC filters: 4. PF's MAC is changed 5. PF changes MAC of a VF 6. VF's MAC is changed 7. ndo_set_rx_mode et al When VLAN is assigned to a VF in (1), the affected VF is reset and rebuild. This makes (1) the same as (2). We end up with two cases where VLAN filters are added: (2) and (3). To correctly handle (1-2), we move the VLAN filters initialization before the MAC filters initialization, since MAC filters now depend on VLAN filters presence. These two handle PVID (or lack of thereof) and because they are always associated with a reset, we don't need to consider updating MAC and MAC,VLAN filters afterwards. In (3), we will always have a lower device that is expected to receive all packets for its MAC regardless of VLAN tag. Because of the caveat described above, we will do the same for each MAC address associated with the interface regardless of VLANs. The result is we only have MAC-only filters in this case. When we create MAC filters in (4-7) we now check for existing VLAN filters and depending on PVID and VLAN 0 presence we decide to create, respectively, a MAC and MAC,VLAN filter pair, or a MAC filter. This is done implicitly when requesting to remove old MAC and add new MAC, so no change is required to this flow. Reviewed-by: Michal Swiatkowski Reviewed-by: Aleksandr Loktionov Signed-off-by: Jakub Slepecki --- Note the /a.s. dead/ branch in ice_fltr.c. I decided to make it explicit, but it can be merged into VLAN 0 branch as well (with or without a comment), because their final effect is exactly the same. No changes in v3. No changes in v2. --- drivers/net/ethernet/intel/ice/ice_fltr.c | 71 +++++++++++++++++++-- drivers/net/ethernet/intel/ice/ice_fltr.h | 6 +- drivers/net/ethernet/intel/ice/ice_main.c | 8 +-- drivers/net/ethernet/intel/ice/ice_switch.c | 2 +- drivers/net/ethernet/intel/ice/ice_switch.h | 2 + drivers/net/ethernet/intel/ice/ice_vf_lib.c | 8 +-- 6 files changed, 83 insertions(+), 14 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_fltr.c b/drivers/net/ethern= et/intel/ice/ice_fltr.c index 96a4e4b1b3fc..c0fc1bced167 100644 --- a/drivers/net/ethernet/intel/ice/ice_fltr.c +++ b/drivers/net/ethernet/intel/ice/ice_fltr.c @@ -3,6 +3,7 @@ =20 #include "ice.h" #include "ice_fltr.h" +#include "ice_lib.h" =20 /** * ice_fltr_free_list - free filter lists helper @@ -221,10 +222,12 @@ void ice_fltr_remove_all(struct ice_vsi *vsi) * @list: list to add filter info to * @mac: MAC address to add * @action: filter action + * @external: force the filter to enable lan destination */ int ice_fltr_add_mac_to_list(struct ice_vsi *vsi, struct list_head *list, - const u8 *mac, enum ice_sw_fwd_act_type action) + const u8 *mac, enum ice_sw_fwd_act_type action, + bool external) { struct ice_fltr_info info =3D { 0 }; =20 @@ -233,6 +236,10 @@ ice_fltr_add_mac_to_list(struct ice_vsi *vsi, struct l= ist_head *list, info.lkup_type =3D ICE_SW_LKUP_MAC; info.fltr_act =3D action; info.vsi_handle =3D vsi->idx; + if (external) { + info.lb_en =3D ICE_FLTR_INFO_LB_LAN_FORCE_ENABLED; + info.lan_en =3D ICE_FLTR_INFO_LB_LAN_FORCE_ENABLED; + } =20 ether_addr_copy(info.l_data.mac.mac_addr, mac); =20 @@ -273,6 +280,62 @@ ice_fltr_add_mac_vlan_to_list(struct ice_vsi *vsi, str= uct list_head *list, list); } =20 +/** + * ice_fltr_add_macs_to_list - add MAC and MAC,VLAN filters info to an exi= sting + * list + * @vsi: pointer to VSI struct + * @list: list to add filter info to + * @mac: MAC address to add + * @action: filter action + * + * Return: + * * 0 on success, or + * * %-ENOMEM if entry for filter could not be allocated. + */ +int +ice_fltr_add_macs_to_list(struct ice_vsi *vsi, struct list_head *list, + const u8 *mac, enum ice_sw_fwd_act_type action) +{ + if (is_multicast_ether_addr(mac)) { + /* There is no point in doing the same gymnastics as below + * because multicast addresses are sent to both lan and lb then + * pruned as necessary. + */ + return ice_fltr_add_mac_to_list(vsi, list, mac, action, false); + } else if (ice_vsi_has_pvid(vsi)) { + u16 pvid =3D ice_vsi_pvid(vsi); + int ret; + + ret =3D ice_fltr_add_mac_to_list(vsi, list, mac, action, true); + if (ret) + return ret; + + return ice_fltr_add_mac_vlan_to_list(vsi, list, mac, pvid, + action); + } else if (vsi->num_vlan !=3D ice_vsi_num_non_zero_vlans(vsi)) { + /* If VSI has VLAN 0 filters, then the interface is prepared to + * receive untagged packets. As of now, we simply don't have + * heuristics to decide which MAC is and is not part of which + * VLAN so we put them all in the same bucket. + */ + return ice_fltr_add_mac_to_list(vsi, list, mac, action, false); + } + + /* This branch is a.s. dead. There are three cases that may happen: + * + * - no vlans in sight; this is the VLAN 0 branch, + * - VF is assigned PVID; this is ice_vsi_has_pvid branch, + * - PF or VF is under vlan device; this is the VLAN 0 branch. + * + * This is where you would implement support for multiple VLANs but + * without the VLAN 0. This could happen if vlan upper device is + * assigned a MAC that is unique compared to lower ice device that is + * forced to accept any VLAN. This would imply MAC-only filter for one + * MAC address (PF) and MAC,VLAN+MAC filters for another (vlan). + */ + return ice_fltr_add_mac_to_list(vsi, list, mac, action, false); +} + /** * ice_fltr_add_vlan_to_list - add VLAN filter info to exsisting list * @vsi: pointer to VSI struct @@ -343,7 +406,7 @@ ice_fltr_prepare_mac(struct ice_vsi *vsi, const u8 *mac, LIST_HEAD(tmp_list); int result; =20 - if (ice_fltr_add_mac_to_list(vsi, &tmp_list, mac, action)) { + if (ice_fltr_add_macs_to_list(vsi, &tmp_list, mac, action)) { ice_fltr_free_list(ice_pf_to_dev(vsi->back), &tmp_list); return -ENOMEM; } @@ -371,8 +434,8 @@ ice_fltr_prepare_mac_and_broadcast(struct ice_vsi *vsi,= const u8 *mac, int result; =20 eth_broadcast_addr(broadcast); - if (ice_fltr_add_mac_to_list(vsi, &tmp_list, mac, action) || - ice_fltr_add_mac_to_list(vsi, &tmp_list, broadcast, action)) { + if (ice_fltr_add_macs_to_list(vsi, &tmp_list, mac, action) || + ice_fltr_add_macs_to_list(vsi, &tmp_list, broadcast, action)) { ice_fltr_free_list(ice_pf_to_dev(vsi->back), &tmp_list); return -ENOMEM; } diff --git a/drivers/net/ethernet/intel/ice/ice_fltr.h b/drivers/net/ethern= et/intel/ice/ice_fltr.h index fb9ffb39be50..ed3371b0a71f 100644 --- a/drivers/net/ethernet/intel/ice/ice_fltr.h +++ b/drivers/net/ethernet/intel/ice/ice_fltr.h @@ -21,12 +21,16 @@ ice_fltr_set_vsi_promisc(struct ice_hw *hw, u16 vsi_han= dle, u8 promisc_mask, u16 vid); int ice_fltr_add_mac_to_list(struct ice_vsi *vsi, struct list_head *list, - const u8 *mac, enum ice_sw_fwd_act_type action); + const u8 *mac, enum ice_sw_fwd_act_type action, + bool external); int ice_fltr_add_mac_vlan_to_list(struct ice_vsi *vsi, struct list_head *list, const u8 *mac, u16 vlan_id, enum ice_sw_fwd_act_type action); int +ice_fltr_add_macs_to_list(struct ice_vsi *vsi, struct list_head *list, + const u8 *mac, enum ice_sw_fwd_act_type action); +int ice_fltr_add_mac(struct ice_vsi *vsi, const u8 *mac, enum ice_sw_fwd_act_type action); int diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethern= et/intel/ice/ice_main.c index 7b3ab69b8300..b712e0c29fc2 100644 --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -212,8 +212,8 @@ static int ice_add_mac_to_sync_list(struct net_device *= netdev, const u8 *addr) struct ice_netdev_priv *np =3D netdev_priv(netdev); struct ice_vsi *vsi =3D np->vsi; =20 - if (ice_fltr_add_mac_to_list(vsi, &vsi->tmp_sync_list, addr, - ICE_FWD_TO_VSI)) + if (ice_fltr_add_macs_to_list(vsi, &vsi->tmp_sync_list, addr, + ICE_FWD_TO_VSI)) return -EINVAL; =20 return 0; @@ -242,8 +242,8 @@ static int ice_add_mac_to_unsync_list(struct net_device= *netdev, const u8 *addr) if (ether_addr_equal(addr, netdev->dev_addr)) return 0; =20 - if (ice_fltr_add_mac_to_list(vsi, &vsi->tmp_unsync_list, addr, - ICE_FWD_TO_VSI)) + if (ice_fltr_add_macs_to_list(vsi, &vsi->tmp_unsync_list, addr, + ICE_FWD_TO_VSI)) return -EINVAL; =20 return 0; diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethe= rnet/intel/ice/ice_switch.c index 3b526383b8ed..13dd3448aec6 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.c +++ b/drivers/net/ethernet/intel/ice/ice_switch.c @@ -4018,7 +4018,7 @@ ice_cfg_dflt_vsi(struct ice_port_info *pi, u16 vsi_ha= ndle, bool set, * @fm_entry: filter entry to inspect * @vsi_handle: VSI handle to compare with filter info */ -static bool +bool ice_vsi_uses_fltr(struct ice_fltr_mgmt_list_entry *fm_entry, u16 vsi_handl= e) { return ((fm_entry->fltr_info.fltr_act =3D=3D ICE_FWD_TO_VSI && diff --git a/drivers/net/ethernet/intel/ice/ice_switch.h b/drivers/net/ethe= rnet/intel/ice/ice_switch.h index b442db4a2ce5..a295130e96f3 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.h +++ b/drivers/net/ethernet/intel/ice/ice_switch.h @@ -346,6 +346,8 @@ ice_update_vsi(struct ice_hw *hw, u16 vsi_handle, struc= t ice_vsi_ctx *vsi_ctx, bool ice_is_vsi_valid(struct ice_hw *hw, u16 vsi_handle); struct ice_vsi_ctx *ice_get_vsi_ctx(struct ice_hw *hw, u16 vsi_handle); void ice_clear_all_vsi_ctx(struct ice_hw *hw); +bool ice_vsi_uses_fltr(struct ice_fltr_mgmt_list_entry *fm_entry, + u16 vsi_handle); /* Switch config */ int ice_get_initial_sw_cfg(struct ice_hw *hw); =20 diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.c b/drivers/net/ethe= rnet/intel/ice/ice_vf_lib.c index de9e81ccee66..1031ce20bb60 100644 --- a/drivers/net/ethernet/intel/ice/ice_vf_lib.c +++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.c @@ -501,14 +501,14 @@ static void ice_vf_rebuild_host_cfg(struct ice_vf *vf) =20 ice_vf_set_host_trust_cfg(vf); =20 - if (ice_vf_rebuild_host_mac_cfg(vf)) - dev_err(dev, "failed to rebuild default MAC configuration for VF %d\n", - vf->vf_id); - if (ice_vf_rebuild_host_vlan_cfg(vf, vsi)) dev_err(dev, "failed to rebuild VLAN configuration for VF %u\n", vf->vf_id); =20 + if (ice_vf_rebuild_host_mac_cfg(vf)) + dev_err(dev, "failed to rebuild default MAC configuration for VF %d\n", + vf->vf_id); + if (ice_vf_rebuild_host_tx_rate_cfg(vf)) dev_err(dev, "failed to rebuild Tx rate limiting configuration for VF %u= \n", vf->vf_id); --=20 2.43.0