Re: [dpdk-dev] [Bug 60] rte_event_port_unlink() causes subsequent events to end up in wrong port

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

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