From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 4696CA0096 for ; Fri, 12 Apr 2019 11:06:09 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 63DFF5A44; Fri, 12 Apr 2019 11:06:08 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 83688532C for ; Fri, 12 Apr 2019 11:06:06 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2019 02:06:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,340,1549958400"; d="scan'208";a="290947869" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.220.103]) by orsmga004.jf.intel.com with SMTP; 12 Apr 2019 02:06:02 -0700 Received: by (sSMTP sendmail emulation); Fri, 12 Apr 2019 10:06:01 +0100 Date: Fri, 12 Apr 2019 10:06:01 +0100 From: Bruce Richardson To: David Marchand Cc: Aaron Conole , dev , Luca Boccassi , Reshma Pattan , Agalya Babu RadhaKrishnan , David Marchand Message-ID: <20190412090601.GA1723@bricha3-MOBL.ger.corp.intel.com> References: <20190411195229.7841-1-aconole@redhat.com> <20190411195229.7841-4-aconole@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH 3/3] app/test/meson: auto detect number of cores X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190412090601.oJWd6fRt88Jy17e1EQFk8Q_BRNBo0zOB6ZcfFcmOHFQ@z> On Fri, Apr 12, 2019 at 09:46:17AM +0200, David Marchand wrote: > On Thu, Apr 11, 2019 at 9:52 PM Aaron Conole <[1]aconole@redhat.com> > wrote: > > The arguments being passed will cause failures on laptops that have, > for instance, 2 cores only. Most of the tests don't require more > than a single core. Some require multiple cores (but those tests > should be modified to 'SKIP' when the correct number of cores > aren't available). > The unit test results shouldn't be impacted by this change, but it > allows for a future enhancement to pass flags such as '--no-huge'. > Also include a fix to a reported issue with running on FreeBSD. > Signed-off-by: Aaron Conole <[2]aconole@redhat.com> > --- > Conflicts with [3]http://patches.dpdk.org/patch/50850/ > app/test/meson.build | 24 +++++++++++++++++++++--- > 1 file changed, 21 insertions(+), 3 deletions(-) > diff --git a/app/test/meson.build b/app/test/meson.build > index 867cc5863..1010bfbc8 100644 > --- a/app/test/meson.build > +++ b/app/test/meson.build > @@ -344,17 +344,32 @@ if get_option('tests') > timeout_seconds = 600 > timeout_seconds_fast = 10 > + # Retreive the number of CPU cores > > nit: Retrieve > Little concern here on the approach of getting the max available cpu > index. > If we have non contiguous cpus (let's say hyper threading is disabled), > this won't work. > But we can just assume this won't happen for non regression setups > (vms). > > + num_cores = run_command('lscpu', > '-p=cpu').stdout().strip().split('\n')[-1] > > lscpu is a linux command afaik. > Maybe for FreeBSD: > root@freebsd-10:~ # sysctl dev.cpu |cut -d . -f 3 |sort |tail -1 > 3 > Not sure if FreeBSD ensures that the keys names/objects won't change > accross the versions. > Very similar thoughs/concerns here. I think doing this per OS is probably safer in the long term - even though lscpu is available for FreeBSD as an extra package. My suggestion: for FreeBSD, get the number of CPUs using "/sbin/sysctl -n hw.ncpu" For Linux, rather than using a "0-N" range, use output from "cat /sys/devices/system/cpu/present", which will ensure that it works even in the non-contiguous CPU numbering case. [Though I suspect we get non-contiguous numbers only in the case a core or two has been hotplugged out, I think - disabling hyperthreading won't leave gaps, just fewer cores] /Bruce