From: Anatoly Burakov <anatoly.burakov@intel.com>
To: dev@dpdk.org
Cc: John McNamara <john.mcnamara@intel.com>,
Marko Kovacevic <marko.kovacevic@intel.com>,
przemyslawx.lal@intel.com, kuralamudhan.ramakrishnan@intel.com,
ivan.coughlan@intel.com, tiwei.bie@intel.com,
ray.kinsella@intel.com, maxime.coquelin@redhat.com,
stable@dpdk.org
Subject: [dpdk-dev] [PATCH v2 2/5] memalloc: check for memfd support in segment fd API
Date: Tue, 11 Dec 2018 16:43:29 +0000 [thread overview]
Message-ID: <b3c86d2b5bf5b0c56c8f81c536e88747370f632c.1544546363.git.anatoly.burakov@intel.com> (raw)
In-Reply-To: <cover.1544546363.git.anatoly.burakov@intel.com>
In-Reply-To: <cover.1544546363.git.anatoly.burakov@intel.com>
If memfd support was not compiled, or hugepage memfd support
is not available at runtime, the API will now return proper
error code, indicating that this API is unsupported. This
changes the API, so document the changes.
Fixes: 41dbdb68723b ("mem: add external API to retrieve page fd")
Fixes: 3a44687139eb ("mem: allow querying offset into segment fd")
Cc: stable@dpdk.org
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
---
Notes:
The API is experimental, no deprecation notice needed.
doc/guides/rel_notes/release_19_02.rst | 2 ++
lib/librte_eal/linuxapp/eal/eal_memalloc.c | 40 +++++++++++++++++-----
2 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_02.rst b/doc/guides/rel_notes/release_19_02.rst
index ade41b9c8..960098582 100644
--- a/doc/guides/rel_notes/release_19_02.rst
+++ b/doc/guides/rel_notes/release_19_02.rst
@@ -88,6 +88,8 @@ API Changes
where segment fd API is not expected to be supported:
- On attempt to get segment fd for an externally allocated memory segment
+ - In cases where memfd support would have been required to provide segment
+ fd's (such as in-memory or no-huge mode)
ABI Changes
diff --git a/lib/librte_eal/linuxapp/eal/eal_memalloc.c b/lib/librte_eal/linuxapp/eal/eal_memalloc.c
index 784939566..a93548b8c 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memalloc.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memalloc.c
@@ -23,6 +23,10 @@
#include <sys/time.h>
#include <signal.h>
#include <setjmp.h>
+#ifdef F_ADD_SEALS /* if file sealing is supported, so is memfd */
+#include <linux/memfd.h>
+#define MEMFD_SUPPORTED
+#endif
#ifdef RTE_EAL_NUMA_AWARE_HUGEPAGES
#include <numa.h>
#include <numaif.h>
@@ -53,8 +57,8 @@ const int anonymous_hugepages_supported =
#endif
/*
- * we don't actually care if memfd itself is supported - we only need to check
- * if memfd supports hugetlbfs, as that already implies memfd support.
+ * we've already checked memfd support at compile-time, but we also need to
+ * check if we can create hugepage files with memfd.
*
* also, this is not a constant, because while we may be *compiled* with memfd
* hugetlbfs support, we might not be *running* on a system that supports memfd
@@ -63,10 +67,11 @@ const int anonymous_hugepages_supported =
*/
static int memfd_create_supported =
#ifdef MFD_HUGETLB
-#define MEMFD_SUPPORTED
1;
+#define RTE_MFD_HUGETLB MFD_HUGETLB
#else
0;
+#define RTE_MFD_HUGETLB 4U
#endif
/*
@@ -338,12 +343,12 @@ get_seg_memfd(struct hugepage_info *hi __rte_unused,
int fd;
char segname[250]; /* as per manpage, limit is 249 bytes plus null */
+ int flags = RTE_MFD_HUGETLB | pagesz_flags(hi->hugepage_sz);
+
if (internal_config.single_file_segments) {
fd = fd_list[list_idx].memseg_list_fd;
if (fd < 0) {
- int flags = MFD_HUGETLB | pagesz_flags(hi->hugepage_sz);
-
snprintf(segname, sizeof(segname), "seg_%i", list_idx);
fd = memfd_create(segname, flags);
if (fd < 0) {
@@ -357,8 +362,6 @@ get_seg_memfd(struct hugepage_info *hi __rte_unused,
fd = fd_list[list_idx].fds[seg_idx];
if (fd < 0) {
- int flags = MFD_HUGETLB | pagesz_flags(hi->hugepage_sz);
-
snprintf(segname, sizeof(segname), "seg_%i-%i",
list_idx, seg_idx);
fd = memfd_create(segname, flags);
@@ -1542,6 +1545,17 @@ int
eal_memalloc_get_seg_fd(int list_idx, int seg_idx)
{
int fd;
+
+ if (internal_config.in_memory || internal_config.no_hugetlbfs) {
+#ifndef MEMFD_SUPPORTED
+ /* in in-memory or no-huge mode, we rely on memfd support */
+ return -ENOTSUP;
+#endif
+ /* memfd supported, but hugetlbfs memfd may not be */
+ if (!internal_config.no_hugetlbfs && !memfd_create_supported)
+ return -ENOTSUP;
+ }
+
if (internal_config.single_file_segments) {
fd = fd_list[list_idx].memseg_list_fd;
} else if (fd_list[list_idx].len == 0) {
@@ -1565,7 +1579,7 @@ test_memfd_create(void)
int pagesz_flag = pagesz_flags(pagesz);
int flags;
- flags = pagesz_flag | MFD_HUGETLB;
+ flags = pagesz_flag | RTE_MFD_HUGETLB;
int fd = memfd_create("test", flags);
if (fd < 0) {
/* we failed - let memalloc know this isn't working */
@@ -1589,6 +1603,16 @@ eal_memalloc_get_seg_fd_offset(int list_idx, int seg_idx, size_t *offset)
{
struct rte_mem_config *mcfg = rte_eal_get_configuration()->mem_config;
+ if (internal_config.in_memory || internal_config.no_hugetlbfs) {
+#ifndef MEMFD_SUPPORTED
+ /* in in-memory or no-huge mode, we rely on memfd support */
+ return -ENOTSUP;
+#endif
+ /* memfd supported, but hugetlbfs memfd may not be */
+ if (!internal_config.no_hugetlbfs && !memfd_create_supported)
+ return -ENOTSUP;
+ }
+
/* fd_list not initialized? */
if (fd_list[list_idx].len == 0)
return -ENODEV;
--
2.17.1
next prev parent reply other threads:[~2018-12-11 16:43 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-13 17:54 [dpdk-dev] [PATCH 19.02 0/2] Allow using virtio without hugepages Anatoly Burakov
2018-11-13 17:54 ` [dpdk-dev] [PATCH 19.02 1/2] memalloc: allow setting up segment list fd's Anatoly Burakov
2018-11-13 17:54 ` [dpdk-dev] [PATCH 19.02 2/2] mem: use memfd for no-huge mode Anatoly Burakov
2018-11-28 4:57 ` Tiwei Bie
2018-11-28 9:11 ` Burakov, Anatoly
2018-12-11 16:43 ` [dpdk-dev] [PATCH v2 0/5] Allow using virtio without hugepages Anatoly Burakov
2018-12-13 4:53 ` Tiwei Bie
2018-12-13 11:43 ` [dpdk-dev] [PATCH v3 0/5] Allow using virtio-user " Anatoly Burakov
2018-12-20 22:01 ` Thomas Monjalon
2018-12-13 11:43 ` [dpdk-dev] [PATCH v3 1/5] mem: fix error code for segment fd API for external segs Anatoly Burakov
2018-12-14 9:15 ` Maxime Coquelin
2018-12-13 11:43 ` [dpdk-dev] [PATCH v3 2/5] memalloc: check for memfd support in segment fd API Anatoly Burakov
2018-12-14 9:19 ` Maxime Coquelin
2018-12-13 11:43 ` [dpdk-dev] [PATCH v3 3/5] memalloc: allow setting up segment list fd's Anatoly Burakov
2018-12-14 10:03 ` Maxime Coquelin
2018-12-13 11:43 ` [dpdk-dev] [PATCH v3 4/5] mem: use memfd for no-huge mode Anatoly Burakov
2018-12-13 11:59 ` Burakov, Anatoly
2018-12-14 10:06 ` Maxime Coquelin
2018-12-13 11:43 ` [dpdk-dev] [PATCH v3 5/5] test: add segment fd API test Anatoly Burakov
2018-12-14 10:09 ` Maxime Coquelin
2018-12-11 16:43 ` [dpdk-dev] [PATCH v2 1/5] mem: fix error code for segment fd API for external segs Anatoly Burakov
2018-12-11 16:43 ` Anatoly Burakov [this message]
2018-12-11 16:43 ` [dpdk-dev] [PATCH v2 3/5] memalloc: allow setting up segment list fd's Anatoly Burakov
2018-12-11 16:43 ` [dpdk-dev] [PATCH v2 4/5] mem: use memfd for no-huge mode Anatoly Burakov
2018-12-13 4:59 ` Tiwei Bie
2018-12-13 11:36 ` Burakov, Anatoly
2018-12-11 16:43 ` [dpdk-dev] [PATCH v2 5/5] test: add segment fd API test Anatoly Burakov
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=b3c86d2b5bf5b0c56c8f81c536e88747370f632c.1544546363.git.anatoly.burakov@intel.com \
--to=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=ivan.coughlan@intel.com \
--cc=john.mcnamara@intel.com \
--cc=kuralamudhan.ramakrishnan@intel.com \
--cc=marko.kovacevic@intel.com \
--cc=maxime.coquelin@redhat.com \
--cc=przemyslawx.lal@intel.com \
--cc=ray.kinsella@intel.com \
--cc=stable@dpdk.org \
--cc=tiwei.bie@intel.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).