From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by dpdk.org (Postfix) with ESMTP id BEF87ADB6 for ; Wed, 18 May 2016 14:47:06 +0200 (CEST) Received: by mail-wm0-f53.google.com with SMTP id r12so32995874wme.0 for ; Wed, 18 May 2016 05:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7ZN2M5ZVvST9B9ZtJ1441pYi4zXNo2HzJRvtIxS5UP4=; b=vEughQs1k12hFCVh4lIBJfFE9zCSfjwKBU6Z/kk9EqodxeJc7PZlR+Wt009kZZXBXT 7I/Waj3221QElYrhfD1EqpWmAgfxWs+4JuNedTusI81hpGD8aLVGOczFiONC9xvsrs4F 89S+tf8N2FghnZSP+nieP0GxmILmW0d3outUy0oxzulJKG1V8UzuEsr9qXZGKVyWrKjV mZNfWEzwuVgPTx6lkziYIN7drJZv6pZJ9eG4RUYOgSM85XEWFclNSLrhduTUN6K21/BL Dmkj9eAekk+rbcHq70gStYMdrHmcX+QvENXl9WzKq+GoTjl1q+X4OOr8fCF6OvPmflcR vOFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7ZN2M5ZVvST9B9ZtJ1441pYi4zXNo2HzJRvtIxS5UP4=; b=IpLPGlByLB+yxTgpUnUaLdV8586IJJVyHIkAy6Qk9h3yKTb40SkbC7S19QEFz5Cxvk TaEj4Q4nzQwvw+9Pj9i+peRunBaPVEATxNbXKlAuF35v7h16fwv7lpFPxzc/hYt7mF8D dE93Qrj/mjjVPoVOvy8kfZno65miXK6GXX40zrj0b4sKoKrHsntNQ45xy+JhmapT5e2A KP6UonKWDud+G9WVkaBN/AnmFFs3XFJgI4shq22AwXgQ30WQlJcBPF7hANpOEPvn0wqT SU+AWBd2K+gcLvMB5cIHXirRyn/V8ELhf65r3CP5Ol1DedXhpkiWbDW+Z8QHp1ixWLfx APyw== X-Gm-Message-State: AOPr4FXBtFRfKrc8F3FRqY9F/lGi2XIN4SMt0pxKKTHOVEro5m1OAVIW5B5wDPY7IcTezIpNjJss7rbttBGPLPEY X-Received: by 10.194.123.67 with SMTP id ly3mr7060169wjb.135.1463575626593; Wed, 18 May 2016 05:47:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.16.2 with HTTP; Wed, 18 May 2016 05:46:46 -0700 (PDT) In-Reply-To: <56E01F94.2060906@redhat.com> 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: David Marchand Date: Wed, 18 May 2016 14:46:46 +0200 Message-ID: To: "Tan, Jianfeng" Cc: "dev@dpdk.org" , Panu Matilainen Content-Type: text/plain; charset=UTF-8 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, 18 May 2016 12:47:06 -0000 Hello Jianfeng, On Wed, Mar 9, 2016 at 2: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. > > 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? +1 and I don't even see why we should have an option to disable this, since taskset would do the job. Looking at your special case, if the user did set an isolcpus option for another use, with no -c/-l, I understand the dpdk application won't care too much about it. So, this seems like somehow rude to the rest of the system and unwanted. We can still help the user starting its application as root (without taskset) by adding a warning message if a requested cpu (-c / -l ..) is not part of the available cpus. -- David Marchand