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

[Jerin Jacob]

-----Original Message-----
> Date: Mon, 30 Jul 2018 13:36:35 +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)
> 
> 
> >> For this "runtime scale down" use-case the missing information is being
> >> able to identify when an unlink is complete. After that (and ensuring the
> >> port buffer is empty) the application can be guaranteed that there are no
> >> more events going to be sent to that port, and the application can take
> >> the worker lcore out of its polling-loop and put it to sleep.
> >>
> >> As mentioned before, I think an "unlinks_in_progress()" function is perhaps
> >> the easiest way to achieve this functionality, as it allows relatively simple
> >> tracking of unlinks() using an atomic counter in sw. (Implementation details
> >> become complex when we have a separate core running event/sw, separate cores
> >> polling, and a control-plane thread calling unlink...)
> >>
> >> 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?

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?

Are we calling this API in fastpath? or it is control thread as
mentioned in harry's pseudo code.