From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id CD6527F18 for ; Thu, 6 Nov 2014 16:32:12 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 06 Nov 2014 07:41:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,326,1413270000"; d="scan'208";a="632689354" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga002.jf.intel.com with ESMTP; 06 Nov 2014 07:41:38 -0800 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.101]) by IRSMSX104.ger.corp.intel.com ([169.254.5.58]) with mapi id 14.03.0195.001; Thu, 6 Nov 2014 15:41:38 +0000 From: "Burakov, Anatoly" To: lxu , "dev@dpdk.org" Thread-Topic: [PATCH v5] eal: map uio resources after hugepages when the base_virtaddr is configured. Thread-Index: AQHP+dcGdG2T5nOWEkiCOSTResgRgJxTupOw Date: Thu, 6 Nov 2014 15:41:37 +0000 Message-ID: References: <1415193919-17361-1-git-send-email-liang.xu@cinfotech.cn> <1415287928-14513-1-git-send-email-liang.xu@cinfotech.cn> In-Reply-To: <1415287928-14513-1-git-send-email-liang.xu@cinfotech.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v5] 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: Thu, 06 Nov 2014 15:32:13 -0000 The explanation of the patch should be generic and impartial, i.e. when thi= s and this happens, it results in such and such problem, and this patch fix= es it by doing this and that. In other words, this will appear in the git h= istory, so whoever is reading the commit log will be able to figure out wha= t this patch does and why it's been applied. Thomas, do we need to do similar changes to VFIO code, to keep consistency?= Also, do we really need for this to depend on --base-virtaddr? Why not do = it unconditionally, i.e. map PCI resources right after hugepages in memory? Thanks, Anatoly -----Original Message----- From: lxu [mailto:liang.xu@cinfotech.cn]=20 Sent: Thursday, November 6, 2014 3:32 PM To: dev@dpdk.org Cc: Burakov, Anatoly; thomas.monjalon@6wind.com; De Lara Guarch, Pablo Subject: [PATCH v5] eal: map uio resources after hugepages when the base_vi= rtaddr is configured. Sorry, I'm learning the right way to send a patch by git.=20 I have a multiple processes application. When start the secondary process, = I got error message "EAL: pci_map_resource(): cannot mmap(11, 0x7ffff7fba00= 0, 0x20000, 0x0): Bad file descriptor (0x7ffff7fb9000)". The secondary process links a lot of additional shared libraries, so the ad= dress 0x7ffff7fba000 had already be used. I had fixed similar hugepages mmap problems by base_virtaddr. So I believe = the uio resource should be mapped into base_virtaddr at this situation. This patch try to fix it. 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/lin= uxapp/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 *dstb= uf, return uio_num; } =20 +static inline const struct rte_memseg * +get_physmem_last(void) +{ + const struct rte_memseg * seg =3D rte_eal_get_physmem_layout(); + const struct rte_memseg * last =3D seg; + unsigned i =3D 0; + + for (i=3D0; iaddr =3D=3D NULL) + break; + + if(seg->addr > last->addr) + last =3D 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; =20 + /* map uio resource into user required virtual address */ + static void * requested_addr; + if (internal_config.base_virtaddr && NULL =3D=3D requested_addr) { + const struct rte_memseg * last =3D get_physmem_last(); + requested_addr =3D RTE_PTR_ADD(last->addr, last->len); + } + dev->intr_handle.fd =3D -1; dev->intr_handle.type =3D RTE_INTR_HANDLE_UNKNOWN; =20 @@ -371,10 +396,12 @@ pci_uio_map_resource(struct rte_pci_device *dev) if (maps[j].addr !=3D NULL) fail =3D 1; else { - mapaddr =3D pci_map_resource(NULL, fd, (off_t)offset, + mapaddr =3D pci_map_resource(requested_addr, fd, (off_t)offset, (size_t)maps[j].size); if (mapaddr =3D=3D NULL) fail =3D 1; + else if (NULL !=3D requested_addr) + requested_addr =3D RTE_PTR_ADD(mapaddr, maps[j].size); } =20 if (fail) { -- 1.9.1