From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) by dpdk.org (Postfix) with ESMTP id 89A775921 for ; Thu, 9 Jul 2015 01:18:06 +0200 (CEST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id BCB69C0904EAA; Wed, 8 Jul 2015 23:18:01 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t68NI4IW001198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jul 2015 23:18:04 GMT Received: from US70TWXCHMBA07.zam.alcatel-lucent.com ([169.254.1.180]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Wed, 8 Jul 2015 19:18:04 -0400 From: "Assaad, Sami (Sami)" To: "dev@dpdk.org" , Bruce Richardson Thread-Topic: dev Digest, Vol 45, Issue 9 Thread-Index: AQHQp27noGOwOPbK5k+S0vRJm5IQjZ3SUfyw Date: Wed, 8 Jul 2015 23:18:04 +0000 Message-ID: <9478F0FB69DAA249AF0A9BDA1E6ED95218848877@US70TWXCHMBA07.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] dev Digest, Vol 45, Issue 9 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 23:18:06 -0000 Hello Bruce,=20 As you stated previously, I cannot guarantee the proper mapping of the virt= ual addresses between my primary and secondary processes. I have one primar= y process and up to 42 secondary processes. The application as a whole work= s very well. However, closing the application/restarting it continuously re= sults 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 perma= nently disabled and ran the application. None of the clients (secondary pro= cesses) was able in memory mapping the virtual addresses derived from the p= rimary 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 d= isabled 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 primar= y & secondary processes? An example would help. I am running the primary process with the option --proc-type=3Dprimary and = the 40+ clients with --proc-type=3Dsecondary. - My OS is CentOS6.6 - Using KVM/QEMU - DPDK 1.8.0 - Haswell Thanks in advance! Best Regards, Sami Assaad.=20 =20 -----Original Message----- Message: 2 Date: Mon, 15 Jun 2015 11:21:39 +0100 From: Bruce Richardson To: "Assaad, Sami (Sami)" Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] DPDK and ASLR Message-ID: <20150615102138.GB3872@bricha3-MOBL3> Content-Type: text/plain; charset=3Dus-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 follo= wing: > EAL: WARNING: Address Space Layout Randomization (ASLR) is enabled in the= kernel. > EAL: This may cause issues with mapping memory into secondary proces= ses. >=20 > Our application is DPDK client/server based and runs properly. >=20 > My questions are: >=20 > * 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. Bec= ause of this, you may occasionally get instances where your application fai= ls to run because an essential piece of memory is mapped at address X in th= e primary, while something else is mapped at address X in the secondary pro= cess. How frequently, if ever, this happens will vary from application to a= pplication. If ASLR is disabled, the memory mappings created in the primary and seconda= ry processes will be identical and repeatable from one run to another, so y= ou can know that if a set of processes starts once, it will start a second = time. With ASLR enabled, that guarantee cannot be made. >=20 > * Should ASLR be disabled? >=20 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 mult= i-process run to another, the only way get that - that I am aware of - is t= o 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