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