> -----Original Message----- > From: Lu, Patrick > Sent: Friday, June 13, 2014 9:58 AM > To: Richardson, Bruce > Cc: Olivier MATZ; Thomas Monjalon; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] Add an API to query enabled core index > > On Thu, Jun 12, 2014 at 08:54:11AM -0700, Richardson, Bruce wrote: > > > > > > > -----Original Message----- > > > From: Olivier MATZ [mailto:olivier.matz at 6wind.com] > > > Sent: Thursday, June 12, 2014 1:20 AM > > > To: Richardson, Bruce; Thomas Monjalon; Lu, Patrick > > > Cc: dev at dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH] Add an API to query enabled core index > > > > > > Hello, > > > > > > On 06/11/2014 11:57 PM, Richardson, Bruce wrote: > > > >> 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. > > > > > > What about lcore_rank ? > > > It may avoid confusion between "id" and "index", which are quite > > > close visually and phonetically. > > > > Not sure about rank, index is more correct. How about making it "app_index" > or "app_idx", to indicate that it's not a global id but rather the idx that's > local to > the running app instance. > > > > Other alternative approach would be rte_lcore_position() API that takes a > hardware lcore id, and tells you it's "position" in the coremask for the > application, i.e. lcore 6 is in position 2 (of e.g. 5) lcores, for instance. > [It would > obviously return -1 on non-active cores.] > The main purpose of this API is for a running thread know its relative > index in all enabled core, so it can access the shared data structure > with correct index. I don't know if we necessarily need to pass in a > hardware lcore id, I suggest the API will implicit call rte_lcore_id.
Yes, having the API call rte_lcore_id internally is simpler. However, the advantage of having the API take the hardware core id means that it then becomes possible for one thread to query the position of another. However, how likely this scenario is to be useful, I'm not sure. > > I think either position or index is a much appropriated name for this > API. What do you think of "rte_lcore_app_idx()" then as the name? This hopefully is descriptive enough and should allow us to leave the existing API unmodified.
