From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>,
David Marchand <david.marchand@redhat.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"jerinjacobk@gmail.com" <jerinjacobk@gmail.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"mdr@ashroe.eu" <mdr@ashroe.eu>,
"ktraynor@redhat.com" <ktraynor@redhat.com>,
"Stokes, Ian" <ian.stokes@intel.com>,
"i.maximets@ovn.org" <i.maximets@ovn.org>,
"Mcnamara, John" <john.mcnamara@intel.com>,
"Kovacevic, Marko" <marko.kovacevic@intel.com>,
"Burakov, Anatoly" <anatoly.burakov@intel.com>,
Olivier Matz <olivier.matz@6wind.com>,
"Andrew Rybchenko" <arybchenko@solarflare.com>,
Neil Horman <nhorman@tuxdriver.com>
Subject: Re: [dpdk-dev] [PATCH v3 6/9] eal: register non-EAL threads as lcores
Date: Tue, 30 Jun 2020 18:57:15 +0000 [thread overview]
Message-ID: <BYAPR11MB3301435E5F0E50FBAA0E3C269A6F0@BYAPR11MB3301.namprd11.prod.outlook.com> (raw)
In-Reply-To: <2881429.9YLJUJncU7@thomas>
> 30/06/2020 14:07, Ananyev, Konstantin:
> > > 26/06/2020 16:43, David Marchand:
> > > > On Wed, Jun 24, 2020 at 1:59 PM Ananyev, Konstantin
> > > > <konstantin.ananyev@intel.com> wrote:
> > > > > > > Do you mean - make this new dynamic-lcore API return an error if callied
> > > > > > > from secondary process?
> > > > > >
> > > > > > Yes, and prohibiting from attaching a secondary process if dynamic
> > > > > > lcore API has been used in primary.
> > > > > > I intend to squash in patch 6:
> > > > > > https://github.com/david-marchand/dpdk/commit/e5861ee734bfe2e4dc23d9b919b0db2a32a58aee
> > > > >
> > > > > But secondary process can attach before lcore_register, so we'll have some sort of inconsistency in behaviour.
> > > >
> > > > If the developer tries to use both features, he gets an ERROR log in
> > > > the two init path.
> > > > So whatever the order at runtime, we inform the developer (who did not
> > > > read/understand the rte_thread_register() documentation) that what he
> > > > is doing is unsupported.
> > >
> > > I agree.
> > > Before this patch, pinning a thread on a random core can
> > > trigger some issues.
> > > After this patch, register an external thread will
> > > take care of logging errors in case of inconsistencies.
> > > So the user will know he is doing something not supported
> > > by the app.
> >
> > I understand that, and return a meaningful error is definitely
> > better the silent crash or memory corruption.
> > The problem with that approach, as I said before, MP group
> > behaviour becomes non-deterministic.
>
> It was already non-deterministic before these patches.
> > > It is an nice improvement.
> > >
> > > > > If we really want to go ahead with such workaround -
> > >
> > > It is not a workaround.
> > > It is fixing some old issues and making clear what is really impossible.
> >
> > The root cause of the problem is in our MP model design decisions:
> > from one side we treat lcore_id as process local data, from other side
> > in some shared data-structures we use lcore_id as an index.
> > I think to fix it properly we need either:
> > make lcore_id data shared or stop using lcore_id as an index for shared data.
> > So from my perspective this approach is just one of possible workarounds.
> > BTW, there is nothing wrong to have a workaround for the problem
> > we are not ready to fix right now.
>
> I think you are trying to fix multi-process handling.
> This patch is not about multi-process, it only highlight incompatibilities.
Yes, the problem has been there for a while.
David's patch just made it more visible.
We discussing different workarounds for the problem.
> > > > > probably better to introduce explicit EAL flag ( --single-process or so).
> > > > > As Thomas and Bruce suggested, if I understood them properly.
> > >
> > > No I was thinking to maintain the tri-state information:
> > > - secondary is possible
> > > - secondary is attached
> > > - secondary is forbidden
> >
> > Ok, then I misunderstood you.
> >
> > > Asking the user to use an option to forbid attaching a secondary process
> > > is the same as telling him it is forbidden.
> >
> > I don't think it is the same.
> > On a live and complex system user can't always predict will the primary proc
> > use dynamic lcore and if it will at what particular moment.
> > Same for secondary process launching - user might never start it,
> > might start it straight after the primary one,
> > or might be after several hours.
>
> I don't see the difference.
> An app which register external threads is not compatible
> with multi-process. It needs to be clear.
> If the user tries to do it anyway, there can be some error, OK.
Copying from other mail thread:
Imagine the situation - there is a primary proc (supposed to run forever)
that does rte_thread_register/rte_thread_unregister during its lifetime.
Plus from time to time user runs some secondary process to collect stats/debug
the primary one (proc-info or so).
Now behaviour of such system will be non-deterministic:
In some runs primary proc will do rte_thread_register() first,
and then secondary proc will be never able to attach.
In other cases - secondary will win the race, and then for primary
eal_lcore_non_eal_allocate() will always fail.
Which means different behaviour between runs, varying performance, etc.
> > > The error log is enough in my opinion.
> >
> > I think it is better than nothing, but probably not the best one.
> > Apart from possible non-consistent behaviour, it is quite restrictive:
> > dynamic lcore_id wouldn't be available on any DPDK MP deployment.
> > Which is a pity - I think it is a cool and useful feature.
>
> So you are asking to extend the feature.
I am asking for solution that would guarantee deterministic behaviour to the user.
If dynamic lcores and MP support need to be mutually exclusive,
then there should be a clean way for the user to *always* enable
one and disable the other.
"--proc-type=standalone" will at least guarantee such consistent behaviour between runs:
secondary proc will always fail to attach and eal_lcore_non_eal_allocate() will always succeed
(as long as there are free lcore_ids off-course).
Though I think even better would be not to make them mutually exclusive,
but instead let user to split lcore_id space accordingly.
Let me list the options currently under discussion:
a) New EAL parameter '--lcore-allow=...'
Explicit EAL parameter to enable dyn-lcore=Y
Consistent behaviour between runs=Y
DYN-lcores/MP-support are mutually exclusive=N
b) Extend '--proc-type' EAL parameter with new 'standalone' type
Explicit EAL parameter to enable dyn-lcore =Y
Consistent behaviour between runs=Y
Dyn lcores/MP-support are mutually exclusive=Y
c) dynamic allow/forbid dynamic-lcore/MP support
Explicit EAL parameter=N
Consistent behaviour between runs=N
Dyn lcores/MP-support are mutually exclusive=Y
My preference list (from top to bottom): a, b, c.
> Honestly, I'm not a fan of multi-process,
> so I would not push any feature for it.
Me too, but as we can't drop it, we probably have no
choice but to live with it.
>
> If we don't add any new option now, and restrict MP handling
> to error messages, it would not prevent from extending
> in future, right?
It shouldn't I think.
Though what is the urgency to push this feature without having an
agreement first?
>
> > What do you guys think about different approach:
> > introduce new optional EAL parameter to restrict lcore_id
> > values available for the process.
> >
> > #let say to start primary proc that can use lcore_id=[0-99] only:
> > dpdk_primary --lcore-allow=0-99 ... --file-prefix=xz1
> >
> > #to start secondary one for it with allowed lcore_id=[100-109]:
> > dpdk_secondary --lcore-allow=100-109 ... --file-prefix=xz1 --proc-type=secondary
> >
> > It is still a workaround, but that way we don't need to
> > add any new limitations for dynamic lcores and secondary process usage.
> > Now it is up to user to decide would multiple-process use the same shared data
> > and if so - split lcore_id space properly among them
> > (same as he has to do now with static lcores).
>
> Isn't it pushing too much to the user?
User has to do the similar thing with static lcores right now.
>
> > > > A EAL flag is a stable API from the start, as there is nothing
> > > > describing how we can remove one.
> > > > So a new EAL flag for an experimental API/feature seems contradictory.
> > > >
> > > > Going with a new features status API... I think it is beyond this series.
> > > >
> > > > Thomas seems to suggest an automatic resolution when features conflict
> > > > happens.. ?
> > >
> > > I suggest allowing the maximum and raise an error when usage conflicts.
> > > It seems this is what you did in v4.
> > >
> > > > I'll send the v4, let's discuss it there if you want.
>
>
next prev parent reply other threads:[~2020-06-30 18:57 UTC|newest]
Thread overview: 133+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-10 14:44 [dpdk-dev] [PATCH 0/7] Register external threads as lcore David Marchand
2020-06-10 14:45 ` [dpdk-dev] [PATCH 1/7] eal: relocate per thread symbols to common David Marchand
2020-06-10 14:45 ` [dpdk-dev] [PATCH 2/7] eal: fix multiple definition of per lcore thread id David Marchand
2020-06-15 6:46 ` Kinsella, Ray
2020-06-10 14:45 ` [dpdk-dev] [PATCH 3/7] eal: introduce thread init helper David Marchand
2020-06-10 14:45 ` [dpdk-dev] [PATCH 4/7] eal: introduce thread uninit helper David Marchand
2020-06-10 14:45 ` [dpdk-dev] [PATCH 5/7] eal: register non-EAL threads as lcore David Marchand
2020-06-15 6:43 ` Kinsella, Ray
2020-06-10 14:45 ` [dpdk-dev] [PATCH 6/7] eal: dump lcores David Marchand
2020-06-15 6:40 ` Kinsella, Ray
2020-06-10 14:45 ` [dpdk-dev] [PATCH 7/7] eal: add lcore hotplug notifications David Marchand
2020-06-15 6:34 ` Kinsella, Ray
2020-06-15 7:13 ` David Marchand
2020-06-10 15:09 ` [dpdk-dev] [PATCH 0/7] Register external threads as lcore Jerin Jacob
2020-06-10 15:13 ` Bruce Richardson
2020-06-10 15:18 ` David Marchand
2020-06-10 15:33 ` Jerin Jacob
2020-06-15 7:11 ` David Marchand
2020-06-19 16:22 ` [dpdk-dev] [PATCH v2 0/9] Register non-EAL " David Marchand
2020-06-19 16:22 ` [dpdk-dev] [PATCH v2 1/9] eal: relocate per thread symbols to common David Marchand
2020-06-19 16:22 ` [dpdk-dev] [PATCH v2 2/9] eal: fix multiple definition of per lcore thread id David Marchand
2020-06-19 16:22 ` [dpdk-dev] [PATCH v2 3/9] eal: introduce thread init helper David Marchand
2020-06-19 16:22 ` [dpdk-dev] [PATCH v2 4/9] eal: introduce thread uninit helper David Marchand
2020-06-19 16:22 ` [dpdk-dev] [PATCH v2 5/9] eal: move lcore role code David Marchand
2020-06-19 16:22 ` [dpdk-dev] [PATCH v2 6/9] eal: register non-EAL threads as lcores David Marchand
2020-06-19 16:22 ` [dpdk-dev] [PATCH v2 7/9] eal: add lcore init callbacks David Marchand
2020-06-19 16:22 ` [dpdk-dev] [PATCH v2 8/9] eal: add lcore iterators David Marchand
2020-06-20 2:21 ` Stephen Hemminger
2020-06-19 16:22 ` [dpdk-dev] [PATCH v2 9/9] mempool/bucket: handle non-EAL lcores David Marchand
2020-06-22 13:25 ` [dpdk-dev] [PATCH v3 0/9] Register non-EAL threads as lcore David Marchand
2020-06-22 13:25 ` [dpdk-dev] [PATCH v3 1/9] eal: relocate per thread symbols to common David Marchand
2020-06-22 13:25 ` [dpdk-dev] [PATCH v3 2/9] eal: fix multiple definition of per lcore thread id David Marchand
2020-06-22 13:25 ` [dpdk-dev] [PATCH v3 3/9] eal: introduce thread init helper David Marchand
2020-06-22 13:25 ` [dpdk-dev] [PATCH v3 4/9] eal: introduce thread uninit helper David Marchand
2020-06-22 13:25 ` [dpdk-dev] [PATCH v3 5/9] eal: move lcore role code David Marchand
2020-06-22 13:25 ` [dpdk-dev] [PATCH v3 6/9] eal: register non-EAL threads as lcores David Marchand
2020-06-22 15:49 ` Ananyev, Konstantin
2020-06-22 16:37 ` Ananyev, Konstantin
2020-06-23 7:49 ` David Marchand
2020-06-23 9:14 ` Bruce Richardson
2020-06-23 12:49 ` David Marchand
2020-06-23 13:15 ` Ananyev, Konstantin
2020-06-24 9:23 ` David Marchand
2020-06-24 9:56 ` Bruce Richardson
2020-06-24 10:08 ` Thomas Monjalon
2020-06-24 10:45 ` Ananyev, Konstantin
2020-06-24 10:39 ` Ananyev, Konstantin
2020-06-24 10:48 ` David Marchand
2020-06-24 11:59 ` Ananyev, Konstantin
2020-06-26 14:43 ` David Marchand
2020-06-30 10:35 ` Thomas Monjalon
2020-06-30 12:07 ` Ananyev, Konstantin
2020-06-30 12:44 ` Olivier Matz
2020-06-30 14:37 ` Thomas Monjalon
2020-06-30 19:02 ` Ananyev, Konstantin
2020-06-30 14:35 ` Thomas Monjalon
2020-06-30 18:57 ` Ananyev, Konstantin [this message]
2020-07-01 7:48 ` David Marchand
2020-07-01 11:58 ` Ananyev, Konstantin
2020-07-02 13:06 ` David Marchand
2020-07-03 15:15 ` Thomas Monjalon
2020-07-03 16:40 ` Ananyev, Konstantin
2020-07-04 15:00 ` David Marchand
2020-07-04 21:24 ` Ananyev, Konstantin
2020-06-23 17:02 ` Andrew Rybchenko
2020-06-22 13:25 ` [dpdk-dev] [PATCH v3 7/9] eal: add lcore init callbacks David Marchand
2020-06-22 13:25 ` [dpdk-dev] [PATCH v3 8/9] eal: add lcore iterators David Marchand
2020-06-22 13:25 ` [dpdk-dev] [PATCH v3 9/9] mempool/bucket: handle non-EAL lcores David Marchand
2020-06-23 17:28 ` Andrew Rybchenko
2020-06-26 14:13 ` David Marchand
2020-06-26 14:34 ` Andrew Rybchenko
2020-06-26 14:47 ` [dpdk-dev] [PATCH v4 0/9] Register non-EAL threads as lcore David Marchand
2020-06-26 14:47 ` [dpdk-dev] [PATCH v4 1/9] eal: relocate per thread symbols to common David Marchand
2020-06-30 9:33 ` Olivier Matz
2020-06-26 14:47 ` [dpdk-dev] [PATCH v4 2/9] eal: fix multiple definition of per lcore thread id David Marchand
2020-06-30 9:34 ` Olivier Matz
2020-06-26 14:47 ` [dpdk-dev] [PATCH v4 3/9] eal: introduce thread init helper David Marchand
2020-06-30 9:37 ` Olivier Matz
2020-06-30 12:04 ` David Marchand
2020-06-26 14:47 ` [dpdk-dev] [PATCH v4 4/9] eal: introduce thread uninit helper David Marchand
2020-06-26 15:00 ` Jerin Jacob
2020-06-29 9:07 ` David Marchand
2020-06-29 8:59 ` [dpdk-dev] [EXT] " Sunil Kumar Kori
2020-06-29 9:25 ` David Marchand
2020-06-30 9:42 ` [dpdk-dev] " Olivier Matz
2020-07-01 8:00 ` David Marchand
2020-06-26 14:47 ` [dpdk-dev] [PATCH v4 5/9] eal: move lcore role code David Marchand
2020-06-30 9:45 ` Olivier Matz
2020-06-26 14:47 ` [dpdk-dev] [PATCH v4 6/9] eal: register non-EAL threads as lcores David Marchand
2020-06-29 14:27 ` Ananyev, Konstantin
2020-06-30 10:07 ` Olivier Matz
2020-07-01 7:13 ` David Marchand
2020-07-01 9:11 ` Olivier Matz
2020-06-26 14:47 ` [dpdk-dev] [PATCH v4 7/9] eal: add lcore init callbacks David Marchand
2020-06-29 12:46 ` Ananyev, Konstantin
2020-06-30 10:09 ` Olivier Matz
2020-06-30 10:15 ` Olivier Matz
2020-06-26 14:47 ` [dpdk-dev] [PATCH v4 8/9] eal: add lcore iterators David Marchand
2020-06-30 10:11 ` Olivier Matz
2020-06-26 14:47 ` [dpdk-dev] [PATCH v4 9/9] mempool/bucket: handle non-EAL lcores David Marchand
2020-06-26 14:52 ` Andrew Rybchenko
2020-07-06 14:15 ` [dpdk-dev] [PATCH v5 00/10] Register non-EAL threads as lcore David Marchand
2020-07-06 14:15 ` [dpdk-dev] [PATCH v5 01/10] eal: relocate per thread symbols to common David Marchand
2020-07-06 14:15 ` [dpdk-dev] [PATCH v5 02/10] eal: fix multiple definition of per lcore thread id David Marchand
2020-07-06 14:15 ` [dpdk-dev] [PATCH v5 03/10] eal: introduce thread init helper David Marchand
2020-07-06 14:16 ` [dpdk-dev] [PATCH v5 04/10] eal: introduce thread uninit helper David Marchand
2020-07-06 14:16 ` [dpdk-dev] [PATCH v5 05/10] eal: move lcore role code David Marchand
2020-07-06 14:16 ` [dpdk-dev] [PATCH v5 06/10] eal: register non-EAL threads as lcores David Marchand
2020-07-06 14:16 ` [dpdk-dev] [PATCH v5 07/10] eal: add lcore init callbacks David Marchand
2020-07-06 14:16 ` [dpdk-dev] [PATCH v5 08/10] eal: add lcore iterators David Marchand
2020-07-06 14:16 ` [dpdk-dev] [PATCH v5 09/10] mempool/bucket: handle non-EAL lcores David Marchand
2020-07-06 14:16 ` [dpdk-dev] [PATCH v5 10/10] eal: add multiprocess disable API David Marchand
2020-07-06 20:52 ` [dpdk-dev] [PATCH v6 00/10] Register non-EAL threads as lcore David Marchand
2020-07-06 20:52 ` [dpdk-dev] [PATCH v6 01/10] eal: relocate per thread symbols to common David Marchand
2020-07-06 20:52 ` [dpdk-dev] [PATCH v6 02/10] eal: fix multiple definition of per lcore thread id David Marchand
2020-07-06 20:52 ` [dpdk-dev] [PATCH v6 03/10] eal: introduce thread init helper David Marchand
2020-07-06 20:52 ` [dpdk-dev] [PATCH v6 04/10] eal: introduce thread uninit helper David Marchand
2020-07-06 20:52 ` [dpdk-dev] [PATCH v6 05/10] eal: move lcore role code David Marchand
2020-07-06 20:52 ` [dpdk-dev] [PATCH v6 06/10] eal: register non-EAL threads as lcores David Marchand
2022-11-03 9:02 ` Morten Brørup
2022-11-03 10:15 ` Thomas Monjalon
2020-07-06 20:52 ` [dpdk-dev] [PATCH v6 07/10] eal: add lcore init callbacks David Marchand
2022-12-15 9:05 ` Morten Brørup
2022-12-15 9:09 ` David Marchand
2022-12-15 10:21 ` Morten Brørup
2022-12-16 8:09 ` David Marchand
2022-12-16 9:55 ` Morten Brørup
2020-07-06 20:52 ` [dpdk-dev] [PATCH v6 08/10] eal: add lcore iterators David Marchand
2020-07-06 20:52 ` [dpdk-dev] [PATCH v6 09/10] mempool/bucket: handle non-EAL lcores David Marchand
2020-07-06 20:52 ` [dpdk-dev] [PATCH v6 10/10] eal: add multiprocess disable API David Marchand
2020-07-06 23:22 ` [dpdk-dev] [PATCH v6 00/10] Register non-EAL threads as lcore Ananyev, Konstantin
2020-07-08 13:05 ` David Marchand
2020-07-08 13:06 ` 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=BYAPR11MB3301435E5F0E50FBAA0E3C269A6F0@BYAPR11MB3301.namprd11.prod.outlook.com \
--to=konstantin.ananyev@intel.com \
--cc=anatoly.burakov@intel.com \
--cc=arybchenko@solarflare.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=i.maximets@ovn.org \
--cc=ian.stokes@intel.com \
--cc=jerinjacobk@gmail.com \
--cc=john.mcnamara@intel.com \
--cc=ktraynor@redhat.com \
--cc=marko.kovacevic@intel.com \
--cc=mdr@ashroe.eu \
--cc=nhorman@tuxdriver.com \
--cc=olivier.matz@6wind.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).