[dpdk-dev] eventdev: method for finding out unlink status
Elo, Matias (Nokia - FI/Espoo)
matias.elo at nokia.com
Mon Jul 30 11:17:47 CEST 2018
>>
>> 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.
More information about the dev
mailing list