Hi Panu, On 3/8/2016 4:54 PM, Panu Matilainen wrote: > On 03/04/2016 12:05 PM, Jianfeng Tan wrote: >> This patch adds option, --avail-cores, to use lcores which are available >> by calling pthread_getaffinity_np() to narrow down detected cores before >> parsing coremask (-c), corelist (-l), and coremap (--lcores). >> >> Test example: >> $ taskset 0xc0000 ./examples/helloworld/build/helloworld \ >> --avail-cores -m 1024 >> >> Signed-off-by: Jianfeng Tan <jianfeng.tan at intel.com> >> Acked-by: Neil Horman <nhorman at tuxdriver.com> > > Hmm, to me this sounds like something that should be done always so > there's no need for an option. Or if there's a chance it might do the > wrong thing in some rare circumstance then perhaps there should be a > disabler option instead?
Thanks for comments. Yes, there's a use case that we cannot handle. If we make it as default, DPDK applications may fail to start, when user specifies a core in isolcpus and its parent process (say bash) has a cpuset affinity that excludes isolcpus. Originally, DPDK applications just blindly do pthread_setaffinity_np() and it always succeeds because it always has root privilege to change any cpu affinity. Now, if we do the checking in rte_eal_cpu_init(), those lcores will be flagged as undetected (in my older implementation) and leads to failure. To make it correct, we would always add "taskset mask" (or other ways) before DPDK application cmd lines. How do you think? Thanks, Jianfeng > > Or am I just missing something? > > - Panu - >
