> From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] > Sent: Monday, June 4, 2018 9:20 AM > To: bugzi...@dpdk.org > Cc: dev@dpdk.org; Van Haaren, Harry <harry.van.haa...@intel.com>; Ma, Liang > J <liang.j...@intel.com>; hemant.agra...@nxp.com; sunil.k...@nxp.com; > nipun.gu...@nxp.com > Subject: Re: [dpdk-dev] [Bug 60] rte_event_port_unlink() causes subsequent > events to end up in wrong port > > -----Original Message----- > > Date: Mon, 4 Jun 2018 07:21:18 +0000 > > From: bugzi...@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....@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.haa...@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.
Hi Matias, Thanks for opening, from memory the sw_port_unlink() API does attempt to handle 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 array 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? Unfortunately I will be away until next week, but I will check up on this thread once I'm back in the office. Regards, -Harry
