On 06/13/2016 01:26 PM, Olivier Matz wrote:
> Since recently [1], it is not possible to run the dpdk with user
> (non-root) privileges and the --no-huge option. This is because the eal
> layer tries to lock the memory. Using locked memory is mandatory for
> physical devices because they reference physical addresses.
>
> But a user may want to start the dpdk without locked memory, because he
> does not have the permission to do so, and/or does not have this need.
>
> Moreover, the option --no-huge is still not functional today since the
> physical memory address is not properly filled, so the initial patch is
> not really useful.
>
> This commit fixes this issue by retrying the mmap() wihout the
> MAP_LOCKED flag if the first mmap() failed.
>
> [1] http://www.dpdk.org/ml/archives/dev/2016-May/039404.html
>
> Fixes: 593a084afc2b ("mem: lock pages when not using hugepages")
> Reported-by: Panu Matilainen <pmatilai at redhat.com>
> Signed-off-by: Olivier Matz <olivier.matz at 6wind.com>
> ---
> lib/librte_eal/linuxapp/eal/eal_memory.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
> b/lib/librte_eal/linuxapp/eal/eal_memory.c
> index 79d1d2d..08692d1 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_memory.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
> @@ -1075,6 +1075,15 @@ rte_eal_hugepage_init(void)
> if (internal_config.no_hugetlbfs) {
> addr = mmap(NULL, internal_config.memory, PROT_READ |
> PROT_WRITE,
> MAP_LOCKED | MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
> + /* retry without MAP_LOCKED */
> + if (addr == MAP_FAILED && errno == EAGAIN) {
> + addr = mmap(NULL, internal_config.memory,
> + PROT_READ | PROT_WRITE,
> + MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
> + if (addr != MAP_FAILED)
> + RTE_LOG(NOTICE, EAL,
> + "Cannot lock memory: don't use physical
> devices\n");
> + }
> if (addr == MAP_FAILED) {
> RTE_LOG(ERR, EAL, "%s: mmap() failed: %s\n", __func__,
> strerror(errno));
>
I'm not really that familiar with dpdk memory usage, but gut feeling
says such a thing needs to be explicit - either you explicitly ask for
memory that doesn't need to be locked, or this simply fails with no
retries. Or something like that. But "maybe I did, maybe I didn't"
doesn't seem like very good API semantics to me :)
Are there actual plans to make --no-huge work with real devices? If not
then documenting --no-huge to imply unlocked memory is one option I guess.
- Panu -
- Panu -
