-----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.
