From patchwork Wed Mar 5 16:21:21 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Lobakin X-Patchwork-Id: 14002950 X-Patchwork-Delegate: kuba@kernel.org Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) (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 9D2682512E6; Wed, 5 Mar 2025 16:22:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741191758; cv=none; b=YpYuXVm0hzqIXud9tqzIYaG98tDEZtgQpYeL6FV859vEPCBvu2VWiaGkTzTReCRhYpnDCbkpZpOrrakUWIe/MKqXuu+GAzHwkshF0+ZRCZJrgodUvMaMxbL40bpIThFEiDrhFpF5Uf2IWpYGvHOBmwu50uZgVFjBZvfGwmWuCLg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741191758; c=relaxed/simple; bh=KISi81PW5uI6HavTQsyuz/rieJO5h1l02sGDkGz6rAw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=i2M2vN1tkgNPUbhaM3fRmfGXWH4EzY3MRNIU+7T8UUo6R9kSIAbTIrbsvPr62xaofvpXRRm6tDLaykANlclcjgTPsok+9UG5eRiY8mcQkVQysc0nvi/u2g8X+dshg7YVbjwt/JKibvmA56Lr/vN0M7csd5HdE7CtgDU8GrXIs3k= 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=iyw532AJ; arc=none smtp.client-ip=198.175.65.19 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="iyw532AJ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1741191757; x=1772727757; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=KISi81PW5uI6HavTQsyuz/rieJO5h1l02sGDkGz6rAw=; b=iyw532AJsxpnRcCGTfk964MupDiRauo+xb3XCxgiE9+vesfm/0PSqaKa Y74vQzZfdLBGplZ9QzvlrFnZqrY+2BjuQoeah0eOpxCCtOrBGw91zmyHk TiTHXMc2FP/rKbMGxZGoRAfHtPzo4GWKLTKyNEf/EGbjEfppleH6dSPEk lowuSkMUvAV5qmwTYE+bnVZx4RssfeBtWQrUkphAIZV3If9yqr+XplWre MQBCMH9iO+lrGymSPf91NiRe3BsWOMbgADGma8JgKcNJ5IeJKuhfFfYP+ A9UbWSbk5mHc7HM9skl9MkHVqOoYsF846ldAVZv0132uSYbozw2/3PMIv A==; X-CSE-ConnectionGUID: iTCFCzJzQyy3aCvlCZP/Vg== X-CSE-MsgGUID: 6o4NJ0DgRJmfVOsLekBAgg== X-IronPort-AV: E=McAfee;i="6700,10204,11363"; a="42026445" X-IronPort-AV: E=Sophos;i="6.14,223,1736841600"; d="scan'208";a="42026445" Received: from fmviesa004.fm.intel.com ([10.60.135.144]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Mar 2025 08:22:36 -0800 X-CSE-ConnectionGUID: 7K+xgifxSRGjYIWcxR2X3A== X-CSE-MsgGUID: TiQbwjE0TS6dB6LfIEbQUQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,223,1736841600"; d="scan'208";a="123832884" Received: from newjersey.igk.intel.com ([10.102.20.203]) by fmviesa004.fm.intel.com with ESMTP; 05 Mar 2025 08:22:32 -0800 From: Alexander Lobakin To: intel-wired-lan@lists.osuosl.org Cc: Alexander Lobakin , Michal Kubiak , Maciej Fijalkowski , Tony Nguyen , Przemek Kitszel , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Simon Horman , bpf@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH net-next 05/16] idpf: fix Rx descriptor ready check barrier in splitq Date: Wed, 5 Mar 2025 17:21:21 +0100 Message-ID: <20250305162132.1106080-6-aleksander.lobakin@intel.com> X-Mailer: git-send-email 2.48.1 In-Reply-To: <20250305162132.1106080-1-aleksander.lobakin@intel.com> References: <20250305162132.1106080-1-aleksander.lobakin@intel.com> Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Delegate: kuba@kernel.org No idea what the current barrier position was meant for. At that point, nothing is read from the descriptor, only the pointer to the actual one is fetched. The correct barrier usage here is after the generation check, so that only the first qword is read if the descriptor is not yet ready and we need to stop polling. Debatable on coherent DMA as the Rx descriptor size is <= cacheline size, but anyway, the current barrier position only makes the codegen worse. Fixes: 3a8845af66ed ("idpf: add RX splitq napi poll support") Signed-off-by: Alexander Lobakin --- drivers/net/ethernet/intel/idpf/idpf_txrx.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c index 6254806c2072..c15833928ea1 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c @@ -3232,18 +3232,14 @@ static int idpf_rx_splitq_clean(struct idpf_rx_queue *rxq, int budget) /* get the Rx desc from Rx queue based on 'next_to_clean' */ rx_desc = &rxq->rx[ntc].flex_adv_nic_3_wb; - /* This memory barrier is needed to keep us from reading - * any other fields out of the rx_desc - */ - dma_rmb(); - /* if the descriptor isn't done, no work yet to do */ gen_id = le16_get_bits(rx_desc->pktlen_gen_bufq_id, VIRTCHNL2_RX_FLEX_DESC_ADV_GEN_M); - if (idpf_queue_has(GEN_CHK, rxq) != gen_id) break; + dma_rmb(); + rxdid = FIELD_GET(VIRTCHNL2_RX_FLEX_DESC_ADV_RXDID_M, rx_desc->rxdid_ucast); if (rxdid != VIRTCHNL2_RXDID_2_FLEX_SPLITQ) {