DPDK patches and discussions
 help / color / mirror / Atom feed
From: Anatoly Burakov <anatoly.burakov@intel.com>
To: dev@dpdk.org
Cc: srinath.mannam@broadcom.com, scott.branden@broadcom.com,
	ajit.khaparde@broadcom.com
Subject: [dpdk-dev] [RFC 00/11] Support externally allocated memory in DPDK
Date: Fri,  6 Jul 2018 14:17:21 +0100	[thread overview]
Message-ID: <cover.1530881548.git.anatoly.burakov@intel.com> (raw)

This is a proposal to enable using externally allocated memory
in DPDK.

In a nutshell, here is what is being done here:

- Index malloc heaps by NUMA node index, rather than NUMA node itself
- Add identifier string to malloc heap, to uniquely identify it
- Allow creating named heaps and add/remove memory to/from those heaps
- Allocate memseg lists at runtime, to keep track of IOVA addresses
  of externally allocated memory
  - If IOVA addresses aren't provided, use RTE_BAD_IOVA
- Allow malloc and memzones to allocate from named heaps

The responsibility to ensure memory is accessible before using it is
on the shoulders of the user - there is no checking done with regards
to validity of the memory (nor could there be...).

The following limitations are present:

- No multiprocess support
- No thread safety

There is currently no way to allocate memory during initialization
stage, so even if multiprocess support is added, it is not guaranteed
to work because of underlying issues with mapping fbarrays in
secondary processes. This is not an issue in single process scenario,
but it may be an issue in a multiprocess scenario in case where
primary doesn't intend to share the externally allocated memory, yet
adding such memory could fail because some other process failed to
attach to this shared memory when it wasn't needed.

Anatoly Burakov (11):
  mem: allow memseg lists to be marked as external
  eal: add function to rerieve socket index by socket ID
  malloc: index heaps using heap ID rather than NUMA node
  malloc: add name to malloc heaps
  malloc: enable retrieving statistics from named heaps
  malloc: enable allocating from named heaps
  malloc: enable creating new malloc heaps
  malloc: allow adding memory to named heaps
  malloc: allow removing memory from named heaps
  malloc: allow destroying heaps
  memzone: enable reserving memory from named heaps

 config/common_base                            |   1 +
 lib/librte_eal/common/eal_common_lcore.c      |  15 +
 lib/librte_eal/common/eal_common_memory.c     |  51 +++-
 lib/librte_eal/common/eal_common_memzone.c    | 283 ++++++++++++++----
 .../common/include/rte_eal_memconfig.h        |   5 +-
 lib/librte_eal/common/include/rte_lcore.h     |  19 +-
 lib/librte_eal/common/include/rte_malloc.h    | 158 +++++++++-
 .../common/include/rte_malloc_heap.h          |   2 +
 lib/librte_eal/common/include/rte_memzone.h   | 183 +++++++++++
 lib/librte_eal/common/malloc_heap.c           | 277 +++++++++++++++--
 lib/librte_eal/common/malloc_heap.h           |  26 ++
 lib/librte_eal/common/rte_malloc.c            | 197 +++++++++++-
 lib/librte_eal/rte_eal_version.map            |  10 +
 13 files changed, 1118 insertions(+), 109 deletions(-)

-- 
2.17.1

             reply	other threads:[~2018-07-06 13:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-06 13:17 Anatoly Burakov [this message]
2018-07-06 13:17 ` [dpdk-dev] [RFC 01/11] mem: allow memseg lists to be marked as external Anatoly Burakov
2018-07-10 11:18   ` Alejandro Lucero
2018-07-10 11:31     ` Burakov, Anatoly
2018-07-06 13:17 ` [dpdk-dev] [RFC 02/11] eal: add function to rerieve socket index by socket ID Anatoly Burakov
2018-07-10 13:03   ` Alejandro Lucero
2018-07-06 13:17 ` [dpdk-dev] [RFC 03/11] malloc: index heaps using heap ID rather than NUMA node Anatoly Burakov
2018-07-13 16:05   ` Alejandro Lucero
2018-07-13 16:08     ` Burakov, Anatoly
2018-07-06 13:17 ` [dpdk-dev] [RFC 04/11] malloc: add name to malloc heaps Anatoly Burakov
2018-07-13 16:09   ` Alejandro Lucero
2018-07-06 13:17 ` [dpdk-dev] [RFC 05/11] malloc: enable retrieving statistics from named heaps Anatoly Burakov
2018-07-13 16:25   ` Alejandro Lucero
2018-07-06 13:17 ` [dpdk-dev] [RFC 06/11] malloc: enable allocating " Anatoly Burakov
2018-07-13 16:31   ` Alejandro Lucero
2018-07-06 13:17 ` [dpdk-dev] [RFC 07/11] malloc: enable creating new malloc heaps Anatoly Burakov
2018-07-06 13:17 ` [dpdk-dev] [RFC 08/11] malloc: allow adding memory to named heaps Anatoly Burakov
2018-07-13 17:04   ` Alejandro Lucero
2018-07-06 13:17 ` [dpdk-dev] [RFC 09/11] malloc: allow removing memory from " Anatoly Burakov
2018-07-06 13:17 ` [dpdk-dev] [RFC 10/11] malloc: allow destroying heaps Anatoly Burakov
2018-07-06 13:17 ` [dpdk-dev] [RFC 11/11] memzone: enable reserving memory from named heaps Anatoly Burakov
2018-07-13 17:10 ` [dpdk-dev] [RFC 00/11] Support externally allocated memory in DPDK Burakov, Anatoly
2018-07-13 17:56   ` Wiles, Keith
2018-07-19 10:58     ` László Vadkerti
2018-07-26 13:48       ` Burakov, Anatoly

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=cover.1530881548.git.anatoly.burakov@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=ajit.khaparde@broadcom.com \
    --cc=dev@dpdk.org \
    --cc=scott.branden@broadcom.com \
    --cc=srinath.mannam@broadcom.com \
    /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).