Re: eventdev: method for finding out unlink status

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

-----Original Message-----
> Date: Thu, 9 Aug 2018 13:14:40 +0000
> From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
> To: "Elo, Matias (Nokia - FI/Espoo)" <matias.elo@nokia.com>
> CC: "dev@dpdk.org" <dev@dpdk.org>, Jerin Jacob
>  <jerin.jacob@caviumnetworks.com>
> Subject: RE: [dpdk-dev] eventdev: method for finding out unlink status
> 
> > From: Elo, Matias (Nokia - FI/Espoo) [mailto:matias.elo@nokia.com]
> > Sent: Wednesday, August 8, 2018 11:05 AM
> > To: Van Haaren, Harry <harry.van.haaren@intel.com>
> > Cc: dev@dpdk.org; Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status
> >
> >
> > >>>>>>>
> > >>>>>>> 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?
> 
> 
> 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