From: Gagandeep Singh <g.singh@nxp.com>
To: dev@dpdk.org, thomas@monjalon.net
Cc: anatoly.burakov@intel.com, olivier.matz@6wind.com,
arybchenko@solarflare.com, Gagandeep Singh <g.singh@nxp.com>,
stable@dpdk.org, Nipun Gupta <nipun.gupta@nxp.com>
Subject: [dpdk-stable] [PATCH v2] eal: change max hugepage sizes to 4 for ARM platforms
Date: Thu, 8 Aug 2019 17:43:20 +0530 [thread overview]
Message-ID: <20190808121320.12253-1-g.singh@nxp.com> (raw)
In-Reply-To: <20190807101204.21614-1-g.singh@nxp.com>
ARM is supporting maximum 4 hugepage sizes (64K, 2M, 32M
and 1G) when granule is 4KB since very long and DPDK
support maximum 3 hugepage sizes.
With all 4 hugepage sizes enabled, applications and some
stacks like VPP which are working over DPDK and using
"in-memory" eal option, or using separate mount points
on ARM based platform, fails at huge page initialization,
reporting error messages from eal:
EAL: FATAL: Cannot get hugepage information.
EAL: Cannot get hugepage information.
EAL: Error - exiting with code: 1
This issue is visible on kernel 5.2 (stable rel), where
kernel is by default creating directories for each supported
hugepage size in /sys/kernel/mm/hugepages/
On earlier Stable Kernel LTR's, the directories visible in
/sys/kernel/mm/hugepages/ were dependent upon what hugepage
sizes are configured at boot time.
This change increases the maximum supported mount points
to 4 for ARM based platforms.
Cc: stable@dpdk.org
Signed-off-by: Gagandeep Singh <g.singh@nxp.com>
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
Changes in V2:
- restricted this change specific to ARM
- commit message updated
- stable added to cc
lib/librte_eal/common/eal_internal_cfg.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/lib/librte_eal/common/eal_internal_cfg.h b/lib/librte_eal/common/eal_internal_cfg.h
index edff09d07..a42f34923 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -15,7 +15,11 @@
#include "eal_thread.h"
+#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
+#define MAX_HUGEPAGE_SIZES 4 /**< support up to 4 page sizes */
+#else
#define MAX_HUGEPAGE_SIZES 3 /**< support up to 3 page sizes */
+#endif
/*
* internal configuration structure for the number, size and
--
2.17.1
next parent reply other threads:[~2019-08-08 12:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190807101204.21614-1-g.singh@nxp.com>
2019-08-08 12:13 ` Gagandeep Singh [this message]
2019-08-08 12:37 ` David Marchand
2019-08-08 15:26 ` Thomas Monjalon
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=20190808121320.12253-1-g.singh@nxp.com \
--to=g.singh@nxp.com \
--cc=anatoly.burakov@intel.com \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=nipun.gupta@nxp.com \
--cc=olivier.matz@6wind.com \
--cc=stable@dpdk.org \
--cc=thomas@monjalon.net \
/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).