From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 16AB51BAE4; Tue, 5 Jun 2018 18:43:29 +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 orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jun 2018 09:43:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,479,1520924400"; d="scan'208";a="54038622" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by fmsmga002.fm.intel.com with ESMTP; 05 Jun 2018 09:43:27 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.146]) by IRSMSX107.ger.corp.intel.com ([169.254.10.238]) with mapi id 14.03.0319.002; Tue, 5 Jun 2018 17:43:26 +0100 From: "Van Haaren, Harry" To: Jerin Jacob , "bugzilla@dpdk.org" CC: "dev@dpdk.org" , "Ma, Liang J" , "hemant.agrawal@nxp.com" , "sunil.kori@nxp.com" , "nipun.gupta@nxp.com" Thread-Topic: [dpdk-dev] [Bug 60] rte_event_port_unlink() causes subsequent events to end up in wrong port Thread-Index: AQHT+9TFc0zont8ExUSZd2OJFy28UKRPsTsAgAIsm+A= Date: Tue, 5 Jun 2018 16:43:26 +0000 Message-ID: References: <20180604081959.GA20978@jerin> In-Reply-To: <20180604081959.GA20978@jerin> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTVmNzVmNjEtODY0ZC00MmRjLWFhYTktYjM2OGY2YTg4OGNiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoieVFHQVlOR2lvMU93SU93MU1mT051UlBMWXYxSnhYeVNWUzBEa2h5RndOZkEyMmo4UnRJcFdJdVF4Y0VYYmdLdSJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [Bug 60] rte_event_port_unlink() causes subsequent events to end up in wrong port 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: , X-List-Received-Date: Tue, 05 Jun 2018 16:43:31 -0000 > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Monday, June 4, 2018 9:20 AM > To: bugzilla@dpdk.org > Cc: dev@dpdk.org; Van Haaren, Harry ; Ma, Lia= ng > J ; hemant.agrawal@nxp.com; sunil.kori@nxp.com; > nipun.gupta@nxp.com > Subject: Re: [dpdk-dev] [Bug 60] rte_event_port_unlink() causes subsequen= t > events to end up in wrong port >=20 > -----Original Message----- > > Date: Mon, 4 Jun 2018 07:21:18 +0000 > > From: bugzilla@dpdk.org > > To: dev@dpdk.org > > Subject: [dpdk-dev] [Bug 60] rte_event_port_unlink() causes subsequent > > events to end up in wrong port > > > > https://dpdk.org/tracker/show_bug.cgi?id=3D60 > > > > Bug ID: 60 > > Summary: rte_event_port_unlink() causes subsequent events to > > end up in wrong port > > Product: DPDK > > Version: 17.11 > > Hardware: x86 > > OS: Linux > > Status: CONFIRMED > > Severity: major > > Priority: Normal > > Component: eventdev > > Assignee: dev@dpdk.org > > Reporter: matias.elo@nokia.com > > Target Milestone: --- > > > > Created attachment 8 > > --> https://dpdk.org/tracker/attachment.cgi?id=3D8&action=3Dedit > > Test application > > > > I'm seeing some unexpected(?) behavior when calling > rte_event_port_unlink() > > with the SW eventdev driver (DPDK 17.11.2/18.02.1, > > RTE_EVENT_MAX_QUEUES_PER_DEV=3D255). After calling rte_event_port_unlin= k(), > > the enqueued events may end up either back to the unlinked port or to p= ort > > zero. > > > > Scenario: > > > > - Run SW evendev on a service core > > - Start eventdev with e.g. 16 ports. Each core will have a dedicated po= rt. > > - Create 1 atomic queue and link all active ports to it (some ports may > not > > be linked). > > - Allocate some events and enqueue them to the created queue > > - Next, each worker core does a number of scheduling rounds concurrentl= y. > > E.g. > > > > uint64_t rx_events =3D 0; > > while(rx_events < SCHED_ROUNDS) { > > num_deq =3D rte_event_dequeue_burst(dev_id, port_id, ev, 1, 0); > > > > if (num_deq) { > > rx_events++; > > rte_event_enqueue_burst(dev_id, port_id, ev, 1); > > } > > } > > > > - This works fine but problems occur when doing cleanup after the first > > loop finishes on some core. > > E.g. > > > > rte_event_port_unlink(dev_id, port_id, NULL, 0); > > > > while(1) { > > num_deq =3D rte_event_dequeue_burst(dev_id, port_id, ev, 1, 0); > > > > if (num_deq =3D=3D 0) > > break; > > > > rte_event_enqueue_burst(dev_id, port_id, ev, 1); > > } > > > > - The events enqueued in the cleanup loop will ramdomly end up either b= ack > to > > the same port (which has already been unlinked) or to port zero, which = is > not > > used (mapping rte_lcore_id to port_id). > > > > As far as I understand the eventdev API, an eventdev port shouldn't hav= e > to be > > linked to the target queue for enqueue to work properly. >=20 > That is a grey area in the spec. octeontx drivers works as the way you > described. I am not sure about SW driver(CC: > harry.van.haaren@intel.com), If there is no performance impact for none o= f > the drivers and it is do able for all HW and SW implementation then can > do that way(CC: all PMD maintainers) >=20 > No related to this question, Are you planning to use rte_event_port_unlin= k() > in fastpath? > Does rte_event_stop() works for you, if it is in slow path. Hi Matias, Thanks for opening, from memory the sw_port_unlink() API does attempt to ha= ndle that correctly. Having a quick look, we scan for the port to unlink, from the queue, and if= we find the queue->port combination, we copy the furthest link in the arra= y to the found position, and reduce num mapped queues by one (aka, we keep = the array contiguous from 0 to num_mapped_queues). The appropriate rte_smp_wmb() is in place to avoid race-conditions between = threads there.. I think this should handle the unlink case you mention, however perhaps you= have identified a genuine bug. If you have more info or a sample config / = app that easily demonstrates the issue that would help reproduce/debug here= ?=20 Unfortunately I will be away until next week, but I will check up on this t= hread once I'm back in the office. Regards, -Harry