-----Original Message-----

Date: Tue, 31 Jul 2018 08:09:05 +0000
From: "Elo, Matias (Nokia - FI/Espoo)" <redacted>
To: Jerin Jacob <redacted>
CC: "Van Haaren, Harry" <redacted>, "dev@dpdk.org"
 [off-list ref]
Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status
x-mailer: Apple Mail (2.3445.9.1)

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?

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

quoted

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?

If is used in fastpath, it will have function pointer overhead for other
drivers and southbound(driver) interface needs to add for holding one more function
pointer.

quoted

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.

If it is in fastpath, I prefer to have single API(if possible) and avoid
creating new API for driver specific usecases(again if possible to do so)