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

[Jerin Jacob]

-----Original Message-----
> Date: Mon, 30 Jul 2018 09:17:47 +0000
> From: "Elo, Matias (Nokia - FI/Espoo)" <matias.elo at nokia.com>
> To: Jerin Jacob <jerin.jacob at caviumnetworks.com>
> CC: "dev at dpdk.org" <dev at dpdk.org>, "Van Haaren, Harry"
>  <harry.van.haaren at intel.com>
> Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status
> x-mailer: Apple Mail (2.3445.9.1)
> 
> 
> >>
> >> 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?

> 
> >
> >> 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.

> 
> > 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.
> 
>