From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C0419A0547; Thu, 9 Sep 2021 10:01:27 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A0F7E41123; Thu, 9 Sep 2021 10:01:27 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id BC3064003E for <dev@dpdk.org>; Thu, 9 Sep 2021 10:01:25 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10101"; a="217558400" X-IronPort-AV: E=Sophos;i="5.85,279,1624345200"; d="scan'208";a="217558400" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2021 01:01:24 -0700 X-IronPort-AV: E=Sophos;i="5.85,279,1624345200"; d="scan'208";a="696134809" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.3.161]) by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 09 Sep 2021 01:01:21 -0700 Date: Thu, 9 Sep 2021 09:01:16 +0100 From: Bruce Richardson <bruce.richardson@intel.com> To: Juraj =?utf-8?Q?Linke=C5=A1?= <juraj.linkes@pantheon.tech> Cc: Piotr Kubaj <pkubaj@anongoth.pl>, David Christensen <drc@linux.vnet.ibm.com>, "thomas@monjalon.net" <thomas@monjalon.net>, "david.marchand@redhat.com" <david.marchand@redhat.com>, "Honnappa.Nagarahalli@arm.com" <Honnappa.Nagarahalli@arm.com>, "Ruifeng.Wang@arm.com" <Ruifeng.Wang@arm.com>, "ferruh.yigit@intel.com" <ferruh.yigit@intel.com>, "jerinjacobk@gmail.com" <jerinjacobk@gmail.com>, "jerinj@marvell.com" <jerinj@marvell.com>, "stephen@networkplumber.org" <stephen@networkplumber.org>, "dev@dpdk.org" <dev@dpdk.org> Message-ID: <YTm/TPiiZ5BjHHmY@bricha3-MOBL.ger.corp.intel.com> References: <1624964105-6525-1-git-send-email-juraj.linkes@pantheon.tech> <1626872655-27496-1-git-send-email-juraj.linkes@pantheon.tech> <8198751beeaf4a94acc951b1c1d4fba4@pantheon.tech> <b80d8861-4c45-8d72-56c0-9b9ab9158d84@linux.vnet.ibm.com> <93e6576242a24380b83d8ca82359c28e@pantheon.tech> <YS19zhZhzq6V6VM1@KGPE-D16> <ab45c677f71e48cc86fa1ae564be81cb@pantheon.tech> <YS3iKhdxyU3Ry6Sq@bricha3-MOBL.ger.corp.intel.com> <2244c98874b14069bacc178516bb8e74@pantheon.tech> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2244c98874b14069bacc178516bb8e74@pantheon.tech> Subject: Re: [dpdk-dev] [PATCH v5] build: optional NUMA and cpu counts detection X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On Thu, Sep 09, 2021 at 07:20:27AM +0000, Juraj Linkeš wrote: > > > > -----Original Message----- > > From: Bruce Richardson <bruce.richardson@intel.com> > > Sent: Tuesday, August 31, 2021 10:03 AM > > To: Juraj Linkeš <juraj.linkes@pantheon.tech> > > Cc: Piotr Kubaj <pkubaj@anongoth.pl>; David Christensen > > <drc@linux.vnet.ibm.com>; thomas@monjalon.net; > > david.marchand@redhat.com; Honnappa.Nagarahalli@arm.com; > > Ruifeng.Wang@arm.com; ferruh.yigit@intel.com; jerinjacobk@gmail.com; > > jerinj@marvell.com; stephen@networkplumber.org; dev@dpdk.org > > Subject: Re: [PATCH v5] build: optional NUMA and cpu counts detection > > > > On Tue, Aug 31, 2021 at 07:54:16AM +0000, Juraj Linkeš wrote: > > > > > > > > > > -----Original Message----- > > > > From: Piotr Kubaj <pkubaj@anongoth.pl> > > > > Sent: Tuesday, August 31, 2021 2:55 AM > > > > To: Juraj Linkeš <juraj.linkes@pantheon.tech> > > > > Cc: David Christensen <drc@linux.vnet.ibm.com>; thomas@monjalon.net; > > > > david.marchand@redhat.com; bruce.richardson@intel.com; > > > > Honnappa.Nagarahalli@arm.com; Ruifeng.Wang@arm.com; > > > > ferruh.yigit@intel.com; jerinjacobk@gmail.com; jerinj@marvell.com; > > > > stephen@networkplumber.org; dev@dpdk.org > > > > Subject: Re: [PATCH v5] build: optional NUMA and cpu counts > > > > detection > > > > > > > > Hi, > > > > > > > > sorry for the late answer. > > > > > > Thanks for the answer anyway, better late than never. > > > > > > > > > > > I suppose you mean sysctl command, not systemctl. > > > > > > > > > > That's right. What does lscpu say? Are the NUMA nodes non-contiguous like > > this?: > > > NUMA node0 CPU(s): 0-63 > > > NUMA node8 CPU(s): 64-127 > > > NUMA node252 CPU(s): > > > NUMA node253 CPU(s): > > > NUMA node254 CPU(s): > > > NUMA node255 CPU(s): > > > > > > > On dual CPU systems, it returns 2. On single CPU ones, 1. > > > > > > I asked the previous question so that we know the actual numa node number > > of the second CPU. If it's 8, then sysctl does some renumeration and we can't > > use it. > > > > > > Bruce, maybe we should just parse lscpu output? That introduces a > > dependency, but that may not be such a big deal as lscpu is pretty common. > > > > > Until we are sure that we need it, can we just keep things simple? Perhaps we > > can use lscpu if present, and fallback to sysctl output if not. > > Piotr says lscpu isn't available on ppc FreeBSD. I think this leaves us with two options: > 1. either use sysctl with the risk that it may not return an accurate value > 2. not support PPC for numa detection > > What do you think? I think point #2 is more not supporting FreeBSD on PPC for numa detection rather than not supporting PPC generally, right? Personally, I am just in favour of #1 for the sake of moving forward and giving us best support with simplest code. If or when someone does hit this (FreeBSD+PPC) as a problem, then we can work with them to find best solution for fixing it. Right now we don't have anyone with the PPC+FreeBSD setup, so I'd rather ignore it than implement more complicated solutions that we can't test "just in case". /Bruce