-----Original Message-----

Date: Mon, 30 Jul 2018 09:17:47 +0000
From: "Elo, Matias (Nokia - FI/Espoo)" <redacted>
To: Jerin Jacob <redacted>
CC: "dev@dpdk.org" <redacted>, "Van Haaren, Harry"
 [off-list ref]
Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status
x-mailer: Apple Mail (2.3445.9.1)

quoted

quoted

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)

At least in case of SW eventdev the problem is how the application can know that
it has processed all pre-scheduled events. E.g. dequeue may return nothing but since
the scheduler is running as a separate process events may still end up to the unlinked
port asynchronously.

Can't we do, dequeue() in loop to get all the events from port. If
dequeue returns with zero event then ports are drained up. Right?

quoted

quoted

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,

For an application doing dynamic load balancing stopping the whole eventdev is not an
option.

OK. Makes sense. Doing unlink() and link() in fastpath is not a
problem. Changing core assignment to event port is problem without stop(). I guess, you
application or general would be OK with that constraint.

quoted

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.

 In my case I'm mapping an event port per thread statically (basically thread_id == port_id),
so this shouldn't be an issue.