From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id BDEB1A04C5; Fri, 4 Sep 2020 00:52:49 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 12EF01C0B2; Fri, 4 Sep 2020 00:52:49 +0200 (CEST) Received: from mail-pg1-f195.google.com (mail-pg1-f195.google.com [209.85.215.195]) by dpdk.org (Postfix) with ESMTP id 8E9C4E07 for ; Fri, 4 Sep 2020 00:52:47 +0200 (CEST) Received: by mail-pg1-f195.google.com with SMTP id 67so3265500pgd.12 for ; Thu, 03 Sep 2020 15:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=gGx5yJnytRdTJIgI0s776P9faSZAzsWmnf+5sedU9MI=; b=uQsx4Si5fEOBa6JzEMm0aM8RuxAu5U6HZ6Bn2DnuKuyuF525EfWUyPL41kerFPKDns kS5CSpTcgHsoPh745Nn5hqIDZCWgsv4ea+mDcqZ1skwXfKV0ERTNs+Ka+DfbmLy3hKW8 SyFl3Vxcert/1auoBx4uRrTJJejUtj4J6sgqMrZGGrWzM11KG0PiYPLOO95Kjq7ul4bc pnQHgS5HYyCLPs4US6kBCn6Lq+QlQPJLSHKUGPcr8+dtPq2QG58c0KU+8Cr/AgDQ6kwV PzFIiLwW9h4CnSPkZ1AZLvidHn1VEfAziIanF7WQ4L7Kf3mMIKkQeG8xztnH2kNOXK1I 9n+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=gGx5yJnytRdTJIgI0s776P9faSZAzsWmnf+5sedU9MI=; b=t3JZzlyF5GmaRNLyZkn+5vk1cIqxpD+HN1/hRZM2MmvRuN0qfXdbIPW8Cv9kU8N/f7 pS2G+xwcqI5tTqOjVGUamJmPM3zQ8GtjNQr+EK0mgNXQDwB71Hz0JGUZrN8J1dxFXB5w anqyjK7e4KgaE7Ou/oNKmrYrISn65MyQsmSeO+wZ6466o7afep37I/KUD7yMpARFUEUQ QEdj6GXI+WAM5mL+nX5lEmOLENh8ltmpnXMMMhbhHg8g5Codtv7ieiXv3hymQregUxdc jw435Wfn1N9EGqsaVTs0Fd8tRMCVBUd7R3TTDUx8V6/ry4OpY2k15fx9itmg8d2pTcbR ssWQ== X-Gm-Message-State: AOAM531B9x4mcCfummCiEzWDFp9E5kPAo264svpjdLGiL7acf4MXZpk2 UL8gtYyBO9EKcwGN3G8RsML1Pw== X-Google-Smtp-Source: ABdhPJwn7U28jnGPOIsmMkld+oNe2oKcx6FOrEVvxAYi6mPj/cZMUHxoo+RHYVW06IpdFiU75FFGDg== X-Received: by 2002:a62:7bd3:: with SMTP id w202mr3211259pfc.197.1599173566676; Thu, 03 Sep 2020 15:52:46 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id u14sm3788261pfc.203.2020.09.03.15.52.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Sep 2020 15:52:46 -0700 (PDT) Date: Thu, 3 Sep 2020 15:52:37 -0700 From: Stephen Hemminger To: Juraj =?UTF-8?B?TGlua2XFoQ==?= Cc: Dharmik Thakkar , Jerin Jacob , "thomas@monjalon.net" , dpdk-dev , nd Message-ID: <20200903155237.3e61310d@hermes.lan> In-Reply-To: References: <20200825211317.8358-1-dharmik.thakkar@arm.com> <20200825211317.8358-2-dharmik.thakkar@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH 2/2] build: find max lcore programmatically 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" On Thu, 3 Sep 2020 06:20:17 +0000 Juraj Linke=C5=A1 wrote: > > -----Original Message----- > > From: dev On Behalf Of Dharmik Thakkar > > Sent: Wednesday, August 26, 2020 6:56 AM > > To: Jerin Jacob > > Cc: thomas@monjalon.net; dpdk-dev ; nd > > Subject: Re: [dpdk-dev] [PATCH 2/2] build: find max lcore programmatica= lly > >=20 > >=20 > > =20 > > > On Aug 25, 2020, at 11:47 PM, Jerin Jacob wro= te: > > > > > > On Wed, Aug 26, 2020 at 2:44 AM Dharmik Thakkar =20 > > wrote: =20 > > >> > > >> For Arm, RTE_MAX_LCORE is hard-coded into the config. It leads to > > >> incorrect RTE_MAX_LCORE when machines have same Implemener and part > > >> number but different number of CPUs. > > >> For x86, RTE_MAX_LCORE is always set to 128 (using the value set in > > >> meson_options.txt) > > >> > > >> Use python script to find max lcore when using native build to > > >> correctly set RTE_MAX_LCORE. =20 > > > > > > We may need to build on the native arm64 machine and use it on another > > > arm64 machine(Just like x86). > > > So I think, at least for default config(which will be used by > > > distribution) to support max > > > lcores as fixed. I am not sure this patch changes those aspects or > > > not? Please check. =20 > >=20 > > This patch does *not* affect =E2=80=98default=E2=80=99 build type and c= ross-compilation. > > =20 > > > =20 > > >> > > >> Signed-off-by: Dharmik Thakkar > > >> Reviewed-by: Ruifeng Wang > > >> --- > > >> config/get_max_lcores.py | 13 +++++++++++++ > > >> config/meson.build | 13 ++++++++++++- > > >> 2 files changed, 25 insertions(+), 1 deletion(-) create mode 100755 > > >> config/get_max_lcores.py > > >> > > >> diff --git a/config/get_max_lcores.py b/config/get_max_lcores.py new > > >> file mode 100755 index 000000000000..ebf1c7efdadd > > >> --- /dev/null > > >> +++ b/config/get_max_lcores.py > > >> @@ -0,0 +1,13 @@ > > >> +#!/usr/bin/python3 > > >> +# SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2020 Arm > > >> +Limited > > >> + > > >> +import os > > >> + > > >> +max_lcores =3D [] > > >> + > > >> +nCPU =3D os.cpu_count() > > >> + > > >> +max_lcores.append(str(nCPU & 0xFFF)) # Number of CPUs > > >> + > > >> +print(' '.join(max_lcores)) > > >> diff --git a/config/meson.build b/config/meson.build index > > >> 6996e5cbeaa5..80c05bc15d2f 100644 > > >> --- a/config/meson.build > > >> +++ b/config/meson.build > > >> @@ -237,11 +237,22 @@ else # for 32-bit we need smaller reserved mem= ory =20 > > areas =20 > > >> dpdk_conf.set('RTE_MAX_MEM_MB', 2048) endif > > >> > > >> - > > >> compile_time_cpuflags =3D [] > > >> subdir(arch_subdir) > > >> dpdk_conf.set('RTE_COMPILE_TIME_CPUFLAGS', > > >> ','.join(compile_time_cpuflags)) > > >> > > >> +# set max lcores > > >> +if machine !=3D 'default' and not meson.is_cross_build() > > >> + # The script returns max lcores > > >> + params =3D files('get_max_lcores.py') > > >> + cmd_out =3D run_command(params) =20 >=20 > Have you considered running just a shell command, such as "nproc --all"? Is this really a good idea? For real distributions and NFV products, the build and runtime environment = will usually be different even if on same CPU architecture. In many cases there maybe a huge build machine (128 CPU) or in a container = (reported as single cpu) even if not doing cross build.