From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 9ED7B2C6A for ; Tue, 11 Jul 2017 13:35:42 +0200 (CEST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP; 11 Jul 2017 04:35:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,346,1496127600"; d="scan'208";a="125125157" Received: from smonroyx-mobl.ger.corp.intel.com (HELO [10.237.221.5]) ([10.237.221.5]) by fmsmga005.fm.intel.com with ESMTP; 11 Jul 2017 04:35:40 -0700 To: "Tan, Jianfeng" , Stephen Hemminger , "dev@dpdk.org" References: <20170711011242.4606-1-stephen@networkplumber.org> From: Sergio Gonzalez Monroy Message-ID: <3f48cbd3-1e60-5a92-3929-7ba06e3cc69c@intel.com> Date: Tue, 11 Jul 2017 12:35:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC] pci: force address of mappings in secondary process X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 11:35:43 -0000 On 11/07/2017 02:56, Tan, Jianfeng wrote: >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen >> Hemminger >> Sent: Tuesday, July 11, 2017 9:13 AM >> To: dev@dpdk.org >> Cc: Stephen Hemminger >> Subject: [dpdk-dev] [RFC] pci: force address of mappings in secondary >> process >> >> The PCI memory resources in the secondary process should be in >> the exact same location as the primary process. Otherwise >> there is a risk of a stray pointer. >> >> Not sure if this is right, but it looks like a potential >> problem. >> >> --- >> lib/librte_eal/common/eal_common_pci_uio.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/lib/librte_eal/common/eal_common_pci_uio.c >> b/lib/librte_eal/common/eal_common_pci_uio.c >> index 367a6816dcb8..2156b1a436c4 100644 >> --- a/lib/librte_eal/common/eal_common_pci_uio.c >> +++ b/lib/librte_eal/common/eal_common_pci_uio.c >> @@ -77,7 +77,7 @@ pci_uio_map_secondary(struct rte_pci_device *dev) >> >> void *mapaddr = pci_map_resource(uio_res- >>> maps[i].addr, >> fd, (off_t)uio_res->maps[i].offset, >> - (size_t)uio_res->maps[i].size, 0); >> + (size_t)uio_res->maps[i].size, >> MAP_FIXED); >> /* fd is not needed in slave process, close it */ >> close(fd); >> if (mapaddr != uio_res->maps[i].addr) { >> -- >> 2.11.0 > +1 for this RFC. I also once encounter such problem, and I use the same way to solve it. The addr parameter of mmap() syscall is only a hint instead of a must even the VMA is not occupied yet. > > Thanks, > Jianfeng How do you know the VMA is not occupied? I think the risk here is that the dynamic linker loaded some shared library in that VMA, and forcing MAP_FIXED is not a safe solution. What I have observed is that Linux will return a different VMA than the one hinted when there is already a mapping in the requested/hinted VMA. I reckon this is a similar issue as we have with the multi-process model when we do not get the VMA requested for the huge-pages. AFAIK we do not have a robust solution for this issue other than restart the program and hope the dynamic linker does not map anything in the VMA ranges that we need to map from the primary. This is also assuming that the application does not allocate memory and maps things before calling eal_init as it could potentially use VMA ranges that we need in the secondary process. The proposal for new secondary process model would solve these issues: http://dpdk.org/ml/archives/dev/2017-May/066147.html Thanks, Sergio