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