Re: [dpdk-dev] [PATCH] mem: skip memory locking on failure

[Panu Matilainen <pmatilai@redhat.com>]

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@redhat.com>
> Signed-off-by: Olivier Matz <olivier.matz@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 -