quoted

quoted

quoted

quoted

quoted

quoted

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?

Based on return code?

Yes, that works. I was thinking about the complexity of the implementation as it would
have to also track the pending unlink requests. But anyway, Harry is better answering
these questions since I guess he would be implementing this.

Hi Harry,

Have you had time to think about this?