From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 871DA7E62 for ; Fri, 24 Oct 2014 13:59:39 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 24 Oct 2014 05:08:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,779,1406617200"; d="scan'208";a="619783980" Received: from bricha3-mobl.ger.corp.intel.com (HELO bricha3-mobl.ir.intel.com) ([10.243.20.25]) by fmsmga002.fm.intel.com with SMTP; 24 Oct 2014 05:08:05 -0700 Received: by bricha3-mobl.ir.intel.com (sSMTP sendmail emulation); Fri, 24 Oct 2014 13:08:04 +0001 Date: Fri, 24 Oct 2014 13:08:04 +0100 From: Bruce Richardson To: Mario Gianni Message-ID: <20141024120803.GA5804@BRICHA3-MOBL> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Cannot mmap device resource in DPDK 1.7.0 multi-process/multi-thread 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: Fri, 24 Oct 2014 11:59:40 -0000 On Fri, Oct 24, 2014 at 01:21:08PM +0200, Mario Gianni wrote: > Hi all, I have a problem since I updated to 1.7.0 version, > I got a multi-process, multi-threaded application, > In my application first I launch a master process, then I launch a secondary process with multiple threads in it > Well, when the number of lcores reserved for the secondary process exceeds a certain number (eg. 4) i got an error in rte_eal_init() on the secondary process when it tries to map PCI memory: > > EAL: pci_map_resource(): cannot mmap(12, 0x7ffff2e96000, 0x800000, 0x1000): Success (0x7ffff559b000) > EAL: Cannot mmap device resource > EAL: Error - exiting with code: 1 > Cause: Requested device 0000:01:00.0 cannot be used > > Can you help me? This could be because the additional memory/stack space used by the pthreads for the cores in the secondary process is overlapping the space used in the primary process for hugepage or device memory. You could perhaps try adding a few cores to the primary process's coremask (and not using those cores) and see if it helps things. Alternatively there is a base-virtaddr parameter that can be passed to the primary process to try and adjust the starting address for it mapping memory. If you look at where it starts mapping memory right now, and then try hinting to it to maps the pages at a slightly higher or lower address and see if it helps. /Bruce