> -----Original Message----- > From: Walukiewicz, Miroslaw > Sent: Monday, December 22, 2014 6:02 PM > To: Richardson, Bruce; Liang, Cunming > Cc: dev at dpdk.org > Subject: RE: [dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore > > > -----Original Message----- > > From: Richardson, Bruce > > Sent: Monday, December 22, 2014 10:46 AM > > To: Liang, Cunming > > Cc: Walukiewicz, Miroslaw; dev at dpdk.org > > Subject: Re: [dpdk-dev] [RFC PATCH 0/7] support multi-phtread per lcore > > > > On Mon, Dec 22, 2014 at 01:51:27AM +0000, Liang, Cunming wrote: > > > ... > > > > I'm conflicted on this one. However, I think far more applications would > > be > > > > broken > > > > to start having to use thread_id in place of an lcore_id than would be > > broken > > > > by having the lcore_id no longer actually correspond to a core. > > > > I'm actually struggling to come up with a large number of scenarios > > > > where > > it's > > > > important to an app to determine the cpu it's running on, compared to > > the large > > > > number of cases where you need to have a data-structure per thread. In > > DPDK > > > > libs > > > > alone, you see this assumption that lcore_id == thread_id a large number > > of > > > > times. > > > > > > > > Despite the slight logical inconsistency, I think it's better to avoid > > introducing > > > > a thread-id and continue having lcore_id representing a unique thread. > > > > > > > > /Bruce > > > > > > Ok, I understand it. > > > I list the implicit meaning if using lcore_id representing the unique > > > thread. > > > 1). When lcore_id less than RTE_MAX_LCORE, it still represents the logical > > core id. > > > 2). When lcore_id large equal than RTE_MAX_LCORE, it represents an > > unique id for thread. > > > 3). Most of APIs(except rte_lcore_id()) in rte_lcore.h suggest to be used > > only in CASE 1) > > > 4). rte_lcore_id() can be used in CASE 2), but the return value no matter > > represent a logical core id. > > > > > > If most of us feel it's acceptable, I'll prepare for the RFC v2 base on > > > this > > conclusion. > > > > > > /Cunming > > > > Sorry, I don't like that suggestion either, as having lcore_id values > > greater > > than RTE_MAX_LCORE is terrible, as how will people know how to dimension > > arrays > > to be indexes by lcore id? [Liang, Cunming] For dimension array, we shall have RTE_MAX_THREAD_ID. Lcore id no longer means logical core, so why still use RTE_MAX_LCORE as the dimension ? In my previous mind, I don't expect to change lcore_config. RTE_MAX_LCORE is only used to identify the legal id for logical core. So there's no any change when id < RTE_MAX_LCORE, while id > RTE_MAX_LCORE cause fail in lcore API.
>> Given the choice, if we are not going to just use > > lcore_id as a generic thread id, which is always between 0 and > > RTE_MAX_LCORE > > we can look to define a new thread_id variable to hold that. However, it > > should > > have a bounded range. [Liang, Cunming] Agree, if we merge lcore id with linear thread id, anyway we require RTE_MAX_THREAD_ID. > > From an ease-of-porting perspective, I still think that the simplest option > > is to > > use the existing lcore_id and accept the fact that it's now a thread id > > rather > > than an actual physical lcore. [Liang, Cunming] Not sure do you means propose to extend lcore_config as a per thread context instead of per lcore ? If accepts the fact lcore_id is now a thread id, how to make decision the physical lcore is in core mask or not ? Question is, is would that cause us lots of issues > > in the future? [Liang, Cunming] Personally I don't like this way that lcore id sometimes stand for logical core id, sometimes stand for thread id. The benefit of it looks like avoid trivial change. Actually will change the meaning of API and implement. What I propose linear thread id is new, but we can control and estimate such limited change where it happens. > > > I would prefer keeping the RTE_MAX_LCORES as Bruce suggests and > determine the HW core on base of following condition if we really have to know > this. > > int num_cores_online = count of cores encountered in the core mask provided by > cmdline parameter [Liang, Cunming] In this way, if we have core mask 0xf0. num_cores_online will be 4. rte_lcore_id() value for logical core will be 0, 1, 2, 3, which is no longer 4,5,6,7. That's probably all right if trying to give up the origin meaning of lcore_id, and change to identify a unique thread id. But I don't think having a dynamic num_cores_online is a good idea. If in one day, we plan to support lcore hot plug, the num_cores_online will change in the fly. It's bad to get the id which already occupied by some thread. > > Rte_lcore_id() < num_cores_online -> physical core (pthread first started on > the > core) > > Rte_lcore_id() >= num_cores_online -> pthread created by rte_pthread_create > > Mirek > > > /Bruce
