... > 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
