From patchwork Fri Mar 15 11:08:20 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Swiatkowski X-Patchwork-Id: 13593267 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 E9D831B7E3 for ; Fri, 15 Mar 2024 11:03:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710500637; cv=none; b=rhp2PdK9jD503VjIxvV9pfFJsQ45XdRYnHN4BoDB7U38BIfUU6fTimU71NhkdOzVtneq+zmwee0UIlDWdfWxPt62lmKbyzdgrhg2KAKYeHLcZkJaFSTK6TlrKTLsEQyiLHJ9KOdBNfB8tkdS26TxiY0OCf1xjficBn7U/g91Rvc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710500637; c=relaxed/simple; bh=AvbcYVh7P8usqtvRRQTYnk/im19ZFQWqAoxQs2bqYZs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=C9UWc7LzGy2ocv4dp9MNKPea5hn7JNN6MTLwThBVFGhfZ0N44KwcYt8LJfKtuOI3LINolqfOZ+0ht38/fdyDHBkowW6MpuRBcxfR1o+We6C7nIZrVWi93BDNgWW98jhpOwt90qZ9gbHCyGOzoaVAyF9fgUnNoiJpVFbKet+6YC8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Wsz7z/GP; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Wsz7z/GP" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1710500635; x=1742036635; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=AvbcYVh7P8usqtvRRQTYnk/im19ZFQWqAoxQs2bqYZs=; b=Wsz7z/GPuTqZmrSKpPkgvL2+5oXKLTRMpN2SHNAoRR43utPQ4FkXmQ29 AohStsmQLEisRm87m+MaOuPGRsw0DvaHvOXODqGYjOWYKFkgO62ETaVVv 3VmOmJsM8vs/phj4S27nSge+y40iz6WKOV88s1uqxoNJ+NqUQVufcdfko wVt4hj4eVXw7JlzyDpKTYNddAZCCVxhLGsnQ4rvhT+GKhx05Iq3reLZIj LYFWV4cLvp97gyOdbavdjEe1sb7e+wOZBWj0jXoppW+gKtJKaU1Oq9ucg pSTlmSSfnNVNoNG9oEZmcB0l4whoi4iVXGPaa/+9t20rwMOgQo6V8jPl6 A==; X-IronPort-AV: E=McAfee;i="6600,9927,11013"; a="5549434" X-IronPort-AV: E=Sophos;i="6.07,128,1708416000"; d="scan'208";a="5549434" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2024 04:03:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,128,1708416000"; d="scan'208";a="35761198" Received: from wasp.igk.intel.com (HELO GK3153-DR2-R750-36946.localdomain.com) ([10.102.20.192]) by fmviesa002.fm.intel.com with ESMTP; 15 Mar 2024 04:03:53 -0700 From: Michal Swiatkowski To: intel-wired-lan@lists.osuosl.org Cc: netdev@vger.kernel.org, Michal Swiatkowski , Jedrzej Jagielski , Sridhar Samudrala Subject: [iwl-net v1 1/2] ice: tc: check src_vsi in case of traffic from VF Date: Fri, 15 Mar 2024 12:08:20 +0100 Message-ID: <20240315110821.511321-2-michal.swiatkowski@linux.intel.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20240315110821.511321-1-michal.swiatkowski@linux.intel.com> References: <20240315110821.511321-1-michal.swiatkowski@linux.intel.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: kuba@kernel.org In case of traffic going from the VF (so ingress for port representor) source VSI should be consider during packet classification. It is needed for hardware to not match packets from different ports with filters added on other port. It is only for "from VF" traffic, because other traffic direction doesn't have source VSI. Set correct ::src_vsi in rule_info to pass it to the hardware filter. For example this rule should drop only ipv4 packets from eth10, not from the others VF PRs. It is needed to check source VSI in this case. $tc filter add dev eth10 ingress protocol ip flower skip_sw action drop Fixes: 0d08a441fb1a ("ice: ndo_setup_tc implementation for PF") Reviewed-by: Jedrzej Jagielski Reviewed-by: Sridhar Samudrala Signed-off-by: Michal Swiatkowski Reviewed-by: Simon Horman Tested-by: Sujai Buvaneswaran --- drivers/net/ethernet/intel/ice/ice_tc_lib.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/net/ethernet/intel/ice/ice_tc_lib.c b/drivers/net/ethernet/intel/ice/ice_tc_lib.c index 47f28cd576c6..a8c686ecd1a0 100644 --- a/drivers/net/ethernet/intel/ice/ice_tc_lib.c +++ b/drivers/net/ethernet/intel/ice/ice_tc_lib.c @@ -28,6 +28,8 @@ ice_tc_count_lkups(u32 flags, struct ice_tc_flower_lyr_2_4_hdrs *headers, * - ICE_TC_FLWR_FIELD_VLAN_TPID (present if specified) * - Tunnel flag (present if tunnel) */ + if (fltr->direction == ICE_ESWITCH_FLTR_EGRESS) + lkups_cnt++; if (flags & ICE_TC_FLWR_FIELD_TENANT_ID) lkups_cnt++; @@ -363,6 +365,11 @@ ice_tc_fill_rules(struct ice_hw *hw, u32 flags, /* Always add direction metadata */ ice_rule_add_direction_metadata(&list[ICE_TC_METADATA_LKUP_IDX]); + if (tc_fltr->direction == ICE_ESWITCH_FLTR_EGRESS) { + ice_rule_add_src_vsi_metadata(&list[i]); + i++; + } + rule_info->tun_type = ice_sw_type_from_tunnel(tc_fltr->tunnel_type); if (tc_fltr->tunnel_type != TNL_LAST) { i = ice_tc_fill_tunnel_outer(flags, tc_fltr, list, i); @@ -820,6 +827,7 @@ ice_eswitch_add_tc_fltr(struct ice_vsi *vsi, struct ice_tc_flower_fltr *fltr) /* specify the cookie as filter_rule_id */ rule_info.fltr_rule_id = fltr->cookie; + rule_info.src_vsi = vsi->idx; ret = ice_add_adv_rule(hw, list, lkups_cnt, &rule_info, &rule_added); if (ret == -EEXIST) { From patchwork Fri Mar 15 11:08:21 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Swiatkowski X-Patchwork-Id: 13593268 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.15]) (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 AD1FA19BA2 for ; Fri, 15 Mar 2024 11:03:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.15 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710500637; cv=none; b=RlTn3dDQDqhRmxkvYC53OUt1K6fxfANWpm3xCP7ps3CGwdmcco4FXKBmF9bq81GIz9xbT527+H8rNSt+Fe55KYxEAhM9+RQvo3ykJwUwB6wh4BSdLcSdekXJwj1xggey0zDVCl0mErXcEk3qfvQ6r3Q84m6p2ryOBDB0Ea8iKog= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710500637; c=relaxed/simple; bh=f1y5+s38KG4eul9EBArMIcDOgPDGpTwExT1UYJ9aTiM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HKXA9Qs6YOKxN5kP9QJIWi7s7HWIXhn7ct5fla82JXyPUpLCLQAvd9wDG9MNYMxPDPimXlqDonlNVDt9AewEr6SnpHE/bfKadpjd40uc9XEdSZ7XkpHcajJ/y714T/YawPJKLhh8dL0jkEtroJlnUPnH6EuJ4caIUFGV5yagf6c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=JxzKeDRq; arc=none smtp.client-ip=192.198.163.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="JxzKeDRq" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1710500636; x=1742036636; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=f1y5+s38KG4eul9EBArMIcDOgPDGpTwExT1UYJ9aTiM=; b=JxzKeDRqj6+xo7dvnYzzKLYdLHliQkfSz/koKgcRYQQ9JDZr6wkRM8re lPleCHEfMXohvun7H5k+MwxudicRJg3g0ZZ5sA7QiFAVPi9vOeMgwrJyj iKL49u/bKjG2R+tstdVV/SqfiiJfYW33dRhNQJbFsDfnVwba/qEGd9di6 b/Ztr5EHEWlUaXuFfEtNkSrAvl8zF0aMksKaqUTeY0RJGeeVZv/Yi8FXb ltqWWQs/9ZN8z5qCa08+jHKnkc+I51S8EhSiFztmjcZ1c5VX21NFo71vk ST7sgoKdyXGPVFEqywTSy1KGrK7mZbVeGaqs/ykZ8gkQyi4hfyTFo244v A==; X-IronPort-AV: E=McAfee;i="6600,9927,11013"; a="5549444" X-IronPort-AV: E=Sophos;i="6.07,128,1708416000"; d="scan'208";a="5549444" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa109.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2024 04:03:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,128,1708416000"; d="scan'208";a="35761201" Received: from wasp.igk.intel.com (HELO GK3153-DR2-R750-36946.localdomain.com) ([10.102.20.192]) by fmviesa002.fm.intel.com with ESMTP; 15 Mar 2024 04:03:54 -0700 From: Michal Swiatkowski To: intel-wired-lan@lists.osuosl.org Cc: netdev@vger.kernel.org, Michal Swiatkowski , Wojciech Drewek Subject: [iwl-net v1 2/2] ice: tc: allow zero flags in parsing tc flower Date: Fri, 15 Mar 2024 12:08:21 +0100 Message-ID: <20240315110821.511321-3-michal.swiatkowski@linux.intel.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20240315110821.511321-1-michal.swiatkowski@linux.intel.com> References: <20240315110821.511321-1-michal.swiatkowski@linux.intel.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: kuba@kernel.org The check for flags is done to not pass empty lookups to adding switch rule functions. Since metadata is always added to lookups there is no need to check against the flag. It is also fixing the problem with such rule: $ tc filter add dev gtp_dev ingress protocol ip prio 0 flower \ enc_dst_port 2123 action drop Switch block in case of GTP can't parse the destination port, because it should always be set to GTP specific value. The same with ethertype. The result is that there is no other matching criteria than GTP tunnel. In this case flags is 0, rule can't be added only because of defensive check against flags. Fixes: 9a225f81f540 ("ice: Support GTP-U and GTP-C offload in switchdev") Reviewed-by: Wojciech Drewek Signed-off-by: Michal Swiatkowski Reviewed-by: Simon Horman Tested-by: Sujai Buvaneswaran --- drivers/net/ethernet/intel/ice/ice_tc_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ice/ice_tc_lib.c b/drivers/net/ethernet/intel/ice/ice_tc_lib.c index a8c686ecd1a0..f8df93e1a9de 100644 --- a/drivers/net/ethernet/intel/ice/ice_tc_lib.c +++ b/drivers/net/ethernet/intel/ice/ice_tc_lib.c @@ -779,7 +779,7 @@ ice_eswitch_add_tc_fltr(struct ice_vsi *vsi, struct ice_tc_flower_fltr *fltr) int ret; int i; - if (!flags || (flags & ICE_TC_FLWR_FIELD_ENC_SRC_L4_PORT)) { + if (flags & ICE_TC_FLWR_FIELD_ENC_SRC_L4_PORT) { NL_SET_ERR_MSG_MOD(fltr->extack, "Unsupported encap field(s)"); return -EOPNOTSUPP; }