Re: eventdev: method for finding out unlink status

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

>> 
>> I'm not sure I understand the issue here.
>> Is anybody suggesting to make unlink() blocking?
>> 
>> For certain PMDs, perhaps it must be a synchronous handled unlink().
>> For other PMDs (eg event/sw) there are multiple threads involved,
>> so it must be async. Hence, APIs should be async to avoid blocking the caller.
>> 
>> With an async API, if you don't want the async behaviuor, it is
>> easy to build the sync version: call it in a loop, optionally with a delay().
> 
> Correct. My point was, rte_event_port_unlink() can be blocking as it 
> is a slow path API(does not really matter how long it waits).
> If you think, it can be called in fastpath and/or application can
> leverage some cpu cycles on completing the async call then you can add
> at the cost of new API unlinks_in_progress() and make sure to update the documentation
> about unlink() that it can be async call(currently it is documented as a sync
> call).

Did you come to an agreement how to solve this issue? Any solution (e.g. make
rte_event_port_unlink() blocking with SW eventdev) would be welcomed since this
issue is currently blocking my work with eventdev.