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

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

-----Original Message-----
> Date: Mon, 30 Jul 2018 06:39:45 +0000
> From: "Elo, Matias (Nokia - FI/Espoo)" <matias.elo@nokia.com>
> To: "dev@dpdk.org" <dev@dpdk.org>
> CC: "Van Haaren, Harry" <harry.van.haaren@intel.com>
> Subject: [dpdk-dev] eventdev: method for finding out unlink status
> x-mailer: Apple Mail (2.3445.9.1)
> 
> 
> Hi,
> 
> In bug report https://bugs.dpdk.org/show_bug.cgi?id=60 we have been discussing
> issues related to events ending up in wrong ports after calling
> rte_event_port_unlink(). In addition of finding few bugs we have identified a
> need for a new API call (or documentation extension) for an application to be

>From HW perspective, documentation extension should be enough. adding 
"there may be pre-scheduled events and the application is responsible to process them"
on unlink(). Since dequeue() has which queue it is dequeue-ed from, the
application can allays make action based on that(i.e, Is the event
post/pre to unlink)

> able to find out when an unlink() call has finished and no new events are
> scheduled anymore to the particular event port. This is required e.g. when doing
> clean-up after an application thread stops processing events.

If thread stopping then it better to call dev_stop(). At least in HW
implementation, A given event port assigned to a new lcore other than
it previous one then we need to do some clean up at port level.

> 
> The bug report discussion provides more background on the subject and Harry has
> already proposed a new 'int32_t rte_event_unlinks_in_progress()' API as one
> possible solution.

Assuming stale event(s) can go the new linked port,
Does rte_event_unlink() takes consider amount of time in SW implementation.


> 
> -Matias
>