[dpdk-dev] eventdev: method for finding out unlink status

[Jerin Jacob]

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