All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: Oscar Zhao <oz@quacker.org>, dev@dpdk.org
Subject: Re: [dpdk-dev] Feature Discussion: CPU topology detection on FreeBSD
Date: Wed, 10 Feb 2021 16:01:38 +0000	[thread overview]
Message-ID: <d10686a5-3a11-5f46-9efd-434371cadf30@intel.com> (raw)
In-Reply-To: <20210129134511.GF929@bricha3-MOBL.ger.corp.intel.com>

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

      parent reply	other threads:[~2021-02-10 16:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-28  4:07 [dpdk-dev] Feature Discussion: CPU topology detection on FreeBSD Oscar Zhao
2021-01-29 10:05 ` Bruce Richardson
2021-01-29 12:52   ` Burakov, Anatoly
2021-01-29 13:45     ` Bruce Richardson
2021-01-29 22:24       ` Oscar Zhao
2021-02-10 16:01       ` Burakov, Anatoly [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d10686a5-3a11-5f46-9efd-434371cadf30@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=oz@quacker.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.