dev.dpdk.org archive mirror
 help / color / mirror / Atom feed
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.
> 
> 


  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).