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 27C2BA2EEB for ; Tue, 10 Sep 2019 06:14:14 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DC7E41E92F; Tue, 10 Sep 2019 06:14:13 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 3F56A1E8C5; Tue, 10 Sep 2019 06:14:11 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Sep 2019 21:14:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,487,1559545200"; d="scan'208";a="200201277" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga001.fm.intel.com with ESMTP; 09 Sep 2019 21:14:09 -0700 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 9 Sep 2019 21:14:09 -0700 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 9 Sep 2019 21:14:09 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Mon, 9 Sep 2019 21:14:09 -0700 Received: from shsmsx105.ccr.corp.intel.com ([169.254.11.23]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.132]) with mapi id 14.03.0439.000; Tue, 10 Sep 2019 12:14:07 +0800 From: "Zhang, Qi Z" To: "Ye, Xiaolong" , "Yigit, Ferruh" , "Loftus, Ciara" CC: "dev@dpdk.org" , "stable@dpdk.org" Thread-Topic: [PATCH] net/af_xdp: fix Tx halt when no recv packets Thread-Index: AQHVZyn0j3SRA/CA602neNGCmkpco6ckSvoQ Date: Tue, 10 Sep 2019 04:14:06 +0000 Message-ID: <039ED4275CED7440929022BC67E7061153D93589@SHSMSX105.ccr.corp.intel.com> References: <20190909161247.61801-1-xiaolong.ye@intel.com> In-Reply-To: <20190909161247.61801-1-xiaolong.ye@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNWIwODA0MTgtM2ZlNC00ZDUzLTliZDEtMjFhZGRhMjVlZjY2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiZlJSQks0M1wvOEljRmRVd1dJSFJnSUNuTDd2OEdnYlA1RTZJSmVCV1wvSnRENWJROEZEeU9iREpPQStKNldlRWRzIn0= 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-dev] [PATCH] net/af_xdp: fix Tx halt when no recv packets 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" > -----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 >=20 > The kernel only consumes Tx packets if we have some Rx traffic on specifi= ed > queue or we have called send(). So we need to issue a send() even when th= e > allocation fails so that kernel will start to consume packets again. So "allocation fails" means " xsk_ring_prod__reserve" fail right? I don't understand when xsk_ring_prod__needs_wakeup is true why kernel will= stop Tx packet at this situation=20 would you share more insight? Thanks Qi >=20 > Commit 45bba02c95b0 ("net/af_xdp: support need wakeup feature") breaks > above rule by adding some condition to send, this patch fixes it while st= ill > keeps the need_wakeup feature for Tx. >=20 > Fixes: 45bba02c95b0 ("net/af_xdp: support need wakeup feature") > Cc: stable@dpdk.org >=20 > Signed-off-by: Xiaolong Ye > --- > drivers/net/af_xdp/rte_eth_af_xdp.c | 28 ++++++++++++++-------------- > 1 file changed, 14 insertions(+), 14 deletions(-) >=20 > 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; >=20 > -#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); } >=20 > @@ -367,7 +364,10 @@ eth_af_xdp_tx(void *queue, struct rte_mbuf > **bufs, uint16_t nb_pkts) >=20 > xsk_ring_prod__submit(&txq->tx, nb_pkts); >=20 > - kick_tx(txq); > +#if defined(XDP_USE_NEED_WAKEUP) > + if (xsk_ring_prod__needs_wakeup(&txq->tx)) > +#endif > + kick_tx(txq); >=20 > txq->stats.tx_pkts +=3D nb_pkts; > txq->stats.tx_bytes +=3D tx_bytes; > -- > 2.17.1