Re: [dpdk-dev] eventdev: method for finding out unlink status

["Elo, Matias (Nokia - FI/Espoo)" <matias.elo@nokia.com>]

>> 
>> In bug report https://bugs.dpdk.org/show_bug.cgi?id=60 we have been discussing
>> issues related to events ending up in wrong ports after calling
>> rte_event_port_unlink(). In addition of finding few bugs we have identified a
>> need for a new API call (or documentation extension) for an application to be
> 
> From HW perspective, documentation extension should be enough. adding 
> "there may be pre-scheduled events and the application is responsible to process them"
> on unlink(). Since dequeue() has which queue it is dequeue-ed from, the
> application can allays make action based on that(i.e, Is the event
> post/pre to unlink)

At least in case of SW eventdev the problem is how the application can know that
it has processed all pre-scheduled events. E.g. dequeue may return nothing but since
the scheduler is running as a separate process events may still end up to the unlinked
port asynchronously.

> 
>> able to find out when an unlink() call has finished and no new events are
>> scheduled anymore to the particular event port. This is required e.g. when doing
>> clean-up after an application thread stops processing events.
> 
> If thread stopping then it better to call dev_stop(). At least in HW
> implementation,

For an application doing dynamic load balancing stopping the whole eventdev is not an
option.

> A given event port assigned to a new lcore other than
> it previous one then we need to do some clean up at port level.

 In my case I'm mapping an event port per thread statically (basically thread_id == port_id),
so this shouldn't be an issue.