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: Tue, 31 Jul 2018 08:09:05 +0000 [thread overview]
Message-ID: <6D43DE84-583D-42E5-B298-0E7BDA0C17FB@nokia.com> (raw)
In-Reply-To: <20180730142614.GA11265@jerin>
>>>>
>>>> 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?
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?
>
> 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.
next prev parent reply other threads:[~2018-07-31 8:09 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) [this message]
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
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=6D43DE84-583D-42E5-B298-0E7BDA0C17FB@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).