From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>,
"thomas@monjalon.net" <thomas@monjalon.net>,
Feifei Wang <Feifei.Wang2@arm.com>,
"david.marchand@redhat.com" <david.marchand@redhat.com>
Cc: "hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
"Nipun.gupta@nxp.com" <nipun.gupta@nxp.com>,
"jerinj@marvell.com" <jerinj@marvell.com>,
"Van Haaren, Harry" <harry.van.haaren@intel.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"dmitry.kozliuk@gmail.com" <dmitry.kozliuk@gmail.com>,
"navasile@linux.microsoft.com" <navasile@linux.microsoft.com>,
"dmitrym@microsoft.com" <dmitrym@microsoft.com>,
"Kadam, Pallavi" <pallavi.kadam@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
Ruifeng Wang <Ruifeng.Wang@arm.com>, nd <nd@arm.com>,
nd <nd@arm.com>
Subject: Re: [dpdk-dev] [RFC 3/5] eal: lcore state FINISHED is not required
Date: Fri, 19 Mar 2021 13:42:39 +0000 [thread overview]
Message-ID: <DM6PR11MB44915ED78F825EEAFD033A589A689@DM6PR11MB4491.namprd11.prod.outlook.com> (raw)
In-Reply-To: <DBAPR08MB5814699797B12F9D8DB570F798999@DBAPR08MB5814.eurprd08.prod.outlook.com>
Hi everyone,
> <snip>
>
> > >
> > > > > Subject: [RFC 3/5] eal: lcore state FINISHED is not required
> > > > >
> > > > > FINISHED state seems to be used to indicate that the worker's
> > > > > update of the 'state' is not visible to other threads. There seems
> > > > > to be no requirement to have such a state.
> > > >
> > > > I am not sure "FINISHED" is necessary to be removed, and I propose
> > > > some of my profiles for discussion.
> > > > There are three states for lcore now:
> > > > "WAIT": indicate lcore can start working
> > > > "RUNNING": indicate lcore is working
> > > > "FINISHED": indicate lcore has finished its working and wait to be
> > > > reset
> > > If you look at the definitions of "WAIT" and "FINISHED" states, they look
> > similar, except for "wait to be reset" in "FINISHED" state . The code really does
> > not do anything to reset the lcore. It just changes the state to "WAIT".
I agree that 3 states here seems excessive.
Just 2 (RUNNING/IDLE) seems enough.
Though we can't just remove FINISHED here - it will be an Abi breakage.
Might be deprecate FINISHED now and remove in 21.11.
Also need to decide what rte_eal_wait_lcore() should return in that case?
Always zero, or always status of last function called?
> > >
> > > >
> > > > From the description above, we can find "FINISHED" is different from
> > > > "WAIT", it can shows that lcore has done the work and finished it.
> > > > Thus, if we remove "FINISHED", maybe we will not know whether the
> > > > lcore finishes its work or just doesn't start, because this two state has the
> > same tag "WAIT".
> > > Looking at "eal_thread_loop", the worker thread sets the state to "RUNNING"
> > before sending the ack back to main core. After that it is guaranteed that the
> > worker will run the assigned function. Only case where it will not run the
> > assigned function is when the 'write' syscall fails, in which case it results in a
> > panic.
> >
> > Quick note: it should not panic.
> > We must find a way to return an error
> > without crashing the whole application.
> The syscalls are being used to communicate the status back to the main thread. If they fail, it is not possible to communicate the status.
> May be it is better to panic.
> We could change the implementation using shared variables, but it would require polling the memory. May be the syscalls are being used to
> avoid polling. However, this polling would happen during init time (or similar) for a short duration.
AFAIK we use read and write not for status communication, but sort of sleep/ack point.
Though I agree if we can't do read/write from the system pipe then something is totally wrong,
and probably there is no much point to continue.
> >
> >
> > > > Furthermore, consider such a scenario:
> > > > Core 1 need to monitor Core 2 state, if Core 2 finishes one task,
> > > > Core 1 can start its working.
> > > > However, if there is only one tag "WAIT", Core 1 maybe start its
> > > > work at the wrong time, when Core 2 still does not start its task at state
> > "WAIT".
> > > > This is just my guess, and at present, there is no similar
> > > > application scenario in dpdk.
> > > To be able to do this effectively, core 1 needs to observe the state change
> > from WAIT->RUNNING->FINISHED. This requires that core 1 should be calling
> > rte_eal_remote_launch and rte_eal_wait_lcore functions. It is not possible to
> > observe this state transition from a 3rd core (for ex: a worker might go from
> > RUNNING->FINISHED->WAIT->RUNNING which a 3rd core might not be able to
> > observe).
> > >
> > > >
> > > > On the other hand, if we decide to remove "FINISHED", please
> > > > consider the following files:
> > > > 1. lib/librte_eal/linux/eal_thread.c: line 31
> > > > lib/librte_eal/windows/eal_thread.c: line 22
> > > > lib/librte_eal/freebsd/eal_thread.c: line 31
> > > I have looked at these lines, they do not capture "why" FINISHED state is
> > required.
> > >
> > > 2.
> > > > lib/librte_eal/include/rte_launch.h: line 24, 44, 121, 123, 131 3.
> > > > examples/l2fwd-
> > > > keepalive/main.c: line 510
> > > > rte_eal_wait_lcore(id_core) can be removed. Because the core state
> > > > has been checked as "WAIT", this is a redundant operation
> >
> >
next prev parent reply other threads:[~2021-03-19 13:44 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-24 21:20 [dpdk-dev] [RFC 0/5] Use correct memory ordering in eal functions Honnappa Nagarahalli
2021-02-24 21:20 ` [dpdk-dev] [RFC 1/5] eal: reset lcore function pointer and argument Honnappa Nagarahalli
2021-02-24 21:20 ` [dpdk-dev] [RFC 2/5] eal: ensure memory operations are visible to worker Honnappa Nagarahalli
2021-02-24 21:20 ` [dpdk-dev] [RFC 3/5] eal: lcore state FINISHED is not required Honnappa Nagarahalli
[not found] ` <AM5PR0802MB2465B62994239817E0AC46C59E9E9@AM5PR0802MB2465.eurprd08.prod.outlook.com>
2021-02-25 8:44 ` [dpdk-dev] 回复: " Feifei Wang
2021-02-25 23:33 ` [dpdk-dev] " Honnappa Nagarahalli
2021-02-26 8:26 ` Thomas Monjalon
2021-03-02 3:13 ` Honnappa Nagarahalli
2021-03-19 13:42 ` Ananyev, Konstantin [this message]
2021-03-30 2:54 ` Honnappa Nagarahalli
2021-03-01 5:55 ` [dpdk-dev] 回复: " Feifei Wang
2021-02-24 21:20 ` [dpdk-dev] [RFC 4/5] eal: ensure memory operations are visible to main Honnappa Nagarahalli
2021-02-24 21:20 ` [dpdk-dev] [RFC 5/5] test/ring: use relaxed barriers for ring stress test Honnappa Nagarahalli
2021-03-01 16:41 ` [dpdk-dev] [RFC 0/5] Use correct memory ordering in eal functions Stephen Hemminger
2021-03-02 16:06 ` Honnappa Nagarahalli
2021-09-09 23:13 ` [dpdk-dev] [PATCH v2 0/6] " Honnappa Nagarahalli
2021-09-09 23:13 ` [dpdk-dev] [PATCH v2 1/6] eal: reset lcore function pointer and argument Honnappa Nagarahalli
2021-09-10 7:49 ` Bruce Richardson
2021-09-10 8:12 ` David Marchand
2021-09-11 22:19 ` Honnappa Nagarahalli
2021-09-09 23:13 ` [dpdk-dev] [PATCH v2 2/6] eal: ensure memory operations are visible to worker Honnappa Nagarahalli
2021-09-09 23:13 ` [dpdk-dev] [PATCH v2 3/6] eal: lcore state FINISHED is not required Honnappa Nagarahalli
2021-09-09 23:13 ` [dpdk-dev] [PATCH v2 4/6] eal: update rte_eal_wait_lcore definition Honnappa Nagarahalli
2021-09-09 23:37 ` Honnappa Nagarahalli
2021-09-09 23:13 ` [dpdk-dev] [PATCH v2 5/6] eal: ensure memory operations are visible to main Honnappa Nagarahalli
2021-09-09 23:13 ` [dpdk-dev] [PATCH v2 6/6] test/ring: use relaxed barriers for ring stress test Honnappa Nagarahalli
2021-10-07 11:55 ` Ananyev, Konstantin
2021-10-07 23:40 ` Honnappa Nagarahalli
2021-10-25 4:52 ` [dpdk-dev] [PATCH v3 0/4] Use correct memory ordering in eal functions Honnappa Nagarahalli
2021-10-25 4:52 ` [dpdk-dev] [PATCH v3 1/4] eal: reset lcore function pointer and argument Honnappa Nagarahalli
2021-10-25 4:52 ` [dpdk-dev] [PATCH v3 2/4] eal: lcore state FINISHED is not required Honnappa Nagarahalli
2021-10-25 4:52 ` [dpdk-dev] [PATCH v3 3/4] eal: use correct memory ordering Honnappa Nagarahalli
2021-10-25 4:52 ` [dpdk-dev] [PATCH v3 4/4] test/ring: use relaxed barriers for ring stress test Honnappa Nagarahalli
2021-10-25 16:23 ` [dpdk-dev] [PATCH v3 0/4] Use correct memory ordering in eal functions David Marchand
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=DM6PR11MB44915ED78F825EEAFD033A589A689@DM6PR11MB4491.namprd11.prod.outlook.com \
--to=konstantin.ananyev@intel.com \
--cc=Feifei.Wang2@arm.com \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=Ruifeng.Wang@arm.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=dmitry.kozliuk@gmail.com \
--cc=dmitrym@microsoft.com \
--cc=harry.van.haaren@intel.com \
--cc=hemant.agrawal@nxp.com \
--cc=jerinj@marvell.com \
--cc=navasile@linux.microsoft.com \
--cc=nd@arm.com \
--cc=nipun.gupta@nxp.com \
--cc=pallavi.kadam@intel.com \
--cc=thomas@monjalon.net \
/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).