DPDK patches and discussions
 help / color / mirror / Atom feed
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
Date: Fri, 10 Aug 2018 14:24:02 +0000	[thread overview]
Message-ID: <4C66F1B2-02F0-4F6E-A6CD-6A3F44CDAB42@nokia.com> (raw)
In-Reply-To: <20180809141814.GA15603@jerin>


> 
> # Other than that, I am still not able to understand, why not
> application wait until rte_event_port_unlink() returns.

Making rte_event_port_unlink() blocking would be troublesome if one doesn’t care
about unlink completion. E.g. doing dynamic load balancing.

> 
> # 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?

In our application this could be used for example to pause scheduling of new events while
working on an “expensive” event to minimise delays. It is also needed when destroying
queues, though calling this fast path is debatable (our application enables creating /
destroying queues at runtime).

These are perhaps not the best examples but I would be very cautious to make a function
blocking if there is even a small probability that it could be called from the fast path.


  reply	other threads:[~2018-08-10 14:24 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
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) [this message]
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=4C66F1B2-02F0-4F6E-A6CD-6A3F44CDAB42@nokia.com \
    --to=matias.elo@nokia.com \
    --cc=dev@dpdk.org \
    --cc=harry.van.haaren@intel.com \
    --cc=jerin.jacob@caviumnetworks.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).