From: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
To: "Richardson, Bruce" <bruce.richardson@intel.com>,
Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] Add an API to query enabled core index
Date: Thu, 12 Jun 2014 00:18:19 +0000 [thread overview]
Message-ID: <3EB4FA525960D640B5BDFFD6A3D891261B1C3DE0@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <59AF69C657FD0841A61C55336867B5B01AA352EF@IRSMSX103.ger.corp.intel.com>
Maybe we could simplify this discussion by simply creating a new function to return the mask of all enabled cores (as provided through -c coremask EAL option) and have the user utilize this mask to derive whatever info it needs?
Right now, to get the mask of enabled cores, a for loop is required to test each core index one by one and re-create the mask.
In several instances, I needed to know just the number of enabled cores (i.e. number of bits set in -c coremask), and there was no alternative to the for loop above. But given such a function, we can quickly do:
uint64_t coremask = rte_eal_coremask();
n_lcores = __builtin_popcountll(coremask);
For what Patrick needs:
uint32_t lcore_enabled_pos = __builtin_popcountll(coremask & RTE_LEN2MASK(lcore_index));
Regards,
Cristian
-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Richardson, Bruce
Sent: Thursday, June 12, 2014 12:28 AM
To: Thomas Monjalon
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] Add an API to query enabled core index
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, June 11, 2014 3:50 PM
> To: Richardson, Bruce
> Cc: Lu, Patrick; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] Add an API to query enabled core index
>
> 2014-06-11 21:57, Richardson, Bruce:
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > > 2014-06-11 13:45, Patrick Lu:
> > > > The new API rte_lcore_id2() will return an index from enabled lcores
> > > > starting from zero.
> > >
> > > I think core_id2 is not a representative name.
> > > What do you think of renaming core_id as lcore_hwid and core_id2 as
> > > lcore_index?
> >
> > I like lcore_index as the name for the new function. However, I'm not sure
> > in that case that we want/need to rename the old one.
>
> I think it would be not easy to distinguish id and index. So I prefer
> hwid/index. And lcore is more precise than core.
>
The function is already called "rte_lcore_id()" so there is no need to change it to make it an "lcore" function. That function has been around for a long time and is commonly used, so I'd prefer it not be changed unless it really is necessary. "rte_lcore_index" is a sufficiently different function name, in my opinion. The API documentation should clear up any confusion for the user anyway.
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
next prev parent reply other threads:[~2014-06-12 0:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-11 20:45 Patrick Lu
2014-06-11 21:51 ` Thomas Monjalon
2014-06-11 21:57 ` Richardson, Bruce
2014-06-11 22:50 ` Thomas Monjalon
2014-06-11 23:27 ` Richardson, Bruce
2014-06-12 0:18 ` Dumitrescu, Cristian [this message]
2014-06-12 8:20 ` Olivier MATZ
2014-06-12 15:54 ` Richardson, Bruce
2014-06-13 16:58 ` Patrick Lu
2014-06-13 17:25 ` Richardson, Bruce
2014-06-11 21:58 ` Lu, Patrick
2014-06-11 22:46 ` Thomas Monjalon
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=3EB4FA525960D640B5BDFFD6A3D891261B1C3DE0@IRSMSX102.ger.corp.intel.com \
--to=cristian.dumitrescu@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=thomas.monjalon@6wind.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).