From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A6503A054F; Wed, 10 Feb 2021 17:02:37 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1DA8E40693; Wed, 10 Feb 2021 17:02:37 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mails.dpdk.org (Postfix) with ESMTP id 75AF340142 for ; Wed, 10 Feb 2021 17:02:35 +0100 (CET) IronPort-SDR: I739x5RrIEU6SErUFrjIoAI2uz3I+DT0f71WQjSZW4VPAmFe5Zqs4+SwStTcQURU11v/uPZfT9 vMRvoz7pclJg== X-IronPort-AV: E=McAfee;i="6000,8403,9891"; a="201207833" X-IronPort-AV: E=Sophos;i="5.81,168,1610438400"; d="scan'208";a="201207833" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Feb 2021 08:01:40 -0800 IronPort-SDR: O8EwNUrrla+1GznhiO51JeXpU8sEF+V6r807txPi12CeEsdIW+3Fbh7eVn7kSEFuSvfN2001U0 Oz86EW9dnMeA== X-IronPort-AV: E=Sophos;i="5.81,168,1610438400"; d="scan'208";a="396756933" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.247.83]) ([10.213.247.83]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Feb 2021 08:01:39 -0800 To: Bruce Richardson Cc: Oscar Zhao , dev@dpdk.org References: <20210129100537.GB929@bricha3-MOBL.ger.corp.intel.com> <8b287cd6-7ea0-96e9-5a48-89e99d84b1f9@intel.com> <20210129134511.GF929@bricha3-MOBL.ger.corp.intel.com> From: "Burakov, Anatoly" Message-ID: Date: Wed, 10 Feb 2021 16:01:38 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20210129134511.GF929@bricha3-MOBL.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] Feature Discussion: CPU topology detection on FreeBSD X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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 29-Jan-21 1:45 PM, Bruce Richardson wrote: > On Fri, Jan 29, 2021 at 12:52:50PM +0000, Burakov, Anatoly wrote: >> On 29-Jan-21 10:05 AM, Bruce Richardson wrote: >>> On Thu, Jan 28, 2021 at 04:07:07AM +0000, Oscar Zhao wrote: >>>> Hello dpdk devs, >>>> >>>> I would like to discuss the feasibility of implementing CPU topology detection on FreeBSD. Currently both eal_cpu_core_id() and eal_cpu_socket_id() in rte_eal library always return 0 on FreeBSD, making NUMA-aware development impossible without resorting to external libraries or system APIs. >>>> >>>> The CPU topology information is available via sysct kern.sched.topology_spec. The only issue is that the return value is an XML formatted object (see https://forums.freebsd.org/threads/number-of-cpus-and-cores.41299/). (https://forums.freebsd.org/threads/number-of-cpus-and-cores.41299/) I'm not sure how feasible it is to parse XML inside DPDK. >>>> >>>> On a side note, obtaining the physical NUMA node id of a core is easy - sysctl dev.cpu.[cpu#].%domain returns the corresponding node id but I have yet found a straightforward way to detect hyperthreads besides the XML thing. >>>> >>>> Oscar >>> >>> Even adding in the numa node information would be a welcome start. >>> >> >> There's little value in it though, because as far as i'm aware we can't >> allocate memory on specific NUMA nodes in FreeBSD. >> > > That is because the NUMA support in FreeBSD was not in place when we first > did the DPDK port. However, I still see no reason not to start adding it > now, even if it is only for information purposes at this point. > A lot of DPDK apps will fail to work in this case, because most of them will allocate with an explicit NUMA node. So, if you have a NUMA node assigned to an lcore but can only allocate from NUMA node 0, any allocation explicitly targeting NUMA node 1 will not succeed. -- Thanks, Anatoly