DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Assaad, Sami (Sami)" <sami.assaad@alcatel-lucent.com>
To: "dev@dpdk.org" <dev@dpdk.org>,
	Bruce Richardson <bruce.richardson@intel.com>
Subject: Re: [dpdk-dev] dev Digest, Vol 45, Issue 9
Date: Wed, 8 Jul 2015 23:18:04 +0000	[thread overview]
Message-ID: <9478F0FB69DAA249AF0A9BDA1E6ED95218848877@US70TWXCHMBA07.zam.alcatel-lucent.com> (raw)
In-Reply-To: <mailman.29888.1434374782.2363.dev@dpdk.org>

Hello Bruce, 

As you stated previously, I cannot guarantee the proper mapping of the virtual addresses between my primary and secondary processes. I have one primary process and up to 42 secondary processes. The application as a whole works very well. However, closing the application/restarting it continuously results with certain clients (secondary processes) failing to memory map the primary virtual addresses into /dev/zero (fd_zero). [Error "Cound not mmap 8573157376 bytes in /dev/zero to requested address ..."]

So, I disabled ASLR on my virtual machine (VM). Rebooted it with ASLR permanently disabled and ran the application. None of the clients (secondary processes) was able in memory mapping the virtual addresses derived from the primary process. Rte_eal_config_reattach() fails with the error "Cannot mmap memory for rte_config".

My experience with ASLR is limited. Must I rebuild the software with ASLR disabled or am I missing EAL configuration?
How about SELinux - must it be enabled or disabled?
Or ... must I manually configure the virtual addressing for both the primary & secondary processes? An example would help.

I am running the primary process with the option --proc-type=primary and the 40+ clients with --proc-type=secondary.

- My OS is CentOS6.6
- Using KVM/QEMU
- DPDK 1.8.0
- Haswell

Thanks in advance!

Best Regards,
Sami Assaad. 
 

-----Original Message-----

Message: 2
Date: Mon, 15 Jun 2015 11:21:39 +0100
From: Bruce Richardson <bruce.richardson@intel.com>
To: "Assaad, Sami (Sami)" <sami.assaad@alcatel-lucent.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] DPDK and ASLR
Message-ID: <20150615102138.GB3872@bricha3-MOBL3>
Content-Type: text/plain; charset=us-ascii

On Fri, Jun 12, 2015 at 10:53:58PM +0000, Assaad, Sami (Sami) wrote:
> When I operate a DPDK based application, the EAL always reports the following:
> EAL: WARNING: Address Space Layout Randomization (ASLR) is enabled in the kernel.
> EAL:      This may cause issues with mapping memory into secondary processes.
> 
> Our application is DPDK client/server based and runs properly.
> 
> My questions are:
> 
> *         Is this warning of any importance?

Yes, it's there for a reason. With ASLR, the position of the hugepage (and other) memory in your DPDK primary process virtual address space will move about from one run to another, and the same with the secondary process. Because of this, you may occasionally get instances where your application fails to run because an essential piece of memory is mapped at address X in the primary, while something else is mapped at address X in the secondary process. How frequently, if ever, this happens will vary from application to application.

If ASLR is disabled, the memory mappings created in the primary and secondary processes will be identical and repeatable from one run to another, so you can know that if a set of processes starts once, it will start a second time. With ASLR enabled, that guarantee cannot be made.


> 
> *         Should ASLR be disabled?
> 

That is a questions we can't answer for you. ASLR is a security feature in the OS so you should be aware of the implications of disabling it. However, if you need absolute guarantees of repeatabiltiy of mappings from one multi-process run to another, the only way get that - that I am aware of - is to disable ASLR. If an occasional random failure at startup is ok, then ASLR can safely be left on.

> *         Does ASLR affect DPDK performance?

No, it only affects the repeatability of memory mappings at DPDK start-up.

Hope this clarifies things.

/Bruce

       reply	other threads:[~2015-07-08 23:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.29888.1434374782.2363.dev@dpdk.org>
2015-07-08 23:18 ` Assaad, Sami (Sami) [this message]
2015-07-09 10:10   ` Bruce Richardson
2015-07-09 17:27     ` Assaad, Sami (Sami)

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=9478F0FB69DAA249AF0A9BDA1E6ED95218848877@US70TWXCHMBA07.zam.alcatel-lucent.com \
    --to=sami.assaad@alcatel-lucent.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    /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).