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