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 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: 126+ 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 2020-07-06 20:52 ` [dpdk-dev] [PATCH v6 07/10] eal: add lcore init callbacks David Marchand 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
DPDK patches and discussions This inbox may be cloned and mirrored by anyone: git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \ dev@dpdk.org public-inbox-index dev Example config snippet for mirrors. Newsgroup available over NNTP: nntp://inbox.dpdk.org/inbox.dpdk.dev AGPL code for this site: git clone https://public-inbox.org/public-inbox.git