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