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

["Elo, Matias (Nokia - FI/Espoo)" <matias.elo@nokia.com>]

> I don't think that the eventdev API requires 1:1 Lcore / Port mapping, so really a
> PMD should be able to handle any thread calling any port.
> 
> The event/sw PMD allows any thread to call dequeue/enqueue any port,
> so long as it is not being accessed by another thread.
> 
> 
>>>> 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.
> 
> This is the common case - but I don't think we should demand it.
> There is a valid scale-down model which just polls *all* ports using
> a single lcore, instead of unlink() of multiple ports.

I agree, 1 : 1 Lcore / Port mapping shouldn't be required.


> I think the end result we're hoping for is something like pseudo code below,
> (keep in mind that the event/sw has a service-core thread running it, so no
> application code there):
> 
> int worker_poll = 1;
> 
> worker() {
>  while(worker_poll) {
>     // eventdev_dequeue_burst() etc
>  }
>  go_to_sleep(1);
> }
> 
> control_plane_scale_down() {
>  unlink(evdev, worker, queue_id);
>  while(unlinks_in_progress(evdev) > 0)
>      usleep(100);
> 
>  /* here we know that the unlink is complete.
>   * so we can now stop the worker from polling */
>  worker_poll = 0;
> }
> 
> Hope my pseudo-code makes pseudo-sense :)


Makes sense =)

One use case this API wouldn't support is if an application would
unlink only a subset of linked queues. In this case events could be still
arriving constantly after unlinks_in_progress() returns zero, so there is no way
for the application to know when all events from unlinked queues have been
processed. However, at least in our application this information is not needed.