-----Original Message-----
> Date: Mon, 30 Jul 2018 13:36:35 +0000
> From: "Elo, Matias (Nokia - FI/Espoo)" <matias....@nokia.com>
> To: Jerin Jacob <jerin.ja...@caviumnetworks.com>
> CC: "Van Haaren, Harry" <harry.van.haa...@intel.com>, "dev@dpdk.org"
> <dev@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.
