From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from serv108.segi.ulg.ac.be (serv108.segi.ulg.ac.be [139.165.32.111]) by dpdk.org (Postfix) with ESMTP id 998721094 for ; Thu, 6 Jul 2017 10:06:23 +0200 (CEST) Received: from mbx12-zne.ulg.ac.be (serv470.segi.ulg.ac.be [139.165.32.199]) by serv108.segi.ulg.ac.be (Postfix) with ESMTP id 38202200F490; Thu, 6 Jul 2017 10:06:23 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mbx12-zne.ulg.ac.be (Postfix) with ESMTP id 0F752129E69D; Thu, 6 Jul 2017 10:06:23 +0200 (CEST) Received: from mbx12-zne.ulg.ac.be ([127.0.0.1]) by localhost (mbx12-zne.ulg.ac.be [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Tnpy1zaPoroN; Thu, 6 Jul 2017 10:06:22 +0200 (CEST) Received: from mbx12-zne.ulg.ac.be (mbx12-zne.ulg.ac.be [139.165.32.199]) by mbx12-zne.ulg.ac.be (Postfix) with ESMTP id D61B4129E568; Thu, 6 Jul 2017 10:06:22 +0200 (CEST) Date: Thu, 6 Jul 2017 10:06:22 +0200 (CEST) From: tom.barbette@ulg.ac.be To: "Tan, Jianfeng" Cc: users@dpdk.org, "Gonzalez Monroy, Sergio" Message-ID: <249213765.27102242.1499328382234.JavaMail.zimbra@ulg.ac.be> In-Reply-To: References: <557033961.26868949.1499263069750.JavaMail.zimbra@ulg.ac.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [109.88.217.64] X-Mailer: Zimbra 8.7.1_GA_1670 (ZimbraWebClient - GC59 (Win)/8.7.1_GA_1670) Thread-Topic: Secondary process try to map hugepage even with --no-huge Thread-Index: AdL2AgEZNQffA9qsR1GssFxOt4tCWOMS36Si Subject: Re: [dpdk-users] Secondary process try to map hugepage even with --no-huge X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 08:06:23 -0000 Thanks for your prompt answer. Are there any plan to change that behavior, = like using shm memory if no-huge is there? As I said, this would be very us= eful for testing. Thanks, Tom ----- Mail original ----- > De: "Tan, Jianfeng" > =C3=80: "tom barbette" , users@dpdk.org > Cc: "Gonzalez Monroy, Sergio" > Envoy=C3=A9: Jeudi 6 Juillet 2017 04:46:02 > Objet: RE: [dpdk-users] Secondary process try to map hugepage even with= =09--no-huge > Hi, >=20 >> -----Original Message----- >> From: users [mailto:users-bounces@dpdk.org] On Behalf Of >> tom.barbette@ulg.ac.be >> Sent: Wednesday, July 5, 2017 9:58 PM >> To: users@dpdk.org >> Cc: Gonzalez Monroy, Sergio >> Subject: [dpdk-users] Secondary process try to map hugepage even with -- >> no-huge >>=20 >> Hi list, >>=20 >> I've got a primary/secondary application that works with huge pages enab= led >> but not with "--no-huge". The secondary application try to >> access .rte_hugepage_info no matter the "--no-huge" being passed to both >> master and slave. >=20 > So far if --no-huge is used, we are mmap anonymous memory, which makes it= not > possible to share the memory with secondary (always refer to a config fil= e, > open and mmap to the same addr). >=20 > And we did not write anything into config file if we use --no-huge. This = is a > limitation for now. >=20 >>=20 >> This is especially important for functional regression test where I cann= ot use >> huge pages or sudo (like Travis, Gitlab CI, ...) >>=20 >> Trying with the simple_mp example : >> ./simple_mp --no-huge -m 128MB --proc-type=3Dsecondary -- >> EAL: Detected 8 lcore(s) >> EAL: Probing VFIO support... >> EAL: Could not mmap /home/tom/.rte_hugepage_info >> PANIC in rte_eal_init(): >> Cannot init memory >> 6: [./simple_mp(_start+0x2a) [0x43512a]] >> 5: [/lib64/libc.so.6(__libc_start_main+0xf1) [0x7ffff6ed4401]] >> 4: [./simple_mp(main+0x6) [0x4347b6]] >> 3: [./simple_mp(rte_eal_init+0xe90) [0x46e2d0]] >> 2: [./simple_mp(__rte_panic+0xbe) [0x4301ab]] >> 1: [./simple_mp(rte_dump_stack+0x16) [0x475c06]] >> zsh: abort (core dumped) ./simple_mp --no-huge --proc-type=3Dsecondary = -- >>=20 >>=20 >> With sudo, I get a little further, I guess this is not the problem. >> EAL: Could not mmap /dev/hugepages/rtemap_53 >> PANIC in rte_eal_init(): >>=20 >> Thanks, >>=20 > > Tom