From: "Varghese, Vipin" <Vipin.Varghese@amd.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"roretzla@linux.microsoft.com" <roretzla@linux.microsoft.com>,
"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
"john.mcnamara@intel.com" <john.mcnamara@intel.com>,
"dmitry.kozliuk@gmail.com" <dmitry.kozliuk@gmail.com>,
"jerinj@marvell.com" <jerinj@marvell.com>,
"ruifeng.wang@arm.com" <ruifeng.wang@arm.com>,
"mattias.ronnblom@ericsson.com" <mattias.ronnblom@ericsson.com>,
"anatoly.burakov@intel.com" <anatoly.burakov@intel.com>,
"Yigit, Ferruh" <Ferruh.Yigit@amd.com>,
"honnappa.nagarahalli@arm.com" <honnappa.nagarahalli@arm.com>,
"wathsala.vithanage@arm.com" <wathsala.vithanage@arm.com>,
"konstantin.ananyev@huawei.com" <konstantin.ananyev@huawei.com>
Subject: RE: [RFC v3 1/3] eal/lcore: add topology based functions
Date: Mon, 4 Nov 2024 03:16:26 +0000 [thread overview]
Message-ID: <PH7PR12MB85965429156D487FF1212AD282512@PH7PR12MB8596.namprd12.prod.outlook.com> (raw)
In-Reply-To: <20241030084759.2937bc4e@hermes.local>
Snipped
>
> > +struct topology_config {
> > +#ifdef RTE_EAL_HWLOC_TOPOLOGY_PROBE
> > + hwloc_topology_t topology;
> > +#endif
> > +
> > + /* domain count */
> > + uint16_t l1_count;
> > + uint16_t l2_count;
> > + uint8_t l3_count;
> > + uint8_t io_count;
> > +
> > + /* total cores under all domain */
> > + uint16_t l1_core_count;
> > + uint16_t l2_core_count;
> > + uint16_t l3_core_count;
> > + uint16_t io_core_count;
> > +
> > + /* two dimensional array for each domain */
> > + struct core_domain_mapping **l1;
> > + struct core_domain_mapping **l2;
> > + struct core_domain_mapping **l3;
> > + struct core_domain_mapping **io; }; extern struct
> > +topology_config topo_cnfg;
> > +
>
> To work with primary/secondary process model, it might be better to keep this info
> in hugpage/shared memory. I.e put topology_config into space allocated with
> rte_malloc() and populated by primary process.
Initially we did use `rte_memzone_reserve` and moved it under `rte_cnfg structure` for primary and secondary.
Exploring on the use cases we noticed in multiprocessor scenarios, lcore of the primary did not share. Hence we moved to using `malloc` as local allocator.
We can easily move to rte_malloc, but do we need to share the HW topology based lcore grouping to multi-process?
next prev parent reply other threads:[~2024-11-04 3:16 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-30 5:41 [RFC v3 0/3] Introduce Topology NUMA grouping for lcores Vipin Varghese
2024-10-30 5:41 ` [RFC v3 1/3] eal/lcore: add topology based functions Vipin Varghese
2024-10-30 15:43 ` Stephen Hemminger
2024-11-04 3:09 ` Varghese, Vipin
2024-10-30 15:44 ` Stephen Hemminger
2024-11-04 3:13 ` Varghese, Vipin
2024-11-04 8:45 ` Mattias Rönnblom
2024-10-30 15:45 ` Stephen Hemminger
2024-11-04 3:13 ` Varghese, Vipin
2024-10-30 15:47 ` Stephen Hemminger
2024-11-04 3:16 ` Varghese, Vipin [this message]
2024-11-04 7:57 ` Morten Brørup
2024-11-04 9:56 ` Varghese, Vipin
2024-11-04 11:21 ` Morten Brørup
2024-11-04 12:14 ` Varghese, Vipin
2024-11-04 12:29 ` Morten Brørup
2024-11-04 13:08 ` Varghese, Vipin
2024-11-04 14:04 ` Morten Brørup
2024-11-05 2:17 ` Varghese, Vipin
2024-10-30 5:41 ` [RFC v3 2/3] test/lcore: enable tests for topology Vipin Varghese
2024-10-30 11:50 ` [EXTERNAL] " Pavan Nikhilesh Bhagavatula
2024-11-04 3:07 ` Varghese, Vipin
2024-10-30 5:41 ` [RFC v3 3/3] examples: add lcore topology API calls Vipin Varghese
2024-10-30 11:49 ` [EXTERNAL] " Pavan Nikhilesh Bhagavatula
2024-10-30 12:06 ` Varghese, Vipin
2024-10-30 12:37 ` Varghese, Vipin
2024-10-30 19:34 ` Pavan Nikhilesh Bhagavatula
2024-11-04 3:02 ` Varghese, Vipin
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=PH7PR12MB85965429156D487FF1212AD282512@PH7PR12MB8596.namprd12.prod.outlook.com \
--to=vipin.varghese@amd.com \
--cc=Ferruh.Yigit@amd.com \
--cc=anatoly.burakov@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=dmitry.kozliuk@gmail.com \
--cc=honnappa.nagarahalli@arm.com \
--cc=jerinj@marvell.com \
--cc=john.mcnamara@intel.com \
--cc=konstantin.ananyev@huawei.com \
--cc=mattias.ronnblom@ericsson.com \
--cc=roretzla@linux.microsoft.com \
--cc=ruifeng.wang@arm.com \
--cc=stephen@networkplumber.org \
--cc=wathsala.vithanage@arm.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).