From patchwork Mon Sep 30 22:35:54 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tony Nguyen X-Patchwork-Id: 13817195 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (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 362511991B1 for ; Mon, 30 Sep 2024 22:36:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735773; cv=none; b=LrwjbOv0U4qqo5l9KLy/1Hf6xBxiXmLosvPlFn4s266bYSt84k43CtQzLyNme9+LqzURjf+8U8QVhO8BRnaodZVWfv7aZCkeBriAT1fS2c8p+8GGci2Yyr1wPrDhcfxbyhtKOq+jRhyNvNLQDkRyn7Q/o6bg8wf9eJvyc9C/NPk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727735773; c=relaxed/simple; bh=XDfzUmMR9gfBvOMfEefkdkONMEQInv3V5Rxu4mIhN20=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mBD+7G6H3MN7ySTBmXIYXBQR35LPZEEuYYllzdihf7OQ7OkOZa58gf9z8Z8U+7G2OLENcX4lKlVEv4sqpo7jNRKWLDQQRMLD8qmLZdkgJgSEoZ+VIKizKZAyg3ZGAEICQ6hKJs7ziQOHlbqGAfY2uPh2s+xyY1jqb9ZMaJuI6os= 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=V8TEk+Mn; arc=none smtp.client-ip=192.198.163.12 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="V8TEk+Mn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1727735771; x=1759271771; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=XDfzUmMR9gfBvOMfEefkdkONMEQInv3V5Rxu4mIhN20=; b=V8TEk+MnHe0zpZeMc+OeywA1dVcDOOYlrx8uqLe6YqyWth6qj3/5KnO5 lhFwqSsgyHJy8RnJ3BJKoM2Jc3bHJkVoikmjLyRnyTgPTtyhbpmBaVqsG LwePhoT7w7x4BGJ0JgC7g2OfRDnQDknrMa3lxSPNPnJcpQR96O+B1uHJ5 QqEAk6W7xqHoWGkM3sM8+dB2ngqpth2/Qal1uXqtb8GXT6BAliUTnPdGU JEVkwuglCXfeeyDYQyR1CPrcdeeYyK4/LiQ+wpJglIQGBASaCKDAJQAx4 Uk69ybkf8CPnCUDkVgwsTbv+6N4DHBtUbrnuDeG3zirlgV5el6fyCpdK1 A==; X-CSE-ConnectionGUID: tWO4PFlQRSi95S0gyUnMMw== X-CSE-MsgGUID: MquZxhBiSK2Er7U49t66/g== X-IronPort-AV: E=McAfee;i="6700,10204,11211"; a="30734892" X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="30734892" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2024 15:36:06 -0700 X-CSE-ConnectionGUID: aJUwVPFrSImK6L1zXyH94A== X-CSE-MsgGUID: r+cMTNpvSiqpiGmDnQTbWg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,166,1725346800"; d="scan'208";a="73496626" Received: from anguy11-upstream.jf.intel.com ([10.166.9.133]) by orviesa009.jf.intel.com with ESMTP; 30 Sep 2024 15:36:07 -0700 From: Tony Nguyen To: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, edumazet@google.com, netdev@vger.kernel.org Cc: Dave Ertman , anthony.l.nguyen@intel.com, Przemek Kitszel , Jacob Keller , Pucha Himasekhar Reddy Subject: [PATCH net 07/10] ice: fix VLAN replay after reset Date: Mon, 30 Sep 2024 15:35:54 -0700 Message-ID: <20240930223601.3137464-8-anthony.l.nguyen@intel.com> X-Mailer: git-send-email 2.46.0.522.gc50d79eeffbf In-Reply-To: <20240930223601.3137464-1-anthony.l.nguyen@intel.com> References: <20240930223601.3137464-1-anthony.l.nguyen@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 From: Dave Ertman There is a bug currently when there are more than one VLAN defined and any reset that affects the PF is initiated, after the reset rebuild no traffic will pass on any VLAN but the last one created. This is caused by the iteration though the VLANs during replay each clearing the vsi_map bitmap of the VSI that is being replayed. The problem is that during rhe replay, the pointer to the vsi_map bitmap is used by each successive vlan to determine if it should be replayed on this VSI. The logic was that the replay of the VLAN would replace the bit in the map before the next VLAN would iterate through. But, since the replay copies the old bitmap pointer to filt_replay_rules and creates a new one for the recreated VLANS, it does not do this, and leaves the old bitmap broken to be used to replay the remaining VLANs. Since the old bitmap will be cleaned up in post replay cleanup, there is no need to alter it and break following VLAN replay, so don't clear the bit. Fixes: 334cb0626de1 ("ice: Implement VSI replay framework") Reviewed-by: Przemek Kitszel Signed-off-by: Dave Ertman Reviewed-by: Jacob Keller Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen --- drivers/net/ethernet/intel/ice/ice_switch.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c index 79d91e95358c..0e740342e294 100644 --- a/drivers/net/ethernet/intel/ice/ice_switch.c +++ b/drivers/net/ethernet/intel/ice/ice_switch.c @@ -6322,8 +6322,6 @@ ice_replay_vsi_fltr(struct ice_hw *hw, u16 vsi_handle, u8 recp_id, if (!itr->vsi_list_info || !test_bit(vsi_handle, itr->vsi_list_info->vsi_map)) continue; - /* Clearing it so that the logic can add it back */ - clear_bit(vsi_handle, itr->vsi_list_info->vsi_map); f_entry.fltr_info.vsi_handle = vsi_handle; f_entry.fltr_info.fltr_act = ICE_FWD_TO_VSI; /* update the src in case it is VSI num */