-----Original Message----- > Date: Fri, 10 Aug 2018 16:55:31 +0000 > From: "Van Haaren, Harry" <harry.van.haa...@intel.com> > To: Jerin Jacob <jerin.ja...@caviumnetworks.com>, "Elo, Matias (Nokia - > FI/Espoo)" <matias....@nokia.com> > CC: "dev@dpdk.org" <dev@dpdk.org> > Subject: RE: [dpdk-dev] eventdev: method for finding out unlink status > > > > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] > > Sent: Friday, August 10, 2018 3:52 PM > > To: Elo, Matias (Nokia - FI/Espoo) <matias....@nokia.com> > > Cc: Van Haaren, Harry <harry.van.haa...@intel.com>; dev@dpdk.org > > 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)" <matias....@nokia.com> > > > To: Jerin Jacob <jerin.ja...@caviumnetworks.com> > > > CC: "Van Haaren, Harry" <harry.van.haa...@intel.com>, "dev@dpdk.org" > > > <dev@dpdk.org> > > > 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).
