From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id A9AA12BA9 for ; Wed, 9 Mar 2016 14:53:09 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP; 09 Mar 2016 05:53:08 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,311,1455004800"; d="scan'208";a="760938578" Received: from shwdeisgchi083.ccr.corp.intel.com (HELO [10.239.67.193]) ([10.239.67.193]) by orsmga003.jf.intel.com with ESMTP; 09 Mar 2016 05:53:07 -0800 To: Panu Matilainen , dev@dpdk.org References: <1453661393-85704-1-git-send-email-jianfeng.tan@intel.com> <1457085957-115339-1-git-send-email-jianfeng.tan@intel.com> <56DE9359.1090705@redhat.com> <56DF0E0A.8000108@intel.com> <56E01F94.2060906@redhat.com> From: "Tan, Jianfeng" Message-ID: <56E02AC2.7010704@intel.com> Date: Wed, 9 Mar 2016 21:53:06 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56E01F94.2060906@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] eal: add option --avail-cores to detect lcores X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 13:53:10 -0000 On 3/9/2016 9:05 PM, Panu Matilainen wrote: > On 03/08/2016 07:38 PM, Tan, Jianfeng wrote: >> 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 >>>> Acked-by: Neil Horman >>> >>> 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? > > I still think it sounds like something that should be done by default > and maybe be overridable with some flag, rather than the other way > around. Another alternative might be detecting the cores always but if > running as root, override but with a warning. For your second solution, only root can setaffinity to isolcpus? Your first solution seems like a promising way for me. > > But I dont know, just wondering. To look at it from another angle: why > would somebody use this new --avail-cores option and in what > situation, if things "just work" otherwise anyway? For DPDK applications, the most common case to initialize DPDK is like this: "$dpdk-app [options for DPDK] -- [options for app]", so users need to specify which cores to run and how much hugepages are used. Suppose we need this dpdk-app to run in a container, users already give those information when they build up the cgroup for it to run inside, this option or this patch is to make DPDK more smart to discover how much resource will be used. Make sense? Thanks, Jianfeng > > - Panu - >