[dpdk-dev] eventdev: method for finding out unlink status

[Jerin Jacob]

-----Original Message-----
> Date: Tue, 31 Jul 2018 08:09:05 +0000
> From: "Elo, Matias (Nokia - FI/Espoo)" <matias.elo at nokia.com>
> To: Jerin Jacob <jerin.jacob at caviumnetworks.com>
> CC: "Van Haaren, Harry" <harry.van.haaren at intel.com>, "dev at dpdk.org"
>  <dev at dpdk.org>
> Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status
> x-mailer: Apple Mail (2.3445.9.1)
> 
> 
> >>>>
> >>>> 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.
> 
> >
> > 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.

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

>