From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [Bug 60] rte_event_port_unlink() causes subsequent events to end up in wrong port Date: Mon, 4 Jun 2018 13:50:00 +0530 Message-ID: <20180604081959.GA20978@jerin> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dev@dpdk.org, harry.van.haaren@intel.com, liang.j.ma@intel.com, hemant.agrawal@nxp.com, sunil.kori@nxp.com, nipun.gupta@nxp.com To: bugzilla@dpdk.org Return-path: Content-Disposition: inline In-Reply-To: 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----- > 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=60 > > 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=8&action=edit > 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=255). After calling rte_event_port_unlink(), > the enqueued events may end up either back to the unlinked port or to port > zero. > > Scenario: > > - Run SW evendev on a service core > - Start eventdev with e.g. 16 ports. Each core will have a dedicated port. > - 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 concurrently. > E.g. > > uint64_t rx_events = 0; > while(rx_events < SCHED_ROUNDS) { > num_deq = 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 = rte_event_dequeue_burst(dev_id, port_id, ev, 1, 0); > > if (num_deq == 0) > break; > > rte_event_enqueue_burst(dev_id, port_id, ev, 1); > } > > - The events enqueued in the cleanup loop will ramdomly end up either back 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 have to be > linked to the target queue for enqueue to work properly. 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 of the drivers and it is do able for all HW and SW implementation then can do that way(CC: all PMD maintainers) No related to this question, Are you planning to use rte_event_port_unlink() in fastpath? Does rte_event_stop() works for you, if it is in slow path.