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

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

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