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 8273BA0613 for ; Mon, 23 Sep 2019 16:41:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5516A1BF04; Mon, 23 Sep 2019 16:41:45 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id A4C5E1BEE8; Mon, 23 Sep 2019 16:41:40 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Sep 2019 07:41:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,540,1559545200"; d="scan'208";a="189079030" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga007.fm.intel.com with ESMTP; 23 Sep 2019 07:41:39 -0700 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 23 Sep 2019 07:41:39 -0700 Received: from fmsmsx117.amr.corp.intel.com ([169.254.3.133]) by FMSMSX157.amr.corp.intel.com ([169.254.14.249]) with mapi id 14.03.0439.000; Mon, 23 Sep 2019 07:41:39 -0700 From: "Wiles, Keith" To: "Smoczynski, MarcinX" CC: "Ananyev, Konstantin" , "adrien.mazarguil@6wind.com" , "Yigit, Ferruh" , "dev@dpdk.org" , "Drost, MariuszX" , "stable@dpdk.org" Thread-Topic: [PATCH v2 1/1] net/tap: fix blocked rx packets error Thread-Index: AQHVchJldOJ9vQLmZ0Gq3kPxnF5taac5yzYA Date: Mon, 23 Sep 2019 14:41:38 +0000 Message-ID: <0F6D6BB2-958A-4EEA-BACF-DB5BFE79A6D0@intel.com> References: <20190902114310.15928-1-marcinx.smoczynski@intel.com> <20190923132247.16860-1-marcinx.smoczynski@intel.com> <20190923132247.16860-2-marcinx.smoczynski@intel.com> In-Reply-To: <20190923132247.16860-2-marcinx.smoczynski@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.202.153] Content-Type: text/plain; charset="us-ascii" Content-ID: <77D55B5D101FE74CA6F21FDD880F2F44@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-stable] [PATCH v2 1/1] net/tap: fix blocked rx packets error 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" > On Sep 23, 2019, at 8:22 AM, Smoczynski, MarcinX wrote: >=20 > When OS sends more packets than are being read with a single > 'rte_eth_rx_burst' call, rx packets are getting stucked in the tap pmd > and are unable to receive, because trigger_seen is getting updated > and consecutive calls are not getting any packets. >=20 > Do not update trigger_seen unless less than a max number of packets were > received allowing next call to receive the rest. >=20 > Remove unnecessary compiler barrier. >=20 > Fixes: a0d8e807d9 ("net/tap: add Rx trigger") > Cc: stable@dpdk.org >=20 > Tested-by: Mariusz Drost > Tested-by: Konstantin Ananyev > Signed-off-by: Marcin Smoczynski > --- > drivers/net/tap/rte_eth_tap.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) >=20 > diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.= c > index 64bd04911..9c3adb832 100644 > --- a/drivers/net/tap/rte_eth_tap.c > +++ b/drivers/net/tap/rte_eth_tap.c > @@ -353,10 +353,8 @@ pmd_rx_burst(void *queue, struct rte_mbuf **bufs, ui= nt16_t nb_pkts) >=20 > if (trigger =3D=3D rxq->trigger_seen) > return 0; > - if (trigger) > - rxq->trigger_seen =3D trigger; > + > process_private =3D rte_eth_devices[rxq->in_port].process_private; > - rte_compiler_barrier(); > for (num_rx =3D 0; num_rx < nb_pkts; ) { > struct rte_mbuf *mbuf =3D rxq->pool; > struct rte_mbuf *seg =3D NULL; > @@ -433,6 +431,9 @@ pmd_rx_burst(void *queue, struct rte_mbuf **bufs, uin= t16_t nb_pkts) > rxq->stats.ipackets +=3D num_rx; > rxq->stats.ibytes +=3D num_rx_bytes; >=20 > + if (trigger && num_rx < nb_pkts) > + rxq->trigger_seen =3D trigger; > + > return num_rx; Looks reasonable to me. I was looking at the code for this patch and notice= d what I believe is a bit odd. The line around 1352 does set req->trigger_seen =3D 1;, but the tap_trigger= global variable is always set to tap_trigger =3D (tap_trigger + 1) | 0x800= 00000; in the signal handler. Just seems the line around 1352 should be set to at least 0x80000001 to beg= in with just to be constant. Not for this patch and maybe it does not matte= r in the long run. Reviewed-by: Keith Wiles > } >=20 > --=20 > 2.17.1 >=20 Regards, Keith