From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 4A8934A6E for ; Fri, 7 Nov 2014 10:33:30 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 07 Nov 2014 01:41:15 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,331,1413270000"; d="scan'208";a="633199191" Received: from bricha3-mobl3.ger.corp.intel.com ([10.243.20.32]) by orsmga002.jf.intel.com with SMTP; 07 Nov 2014 01:42:16 -0800 Received: by (sSMTP sendmail emulation); Fri, 07 Nov 2014 09:42:15 +0025 Date: Fri, 7 Nov 2014 09:42:15 +0000 From: Bruce Richardson To: lxu Message-ID: <20141107094215.GA4628@bricha3-MOBL3> References: <1415193919-17361-1-git-send-email-liang.xu@cinfotech.cn> <1415347284-15468-1-git-send-email-liang.xu@cinfotech.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1415347284-15468-1-git-send-email-liang.xu@cinfotech.cn> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v6] eal: map uio resources after hugepages when the base_virtaddr is configured. 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, 07 Nov 2014 09:33:31 -0000 On Fri, Nov 07, 2014 at 04:01:24PM +0800, lxu wrote: > A multiple process DPDK application must mmap hugepages and pci resource into same virtual addresses. By default the virtual addresses chosen by the primary process automatically when calling the mmap. But sometime the virtual addresses chosen by the primary process isn't usable at secondary process. Such as the secondary process linked with more libraries than primary process. The library has been mapped into this virtual address. The command line parameter 'base-virtaddr' has been added for this situation. If it's configured, the hugepages will be mapped into this base address. But the virtual address of uio resource mapped still does not refer to the parameter. In that case it would still fail. > > This patch try to map uio resources after hugepages when the base_virtaddr is configured. So the error of "EAL: pci_map_resource(): cannot mmap" can be resolved by set base-virtaddr into free virtual address space. > > Signed-off-by: lxu > --- > lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 29 ++++++++++++++++++++++++++++- > 1 file changed, 28 insertions(+), 1 deletion(-) > > diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c > index 7e62266..a2c9ab6 100644 > --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c > +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c > @@ -273,6 +273,24 @@ pci_get_uio_dev(struct rte_pci_device *dev, char *dstbuf, > return uio_num; > } > > +static inline const struct rte_memseg * > +get_physmem_last(void) > +{ > + const struct rte_memseg * seg = rte_eal_get_physmem_layout(); > + const struct rte_memseg * last = seg; > + unsigned i = 0; > + > + for (i=0; i + if (seg->addr == NULL) > + break; > + > + if(seg->addr > last->addr) > + last = seg; > + > + } > + return last; > +} > + > /* map the PCI resource of a PCI device in virtual memory */ > int > pci_uio_map_resource(struct rte_pci_device *dev) > @@ -290,6 +308,13 @@ pci_uio_map_resource(struct rte_pci_device *dev) > struct mapped_pci_resource *uio_res; > struct pci_map *maps; > > + /* map uio resource into user required virtual address */ > + static void * requested_addr; > + if (internal_config.base_virtaddr && NULL == requested_addr) { > + const struct rte_memseg * last = get_physmem_last(); > + requested_addr = RTE_PTR_ADD(last->addr, last->len); > + } > + Could you perhaps take anatoly's suggestion and modify this patch so the checking for a space right after the memsegs does not just depend on base-virtaddr being set. Unless it causes other problems, there is no reason this code should not always be used. /Bruce