From patchwork Tue Mar 14 17:44:21 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13174819 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9ED02C6FD1F for ; Tue, 14 Mar 2023 17:46:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230329AbjCNRqT (ORCPT ); Tue, 14 Mar 2023 13:46:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41482 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230350AbjCNRqS (ORCPT ); Tue, 14 Mar 2023 13:46:18 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 49FC4AFB87 for ; Tue, 14 Mar 2023 10:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678815967; x=1710351967; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Lq8TvvP/JHxHP0VYQpJjFskZxO/zd7qONhVd+ZGt6GQ=; b=RPQcVyZ5ALv9HMZDItI3nKHK9+Dhbl7jfBpssl6T4FuJNSX4XYL45M1m oPNZy9z/9sxDvGboIUWXYTTyo9BzCcey7E7YIgP+Z56pMiDOrrH5Uue7J m/GaEu/cUGRCUOu4Y7WXTJnS53ugOyYY4pVrdno+hkmIf0hws6ZC4QHnx cW2OLuIaq6+ckf0OJ2/eVAsdZcgm+vazBrkFI9awUr6jLdEWdxEwCoZFT P2cbNnis5TGP/7tw1vA4LrAvLUkqB0KSmyfHQHkOsOL+AvrLNEAI3eSO+ KA9+RrUu8PZq5/2QJUb54Fjr0beeoVj1cALzmy3eQZ6JgHP5RQ1U/4h16 A==; X-IronPort-AV: E=McAfee;i="6500,9779,10649"; a="317148703" X-IronPort-AV: E=Sophos;i="5.98,260,1673942400"; d="scan'208";a="317148703" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Mar 2023 10:46:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10649"; a="1008516914" X-IronPort-AV: E=Sophos;i="5.98,260,1673942400"; d="scan'208";a="1008516914" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmsmga005.fm.intel.com with ESMTP; 14 Mar 2023 10:46:05 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Alexander Lobakin , anthony.l.nguyen@intel.com, Larysa Zaremba , Michal Kubiak , Rafal Romanowski Subject: [PATCH net 1/3] iavf: fix inverted Rx hash condition leading to disabled hash Date: Tue, 14 Mar 2023 10:44:21 -0700 Message-Id: <20230314174423.1048526-2-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20230314174423.1048526-1-anthony.l.nguyen@intel.com> References: <20230314174423.1048526-1-anthony.l.nguyen@intel.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org From: Alexander Lobakin Condition, which checks whether the netdev has hashing enabled is inverted. Basically, the tagged commit effectively disabled passing flow hash from descriptor to skb, unless user *disables* it via Ethtool. Commit a876c3ba59a6 ("i40e/i40evf: properly report Rx packet hash") fixed this problem, but only for i40e. Invert the condition now in iavf and unblock passing hash to skbs again. Fixes: 857942fd1aa1 ("i40e: Fix Rx hash reported to the stack by our driver") Reviewed-by: Larysa Zaremba Reviewed-by: Michal Kubiak Signed-off-by: Alexander Lobakin Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Reviewed-by: Leon Romanovsky --- drivers/net/ethernet/intel/iavf/iavf_txrx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/iavf/iavf_txrx.c b/drivers/net/ethernet/intel/iavf/iavf_txrx.c index 18b6a702a1d6..e989feda133c 100644 --- a/drivers/net/ethernet/intel/iavf/iavf_txrx.c +++ b/drivers/net/ethernet/intel/iavf/iavf_txrx.c @@ -1096,7 +1096,7 @@ static inline void iavf_rx_hash(struct iavf_ring *ring, cpu_to_le64((u64)IAVF_RX_DESC_FLTSTAT_RSS_HASH << IAVF_RX_DESC_STATUS_FLTSTAT_SHIFT); - if (ring->netdev->features & NETIF_F_RXHASH) + if (!(ring->netdev->features & NETIF_F_RXHASH)) return; if ((rx_desc->wb.qword1.status_error_len & rss_mask) == rss_mask) { From patchwork Tue Mar 14 17:44:22 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13174821 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7A2EC05027 for ; Tue, 14 Mar 2023 17:46:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230373AbjCNRq3 (ORCPT ); Tue, 14 Mar 2023 13:46:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230350AbjCNRqZ (ORCPT ); Tue, 14 Mar 2023 13:46:25 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9E488ACE2F for ; Tue, 14 Mar 2023 10:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678815976; x=1710351976; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Jv32DuHiKdVyamTKXcO/oJUMaAG3+3+JctJNWxvSMGE=; b=QnYlxIjeB8NrBQ0Ic9W0i7RBBpbAg5CGcLhYnw8yY4RWbf6UxTJzxiTH 5wlDy5VUtlFqvLYvfo5Dl8P+OajnZcqfrxl3zpxr3g1a1Ccbs0u6MOI5a 6kz7yKoLjJ5PGKXC9NFvz/LsNZ09j854gyIw9O5MQUD6mybx2s+vvQEYs 8AMMOPMcQ4sXQYzqarpQXruKsqTVrxZ6sS/3vIhVYdMPpMXT2isCH4N+t MT0xNHqLVDYVEflz1ahp7lKbl2ikuChh7mlH7wfzE4LD+V/X8iwI7le8O 2XMZLnoO2ODR84TBbh6CsyMCES3gxkl2hr+nqdcysidfS7xhq5VfBylml g==; X-IronPort-AV: E=McAfee;i="6500,9779,10649"; a="317148707" X-IronPort-AV: E=Sophos;i="5.98,260,1673942400"; d="scan'208";a="317148707" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Mar 2023 10:46:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10649"; a="1008516919" X-IronPort-AV: E=Sophos;i="5.98,260,1673942400"; d="scan'208";a="1008516919" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmsmga005.fm.intel.com with ESMTP; 14 Mar 2023 10:46:05 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Alexander Lobakin , anthony.l.nguyen@intel.com, Larysa Zaremba , Michal Kubiak , Rafal Romanowski Subject: [PATCH net 2/3] iavf: fix non-tunneled IPv6 UDP packet type and hashing Date: Tue, 14 Mar 2023 10:44:22 -0700 Message-Id: <20230314174423.1048526-3-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20230314174423.1048526-1-anthony.l.nguyen@intel.com> References: <20230314174423.1048526-1-anthony.l.nguyen@intel.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org From: Alexander Lobakin Currently, IAVF's decode_rx_desc_ptype() correctly reports payload type of L4 for IPv4 UDP packets and IPv{4,6} TCP, but only L3 for IPv6 UDP. Originally, i40e, ice and iavf were affected. Commit 73df8c9e3e3d ("i40e: Correct UDP packet header for non_tunnel-ipv6") fixed that in i40e, then commit 638a0c8c8861 ("ice: fix incorrect payload indicator on PTYPE") fixed that for ice. IPv6 UDP is L4 obviously. Fix it and make iavf report correct L4 hash type for such packets, so that the stack won't calculate it on CPU when needs it. Fixes: 206812b5fccb ("i40e/i40evf: i40e implementation for skb_set_hash") Reviewed-by: Larysa Zaremba Reviewed-by: Michal Kubiak Signed-off-by: Alexander Lobakin Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Reviewed-by: Leon Romanovsky --- drivers/net/ethernet/intel/iavf/iavf_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/iavf/iavf_common.c b/drivers/net/ethernet/intel/iavf/iavf_common.c index 16c490965b61..dd11dbbd5551 100644 --- a/drivers/net/ethernet/intel/iavf/iavf_common.c +++ b/drivers/net/ethernet/intel/iavf/iavf_common.c @@ -661,7 +661,7 @@ struct iavf_rx_ptype_decoded iavf_ptype_lookup[BIT(8)] = { /* Non Tunneled IPv6 */ IAVF_PTT(88, IP, IPV6, FRG, NONE, NONE, NOF, NONE, PAY3), IAVF_PTT(89, IP, IPV6, NOF, NONE, NONE, NOF, NONE, PAY3), - IAVF_PTT(90, IP, IPV6, NOF, NONE, NONE, NOF, UDP, PAY3), + IAVF_PTT(90, IP, IPV6, NOF, NONE, NONE, NOF, UDP, PAY4), IAVF_PTT_UNUSED_ENTRY(91), IAVF_PTT(92, IP, IPV6, NOF, NONE, NONE, NOF, TCP, PAY4), IAVF_PTT(93, IP, IPV6, NOF, NONE, NONE, NOF, SCTP, PAY4), From patchwork Tue Mar 14 17:44:23 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13174820 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37599C7618A for ; Tue, 14 Mar 2023 17:46:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230208AbjCNRq1 (ORCPT ); Tue, 14 Mar 2023 13:46:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41718 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229820AbjCNRqZ (ORCPT ); Tue, 14 Mar 2023 13:46:25 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF5D7AD01D for ; Tue, 14 Mar 2023 10:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678815976; x=1710351976; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ypcZhK+w4XMjkLLE0oFas/DEQTTHh6MnXuzo3lHU+gI=; b=RvLXtCScJR/7k+UPNN/czuIDpqBXpWlzaTToAc53wDErxtSeKFsTSFqt Lt8hvwTlJ2F5Q8TDlaCcs6ag7ycK/zh0kMmcbKNdOPKs+oBs9PaifQjuE CrbmMS2kNF+QgJIpv8IYhVFz4v1wBydWyNZ12Nv42k9PV4zwtqujIDAqq HjORuj+wVgxOyGml3OvQkmPTzZfaU27tFCpKA/hHIY7s++gLwW1aljGGp sjnI5y0pXrk8VcSLfK+EOxQccyvWNQyqWHnSZcAlMRDluLuV+OAZdEhcn VM8U7oZ2iqiWIPP19j5fDwVdlSiBclHZkwBO3Ud47sBUs38U5aIIIohIS Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10649"; a="317148716" X-IronPort-AV: E=Sophos;i="5.98,260,1673942400"; d="scan'208";a="317148716" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Mar 2023 10:46:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10649"; a="1008516925" X-IronPort-AV: E=Sophos;i="5.98,260,1673942400"; d="scan'208";a="1008516925" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by fmsmga005.fm.intel.com with ESMTP; 14 Mar 2023 10:46:06 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Ahmed Zaki , anthony.l.nguyen@intel.com, Michal Kubiak , Rafal Romanowski Subject: [PATCH net 3/3] iavf: do not track VLAN 0 filters Date: Tue, 14 Mar 2023 10:44:23 -0700 Message-Id: <20230314174423.1048526-4-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20230314174423.1048526-1-anthony.l.nguyen@intel.com> References: <20230314174423.1048526-1-anthony.l.nguyen@intel.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org From: Ahmed Zaki When an interface with the maximum number of VLAN filters is brought up, a spurious error is logged: [257.483082] 8021q: adding VLAN 0 to HW filter on device enp0s3 [257.483094] iavf 0000:00:03.0 enp0s3: Max allowed VLAN filters 8. Remove existing VLANs or disable filtering via Ethtool if supported. The VF driver complains that it cannot add the VLAN 0 filter. On the other hand, the PF driver always adds VLAN 0 filter on VF initialization. The VF does not need to ask the PF for that filter at all. Fix the error by not tracking VLAN 0 filters altogether. With that, the check added by commit 0e710a3ffd0c ("iavf: Fix VF driver counting VLAN 0 filters") in iavf_virtchnl.c is useless and might be confusing if left as it suggests that we track VLAN 0. Fixes: 0e710a3ffd0c ("iavf: Fix VF driver counting VLAN 0 filters") Signed-off-by: Ahmed Zaki Reviewed-by: Michal Kubiak Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/iavf/iavf_main.c | 4 ++++ drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 2 -- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c index 3273aeb8fa67..eb8f944276ff 100644 --- a/drivers/net/ethernet/intel/iavf/iavf_main.c +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c @@ -893,6 +893,10 @@ static int iavf_vlan_rx_add_vid(struct net_device *netdev, { struct iavf_adapter *adapter = netdev_priv(netdev); + /* Do not track VLAN 0 filter, always added by the PF on VF init */ + if (!vid) + return 0; + if (!VLAN_FILTERING_ALLOWED(adapter)) return -EIO; diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c index 6d23338604bb..4e17d006c52d 100644 --- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c +++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c @@ -2446,8 +2446,6 @@ void iavf_virtchnl_completion(struct iavf_adapter *adapter, list_for_each_entry(f, &adapter->vlan_filter_list, list) { if (f->is_new_vlan) { f->is_new_vlan = false; - if (!f->vlan.vid) - continue; if (f->vlan.tpid == ETH_P_8021Q) set_bit(f->vlan.vid, adapter->vsi.active_cvlans);