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 DBF43A2EDB for ; Fri, 6 Sep 2019 10:48:10 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CED881F16F; Fri, 6 Sep 2019 10:48:10 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 4EF881F16F; Fri, 6 Sep 2019 10:48:09 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2019 01:48:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,472,1559545200"; d="scan'208";a="213080862" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga002.fm.intel.com with ESMTP; 06 Sep 2019 01:48:08 -0700 Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 6 Sep 2019 01:48:08 -0700 Received: from hasmsx112.ger.corp.intel.com (10.184.198.40) by FMSMSX157.amr.corp.intel.com (10.18.116.73) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 6 Sep 2019 01:48:07 -0700 Received: from HASMSX110.ger.corp.intel.com ([169.254.6.228]) by HASMSX112.ger.corp.intel.com ([169.254.11.117]) with mapi id 14.03.0439.000; Fri, 6 Sep 2019 11:48:04 +0300 From: "Smoczynski, MarcinX" To: "Gavin Hu (Arm Technology China)" , "Ananyev, Konstantin" , "Wiles, Keith" , "adrien.mazarguil@6wind.com" CC: "dev@dpdk.org" , "stable@dpdk.org" , "Drost, MariuszX" Thread-Topic: [dpdk-dev] [PATCH v1] net/tap: fix blocked rx packets error Thread-Index: AQHVYYP9zr8cKZ9P+kuNZJfGdPhVg6ccZH+AgAHxyRA= Date: Fri, 6 Sep 2019 08:48:04 +0000 Message-ID: <2F25558C1648FA498380EAC12A86126215FFBB79@HASMSX110.ger.corp.intel.com> References: <20190902114310.15928-1-marcinx.smoczynski@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZmFhOTk5YmQtNjE0Mi00Yzc0LWE4MDEtN2YxNDA0ZTU1MWQ0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiUFd1TWFVVG53K0pJVzVaU0NwXC9kcVdzQll0QUNRTjZ1VER0bjVIQ1wva3NhQlRiTE1tQWRuWHNKZERQVnkrYndOIn0= x-originating-ip: [10.184.70.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v1] 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" > -----Original Message----- > From: Gavin Hu (Arm Technology China) [mailto:Gavin.Hu@arm.com] > Sent: Thursday, September 5, 2019 7:44 AM > To: Smoczynski, MarcinX ; Ananyev, > Konstantin ; Wiles, Keith > ; adrien.mazarguil@6wind.com > Cc: dev@dpdk.org; stable@dpdk.org; Drost, MariuszX > > Subject: RE: [dpdk-dev] [PATCH v1] net/tap: fix blocked rx packets error >=20 > HI Marcin, >=20 > > -----Original Message----- > > From: dev On Behalf Of Marcin Smoczynski > > Sent: Monday, September 2, 2019 7:43 PM > > To: konstantin.ananyev@intel.com; keith.wiles@intel.com; > > adrien.mazarguil@6wind.com > > Cc: dev@dpdk.org; stable@dpdk.org; Marcin Smoczynski > > ; Mariusz Drost > > > > Subject: [dpdk-dev] [PATCH v1] net/tap: fix blocked rx packets error > > > > When OS sends more packets than are beaing read with a single > s/ beaing/being Thanks for that, will be corrected in the v2. >=20 > > '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. > > > > Do not update trigger_seen unless less than a max number of packets > > were received allowing next call to receive the rest. > > > > Fixes: a0d8e807d9 ("net/tap: add Rx trigger") > > Cc: stable@dpdk.org > > > > Tested-by: Mariusz Drost > > Signed-off-by: Marcin Smoczynski > > --- > > drivers/net/tap/rte_eth_tap.c | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/net/tap/rte_eth_tap.c > > b/drivers/net/tap/rte_eth_tap.c index 64bd04911..60121ae56 100644 > > --- a/drivers/net/tap/rte_eth_tap.c > > +++ b/drivers/net/tap/rte_eth_tap.c > > @@ -353,8 +353,7 @@ pmd_rx_burst(void *queue, struct rte_mbuf > **bufs, > > uint16_t nb_pkts) > > > > 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(); > I see this compiler barrier was added together with the above "rxq- > >trigger_seen =3D trigger", should it be removed or moved together > downwards? I think it could be removed, but it is best to ask author of the original c= ode. Adrien, what do you think about removing this barrier? =20 >=20 > > for (num_rx =3D 0; num_rx < nb_pkts; ) { @@ -433,6 +432,9 @@ > > pmd_rx_burst(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts) > > rxq->stats.ipackets +=3D num_rx; > > rxq->stats.ibytes +=3D num_rx_bytes; > > > > + if (trigger && num_rx < nb_pkts) > > + rxq->trigger_seen =3D trigger; > > + > > return num_rx; > > } > > > > -- > > 2.17.1 >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended reci= pient, > please notify the sender immediately and do not disclose the contents to = any > other person, use it for any purpose, or store or copy the information in= any > medium. Thank you.