From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id F415EA0568; Mon, 2 Mar 2020 10:00:24 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7D10D1C011; Mon, 2 Mar 2020 10:00:17 +0100 (CET) Received: from inva021.nxp.com (inva021.nxp.com [92.121.34.21]) by dpdk.org (Postfix) with ESMTP id 389081C00D for ; Mon, 2 Mar 2020 10:00:16 +0100 (CET) Received: from inva021.nxp.com (localhost [127.0.0.1]) by inva021.eu-rdc02.nxp.com (Postfix) with ESMTP id C95C720017C; Mon, 2 Mar 2020 10:00:15 +0100 (CET) Received: from invc005.ap-rdc01.nxp.com (invc005.ap-rdc01.nxp.com [165.114.16.14]) by inva021.eu-rdc02.nxp.com (Postfix) with ESMTP id 49C09200F6F; Mon, 2 Mar 2020 10:00:13 +0100 (CET) Received: from bf-netperf1.ap.com (bf-netperf1.ap.freescale.net [10.232.133.63]) by invc005.ap-rdc01.nxp.com (Postfix) with ESMTP id F326540320; Mon, 2 Mar 2020 17:00:08 +0800 (SGT) From: Hemant Agrawal To: ferruh.yigit@intel.com Cc: dev@dpdk.org, g.singh@nxp.com, Alex Marginean Date: Mon, 2 Mar 2020 20:02:00 +0530 Message-Id: <20200302143209.11854-2-hemant.agrawal@nxp.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200302143209.11854-1-hemant.agrawal@nxp.com> References: <20200302143209.11854-1-hemant.agrawal@nxp.com> X-Virus-Scanned: ClamAV using ClamSMTP Subject: [dpdk-dev] [PATCH 01/10] net/enetc: do not stall in clean Tx ring X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" From: Alex Marginean Don't read the hardware CI register in a loop, read it once, clean up and exit. The issue with reading the register in a loop is that we're stalling here trying to catch up with hardware which keeps sending traffic as long as it has traffic to send, so in effect we could be waiting here for the Tx ring to be drained by hardware, instead of us doing Rx in that meantime. At the time we return the function there may be new BDs in the ring that could be cleaned, we're just leaving those there for the next time. Signed-off-by: Alex Marginean --- drivers/net/enetc/enetc_rxtx.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/net/enetc/enetc_rxtx.c b/drivers/net/enetc/enetc_rxtx.c index 81b0ef3b1..b7ecb75ec 100644 --- a/drivers/net/enetc/enetc_rxtx.c +++ b/drivers/net/enetc/enetc_rxtx.c @@ -1,5 +1,5 @@ /* SPDX-License-Identifier: BSD-3-Clause - * Copyright 2018-2019 NXP + * Copyright 2018-2020 NXP */ #include @@ -21,12 +21,24 @@ enetc_clean_tx_ring(struct enetc_bdr *tx_ring) { int tx_frm_cnt = 0; struct enetc_swbd *tx_swbd; - int i; + int i, hwci; i = tx_ring->next_to_clean; tx_swbd = &tx_ring->q_swbd[i]; - while ((int)(enetc_rd_reg(tx_ring->tcisr) & - ENETC_TBCISR_IDX_MASK) != i) { + + hwci = (int)(enetc_rd_reg(tx_ring->tcisr) & + ENETC_TBCISR_IDX_MASK); + + /* we're only reading the CI index once here, which means HW may update + * it while we're doing clean-up. We could read the register in a loop + * but for now I assume it's OK to leave a few Tx frames for next call. + * The issue with reading the register in a loop is that we're stalling + * here trying to catch up with HW which keeps sending traffic as long + * as it has traffic to send, so in effect we could be waiting here for + * the Tx ring to be drained by HW, instead of us doing Rx in that + * meantime. + */ + while (i != hwci) { rte_pktmbuf_free(tx_swbd->buffer_addr); tx_swbd->buffer_addr = NULL; tx_swbd++; -- 2.17.1