From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
To: "Elo, Matias (Nokia - FI/Espoo)" <matias.elo@nokia.com>
Cc: Jerin Jacob <jerin.jacob@caviumnetworks.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status
Date: Wed, 12 Sep 2018 15:17:07 +0000 [thread overview]
Message-ID: <E923DB57A917B54B9182A2E928D00FA65E2C7D28@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <285D18AA-EC23-4C04-824A-726F20681C61@nokia.com>
> From: Elo, Matias (Nokia - FI/Espoo) [mailto:matias.elo@nokia.com]
> Sent: Wednesday, September 5, 2018 8:49 AM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>
> Cc: Jerin Jacob <jerin.jacob@caviumnetworks.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] eventdev: method for finding out unlink status
>
>
> >>
> >> I'm not sure I understand the issue here.
> >> Is anybody suggesting to make unlink() blocking?
> >>
> >> For certain PMDs, perhaps it must be a synchronous handled unlink().
> >> For other PMDs (eg event/sw) there are multiple threads involved,
> >> so it must be async. Hence, APIs should be async to avoid blocking the
> caller.
> >>
> >> With an async API, if you don't want the async behaviuor, it is
> >> easy to build the sync version: call it in a loop, optionally with a
> delay().
> >
> > Correct. My point was, rte_event_port_unlink() can be blocking as it
> > is a slow path API(does not really matter how long it waits).
> > If you think, it can be called in fastpath and/or application can
> > leverage some cpu cycles on completing the async call then you can add
> > at the cost of new API unlinks_in_progress() and make sure to update the
> documentation
> > about unlink() that it can be async call(currently it is documented as a
> sync
> > call).
>
> Did you come to an agreement how to solve this issue? Any solution (e.g.
> make
> rte_event_port_unlink() blocking with SW eventdev) would be welcomed since
> this
> issue is currently blocking my work with eventdev.
I'll work on a patch and document async behavior as Jerin suggested.
I think we may still need to drain the port after unlinks_in_progress() returns
zero, as there may still be events in the port buffers until all unlinks are done.
That would make the final application code-path as follows:
/* control path core */
unlink();
while(unlinks_in_progress() > 0) {
delay();
}
/* we know there are no more events being scheduled to the port.
Could flag to data-path core here that unlinks are acked */
while(dequeue_burst(events, ... ) > 0) {
free_events();
}
/* now we know there are no events in the port itself either.
Application can perform whatever it wants with the data-path core */
The final dequeueing could also be handled in the data-path core,
and only break out of its loop when the unlink-ack and zero packets returned from dequeue.
I'll send a v1 patchset for your reviews - I think that might make things clearer.
Thanks, -Harry
next prev parent reply other threads:[~2018-09-12 15:17 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)
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 [this message]
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=E923DB57A917B54B9182A2E928D00FA65E2C7D28@IRSMSX102.ger.corp.intel.com \
--to=harry.van.haaren@intel.com \
--cc=dev@dpdk.org \
--cc=jerin.jacob@caviumnetworks.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).