DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: "Elo, Matias (Nokia - FI/Espoo)" <matias.elo@nokia.com>
Cc: "Van Haaren, Harry" <harry.van.haaren@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status
Date: Tue, 31 Jul 2018 14:01:08 +0530	[thread overview]
Message-ID: <20180731083107.GA23233@jerin> (raw)
In-Reply-To: <6D43DE84-583D-42E5-B298-0E7BDA0C17FB@nokia.com>

-----Original Message-----
> Date: Tue, 31 Jul 2018 08:09:05 +0000
> From: "Elo, Matias (Nokia - FI/Espoo)" <matias.elo@nokia.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> CC: "Van Haaren, Harry" <harry.van.haaren@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)
> 
> 
> >>>>
> >>>> 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)

> 

  reply	other threads:[~2018-07-31  8:31 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-30  6:39 Elo, Matias (Nokia - FI/Espoo)
2018-07-30  7:54 ` Jerin Jacob
2018-07-30  9:17   ` Elo, Matias (Nokia - FI/Espoo)
2018-07-30  9:29     ` Jerin Jacob
2018-07-30  9:38       ` Van Haaren, Harry
2018-07-30 10:28         ` Elo, Matias (Nokia - FI/Espoo)
2018-07-30 10:36         ` Jerin Jacob
2018-07-30 13:36           ` Elo, Matias (Nokia - FI/Espoo)
2018-07-30 14:26             ` Jerin Jacob
2018-07-31  8:09               ` Elo, Matias (Nokia - FI/Espoo)
2018-07-31  8:31                 ` Jerin Jacob [this message]
2018-07-31  9:27                   ` Elo, Matias (Nokia - FI/Espoo)
2018-08-08 10:05                     ` Elo, Matias (Nokia - FI/Espoo)
2018-08-09 13:14                       ` Van Haaren, Harry
2018-08-09 14:18                         ` Jerin Jacob
2018-08-10 14:24                           ` Elo, Matias (Nokia - FI/Espoo)
2018-08-10 14:52                             ` Jerin Jacob
2018-08-10 16:55                               ` Van Haaren, Harry
2018-08-10 17:35                                 ` Jerin Jacob
2018-09-05  7:49                                   ` Elo, Matias (Nokia - FI/Espoo)
2018-09-12 15:17                                     ` Van Haaren, Harry
2018-07-30 15:32           ` Liang, Ma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180731083107.GA23233@jerin \
    --to=jerin.jacob@caviumnetworks.com \
    --cc=dev@dpdk.org \
    --cc=harry.van.haaren@intel.com \
    --cc=matias.elo@nokia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).