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 86397A2EEB for ; Wed, 11 Sep 2019 02:12:12 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4C01F1EB95; Wed, 11 Sep 2019 02:12:12 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 2EC6F1EB71; Wed, 11 Sep 2019 02:12:07 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Sep 2019 17:12:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,491,1559545200"; d="scan'208";a="187018138" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga003.jf.intel.com with ESMTP; 10 Sep 2019 17:12:06 -0700 Received: from fmsmsx121.amr.corp.intel.com (10.18.125.36) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 10 Sep 2019 17:12:06 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx121.amr.corp.intel.com (10.18.125.36) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 10 Sep 2019 17:12:05 -0700 Received: from shsmsx105.ccr.corp.intel.com ([169.254.11.23]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.53]) with mapi id 14.03.0439.000; Wed, 11 Sep 2019 08:12:03 +0800 From: "Zhang, Qi Z" To: "Ye, Xiaolong" CC: "Yigit, Ferruh" , "Loftus, Ciara" , "dev@dpdk.org" , "stable@dpdk.org" , "Karlsson, Magnus" Thread-Topic: [PATCH] net/af_xdp: fix Tx halt when no recv packets Thread-Index: AQHVZyn0j3SRA/CA602neNGCmkpco6ckSvoQgAAe64CAAImBoA== Date: Wed, 11 Sep 2019 00:12:02 +0000 Message-ID: <039ED4275CED7440929022BC67E7061153D93E5D@SHSMSX105.ccr.corp.intel.com> References: <20190909161247.61801-1-xiaolong.ye@intel.com> <039ED4275CED7440929022BC67E7061153D93589@SHSMSX105.ccr.corp.intel.com> <20190910135347.GD6732@intel.com> In-Reply-To: <20190910135347.GD6732@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGYzYzdjNzYtZGJiMS00NGNjLTgyYmQtYjk3NzliNmY3YjNmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiNzFXekF4MFF3OFJGRWFaUVNROHk0YXlIc3l2b1NEaXhYVkNFVUFERGlKSnBzRW5QY2FFVGNzN0I4Z3dNdzFvTyJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-stable] [PATCH] net/af_xdp: fix Tx halt when no recv packets X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" > -----Original Message----- > From: Ye, Xiaolong > Sent: Tuesday, September 10, 2019 9:54 PM > To: Zhang, Qi Z > Cc: Yigit, Ferruh ; Loftus, Ciara > ; dev@dpdk.org; stable@dpdk.org; Karlsson, > Magnus > Subject: Re: [PATCH] net/af_xdp: fix Tx halt when no recv packets >=20 > On 09/10, Zhang, Qi Z wrote: > > > > > >> -----Original Message----- > >> From: Ye, Xiaolong > >> Sent: Tuesday, September 10, 2019 12:13 AM > >> To: Yigit, Ferruh ; Loftus, Ciara > >> ; Ye, Xiaolong ; > >> Zhang, Qi Z > >> Cc: dev@dpdk.org; stable@dpdk.org > >> Subject: [PATCH] net/af_xdp: fix Tx halt when no recv packets > >> > >> The kernel only consumes Tx packets if we have some Rx traffic on > >> specified queue or we have called send(). So we need to issue a > >> send() even when the allocation fails so that kernel will start to con= sume > packets again. > > > >So "allocation fails" means " xsk_ring_prod__reserve" fail right? >=20 > Yes. >=20 > >I don't understand when xsk_ring_prod__needs_wakeup is true why kernel > >will stop Tx packet at this situation would you share more insight? >=20 > Actually, the fail case is xsk_ring_prod__needs_wakeup is false, then we > can't issue a send() when xsk_ring_prod__reserve fails. Sorry, I think my question should be for the case when xsk_ring_prod__needs= _wakeup is false, I don't understand why we need to handle different at below two situations 1. when xsk_ring_prod__reserve fails 2. normal tx scenario. My understanding is when xsk_ring_prod__needs_wakeup(tx) is false, which me= ans Tx is ongoing, we don't need to wake up kernel to continue. >=20 > Thanks, > Xiaolong >=20 > > > >Thanks > >Qi > > > >> > >> Commit 45bba02c95b0 ("net/af_xdp: support need wakeup feature") > >> breaks above rule by adding some condition to send, this patch fixes > >> it while still keeps the need_wakeup feature for Tx. > >> > >> Fixes: 45bba02c95b0 ("net/af_xdp: support need wakeup feature") > >> Cc: stable@dpdk.org > >> > >> Signed-off-by: Xiaolong Ye > >> --- > >> drivers/net/af_xdp/rte_eth_af_xdp.c | 28 > >> ++++++++++++++-------------- > >> 1 file changed, 14 insertions(+), 14 deletions(-) > >> > >> diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c > >> b/drivers/net/af_xdp/rte_eth_af_xdp.c > >> index 41ed5b2af..e496e9aaa 100644 > >> --- a/drivers/net/af_xdp/rte_eth_af_xdp.c > >> +++ b/drivers/net/af_xdp/rte_eth_af_xdp.c > >> @@ -286,19 +286,16 @@ kick_tx(struct pkt_tx_queue *txq) { > >> struct xsk_umem_info *umem =3D txq->pair->umem; > >> > >> -#if defined(XDP_USE_NEED_WAKEUP) > >> - if (xsk_ring_prod__needs_wakeup(&txq->tx)) > >> -#endif > >> - while (send(xsk_socket__fd(txq->pair->xsk), NULL, > >> - 0, MSG_DONTWAIT) < 0) { > >> - /* some thing unexpected */ > >> - if (errno !=3D EBUSY && errno !=3D EAGAIN && errno !=3D EINTR) > >> - break; > >> - > >> - /* pull from completion queue to leave more space */ > >> - if (errno =3D=3D EAGAIN) > >> - pull_umem_cq(umem, ETH_AF_XDP_TX_BATCH_SIZE); > >> - } > >> + while (send(xsk_socket__fd(txq->pair->xsk), NULL, > >> + 0, MSG_DONTWAIT) < 0) { > >> + /* some thing unexpected */ > >> + if (errno !=3D EBUSY && errno !=3D EAGAIN && errno !=3D EINTR) > >> + break; > >> + > >> + /* pull from completion queue to leave more space */ > >> + if (errno =3D=3D EAGAIN) > >> + pull_umem_cq(umem, ETH_AF_XDP_TX_BATCH_SIZE); > >> + } > >> pull_umem_cq(umem, ETH_AF_XDP_TX_BATCH_SIZE); } > >> > >> @@ -367,7 +364,10 @@ eth_af_xdp_tx(void *queue, struct rte_mbuf > >> **bufs, uint16_t nb_pkts) > >> > >> xsk_ring_prod__submit(&txq->tx, nb_pkts); > >> > >> - kick_tx(txq); > >> +#if defined(XDP_USE_NEED_WAKEUP) > >> + if (xsk_ring_prod__needs_wakeup(&txq->tx)) > >> +#endif > >> + kick_tx(txq); > >> > >> txq->stats.tx_pkts +=3D nb_pkts; > >> txq->stats.tx_bytes +=3D tx_bytes; > >> -- > >> 2.17.1 > >