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

Date: Thu, 9 Aug 2018 13:14:40 +0000
From: "Van Haaren, Harry" <redacted>
To: "Elo, Matias (Nokia - FI/Espoo)" <redacted>
CC: "dev@dpdk.org" <redacted>, Jerin Jacob
 [off-list ref]
Subject: RE: [dpdk-dev] eventdev: method for finding out unlink status

quoted

From: Elo, Matias (Nokia - FI/Espoo) [mailto:matias.elo@nokia.com]
Sent: Wednesday, August 8, 2018 11:05 AM
To: Van Haaren, Harry <redacted>
Cc: dev@dpdk.org; Jerin Jacob <redacted>
Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status

quoted

quoted

quoted

quoted

quoted

quoted

quoted

I think the end result we're hoping for is something like pseudo

code below,

quoted

quoted

quoted

quoted

quoted

quoted

quoted

(keep in mind that the event/sw has a service-core thread running

it, so no

quoted

quoted

quoted

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

quoted

quoted

quoted

time for deprecation notice.

Both solutions should work but I would perhaps favor Harry's approach

as it

quoted

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

to differentiate a delayed unlink completion from a scenario where the

port & queues

quoted

quoted

quoted

have never been linked?

Based on return code?

Yes, that works. I was thinking about the complexity of the implementation

as it would

quoted

have to also track the pending unlink requests. But anyway, Harry is

better answering

quoted

these questions since I guess he would be implementing this.

Hi Harry,

Have you had time to think about this?

Hey, Yes I'm just collecting my thoughts at the moment, I see a few small quirks;

1) I see the "return -EBUSY from port_unlink()" solution as overloading the rte_event_port_unlink() API.
We lose some self-documenting semantics of the code, see the following snippet @ 1) marker.

2) If some unlinks fail, and others are in progress, we cannot describe that in a single return.
See 2) marker in code below.


int ret = rte_event_port_unlink(dev, port, queues[], nb_queues);
while (ret == -EBUSY) {
   // 1) what args to pass here? It looks like we want to unlink again?

The same arguments.

   // 2) some unlinks fail, and others are -EBUSY: There is no appropriate ret code in that case
   ret = rte_event_port_unlink(...);

It is going to be boolean right? like
rte_event_port_unlink_in_progress(), So do we need additional return code to express partially completed?

}

I was thinking like this,
while (rte_event_port_unlink() == -EBUSY)
{
	rte_delay();
}

Contrast that to the following, which I feel is simpler and more descriptive:

int ret = rte_event_port_unlink(dev, port, queues[], nb_queues);

while (rte_event_port_unlink_in_progress(dev, port) > 0)
   rte_delay();


Here the port_unlink() call can sanity-check the unlinks, and return -EINVAL if invalid requests,
and we can detect other unlinks in progress too using the explicit API.

Regarding adding an API / function-pointer, is there actually a measurable cost there?
Are we willing to sacrifice code-readability and self-documentation?

I am fine either approach, at minimum, you can still return -EBUSY so
that loop look like this,

int ret = rte_event_port_unlink(dev, port, queues[], nb_queues);
while (ret == -EBUSY && rte_event_port_unlink_in_progress(dev, port) > 0)
	rte_delay();

So that, rte_event_port_unlink_in_progress() wont be called for other
drivers for normal cases.

# Other than that, I am still not able to understand, why not
application wait until rte_event_port_unlink() returns.

# What in real word use case, application can, do other than waiting
to complete rte_event_port_unlink(). If we try to put some logic in like,

while (rte_event_port_unlink_in_progress(dev, port) > 0){
	do_something();
}

The do_something() will not be called in some platform at all.

# Any idea on what will be the real world use case, where rte_event_port_unlink() called in fastpath?

-Harry