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

[Elo, Matias (Nokia - FI/Espoo)]

>>>> 
>>>> 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.
> 
> OK.
> 
> Does rte_event_port_unlink() returning -EBUSY will help?

It could perhaps work. The return value becomes a bit ambiguous though. E.g. how
to differentiate a delayed unlink completion from a scenario where the port & queues
have never been linked?

The implementation may also be more complex compared to a separate function but
Harry is a better person to answer this.

> 
> while (rte_event_port_unlink() != nr_links)
> 	usleep(100);
> 
> I am trying to think, how can address this requirements without creating new API and/or less impact to other
> drivers which don't have this requirements?

Wouldn't this function then just be NOP for the other drivers?

> 
> Are we calling this API in fastpath? or it is control thread as
> mentioned in harry's pseudo code.

In our use case it could be called also directly from the fast path by the worker thread.