> From: Elo, Matias (Nokia - FI/Espoo) [mailto:matias....@nokia.com] > Sent: Wednesday, September 5, 2018 8:49 AM > To: Van Haaren, Harry <harry.van.haa...@intel.com> > Cc: Jerin Jacob <jerin.ja...@caviumnetworks.com>; dev@dpdk.org > Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status > > > >> > >> 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.
I'll work on a patch and document async behavior as Jerin suggested. I think we may still need to drain the port after unlinks_in_progress() returns zero, as there may still be events in the port buffers until all unlinks are done. That would make the final application code-path as follows: /* control path core */ unlink(); while(unlinks_in_progress() > 0) { delay(); } /* we know there are no more events being scheduled to the port. Could flag to data-path core here that unlinks are acked */ while(dequeue_burst(events, ... ) > 0) { free_events(); } /* now we know there are no events in the port itself either. Application can perform whatever it wants with the data-path core */ The final dequeueing could also be handled in the data-path core, and only break out of its loop when the unlink-ack and zero packets returned from dequeue. I'll send a v1 patchset for your reviews - I think that might make things clearer. Thanks, -Harry