DPDK usage discussions
 help / color / mirror / Atom feed
From: "Jensen, Allen" <pjensen@arbor.net>
To: "users@dpdk.org" <users@dpdk.org>
Subject: [dpdk-users] Question about NUMA node for PCI devices and rte_eal_init
Date: Tue, 9 Jan 2018 22:33:14 +0000	[thread overview]
Message-ID: <5E41413A-C9B1-4ED4-BC5D-4789B8277E8E@arbor.net> (raw)

This is my first email to the list so apologies if it’s off-topic or anything – just let me know (flame to live, live to flame…)

Had used version 2.2.0 for a while when upgrading to 17.05.02 we discovered the PCI port scan was now trying to allocate memory only from pools allocated for the NUMA node the PCI device was mapped to. In version 2.2.0, it did not do this and used the equivalent of SOCKET_ID_ANY (-1) for the NUMA node.

We had a scenario in which there was a single interface on numa node 1 and all others were on node 0 and we were just allocating everything on node 0 (the on node 0 was a slow interface anyway so performance was not an issue).

It turns out that now an internal data structure – device.dev_private – cannot be allocated because we were not allocating any memory buffer pools for node 1.

My question is – does this dev_private area really need to be forced onto a specific numa node?

Specifically – the line is:

lib/librte_ether/rte_ethdev_pci.h:
                eth_dev->data->dev_private = rte_zmalloc_socket(name,
                                private_data_size, RTE_CACHE_LINE_SIZE,
                                dev->device.numa_node);

I have been trying to understand what eth_dev->data->dev_private is used for and implications of patching ours to use SOCKET_ID_ANY instead of the numa node….

Does any one else have experience with this or have thoughts on the matter?

--
Allen Jensen
Software Engineer
Arbor Networks
pjensen@arbor.net<mailto:bstpierre@arbor.net>
1 404 538 2759
https://www.arbornetworks.com/



                 reply	other threads:[~2018-01-09 22:33 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=5E41413A-C9B1-4ED4-BC5D-4789B8277E8E@arbor.net \
    --to=pjensen@arbor.net \
    --cc=users@dpdk.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).