-----Original Message----- > Date: Fri, 10 Aug 2018 16:55:31 +0000 > From: "Van Haaren, Harry" <[email protected]> > To: Jerin Jacob <[email protected]>, "Elo, Matias (Nokia - > FI/Espoo)" <[email protected]> > CC: "[email protected]" <[email protected]> > Subject: RE: [dpdk-dev] eventdev: method for finding out unlink status > > > > From: Jerin Jacob [mailto:[email protected]] > > Sent: Friday, August 10, 2018 3:52 PM > > To: Elo, Matias (Nokia - FI/Espoo) <[email protected]> > > Cc: Van Haaren, Harry <[email protected]>; [email protected] > > Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status > > > > -----Original Message----- > > > Date: Fri, 10 Aug 2018 14:24:02 +0000 > > > From: "Elo, Matias (Nokia - FI/Espoo)" <[email protected]> > > > To: Jerin Jacob <[email protected]> > > > CC: "Van Haaren, Harry" <[email protected]>, "[email protected]" > > > <[email protected]> > > > Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status > > > x-mailer: Apple Mail (2.3445.9.1) > > > > > > > > > > > > > > # Other than that, I am still not able to understand, why not > > > > application wait until rte_event_port_unlink() returns. > > > > > > Making rte_event_port_unlink() blocking would be troublesome if one > > doesn’t care > > > about unlink completion. E.g. doing dynamic load balancing. > > > > By making it as blocking(i.e the rte_event_port_unlink() returns when > > unlink() completed) forcing everyone to care about unlink completion. > > Right? > > 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).
