quoted

For this "runtime scale down" use-case the missing information is being
able to identify when an unlink is complete. After that (and ensuring the
port buffer is empty) the application can be guaranteed that there are no
more events going to be sent to that port, and the application can take
the worker lcore out of its polling-loop and put it to sleep.

As mentioned before, I think an "unlinks_in_progress()" function is perhaps
the easiest way to achieve this functionality, as it allows relatively simple
tracking of unlinks() using an atomic counter in sw. (Implementation details
become complex when we have a separate core running event/sw, separate cores
polling, and a control-plane thread calling unlink...)

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;
}

Make sense. Instead of rte_event_is_unlink_in_progress(), How about
adding a callback in rte_event_port_unlink() which will be called on 
unlink completion. It will reduce the need for ONE more API.

Anyway it RC2 now, so we can not accept a new feature. So we will have
time for deprecation notice.

Both solutions should work but I would perhaps favor Harry's approach as it
requires less code in the application side and doesn't break backward
compatibility.