From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: lxu <liang.xu@cinfotech.cn>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v5] eal: map uio resources after hugepages when the base_virtaddr is configured.
Date: Thu, 6 Nov 2014 15:41:37 +0000 [thread overview]
Message-ID: <C6ECDF3AB251BE4894318F4E4512369780C07670@IRSMSX109.ger.corp.intel.com> (raw)
In-Reply-To: <1415287928-14513-1-git-send-email-liang.xu@cinfotech.cn>
The explanation of the patch should be generic and impartial, i.e. when this and this happens, it results in such and such problem, and this patch fixes it by doing this and that. In other words, this will appear in the git history, so whoever is reading the commit log will be able to figure out what 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]
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_virtaddr is configured.
Sorry, I'm learning the right way to send a patch by git.
I have a multiple processes application. When start the secondary process, I got error message "EAL: pci_map_resource(): cannot mmap(11, 0x7ffff7fba000, 0x20000, 0x0): Bad file descriptor (0x7ffff7fb9000)".
The secondary process links a lot of additional shared libraries, so the address 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 <liang.xu@cinfotech.cn>
---
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<RTE_MAX_MEMSEG; i++, seg++) {
+ 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);
+ }
+
dev->intr_handle.fd = -1;
dev->intr_handle.type = RTE_INTR_HANDLE_UNKNOWN;
@@ -371,10 +396,12 @@ pci_uio_map_resource(struct rte_pci_device *dev)
if (maps[j].addr != NULL)
fail = 1;
else {
- mapaddr = pci_map_resource(NULL, fd, (off_t)offset,
+ mapaddr = pci_map_resource(requested_addr, fd, (off_t)offset,
(size_t)maps[j].size);
if (mapaddr == NULL)
fail = 1;
+ else if (NULL != requested_addr)
+ requested_addr = RTE_PTR_ADD(mapaddr, maps[j].size);
}
if (fail) {
--
1.9.1
next prev parent reply other threads:[~2014-11-06 15:32 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-05 13:25 [dpdk-dev] [PATCH] " lxu
2014-11-05 15:10 ` Burakov, Anatoly
2014-11-05 15:49 ` [dpdk-dev] 答复: " XU Liang
2014-11-05 15:59 ` Burakov, Anatoly
2014-11-05 16:10 ` [dpdk-dev] 答复:答复: " XU Liang
2014-11-26 1:46 ` Qiu, Michael
2014-11-26 9:58 ` Burakov, Anatoly
2014-11-06 14:11 ` [dpdk-dev] [PATCH v2] " lxu
2014-11-06 14:27 ` Burakov, Anatoly
2014-11-06 14:48 ` [dpdk-dev] 答复:[PATCH " 徐亮
2014-11-06 14:47 ` [dpdk-dev] [PATCH v3] " lxu
2014-11-06 15:06 ` De Lara Guarch, Pablo
2014-11-06 15:07 ` [dpdk-dev] [PATCH v4] " lxu
2014-11-06 15:12 ` Thomas Monjalon
2014-11-06 15:11 ` lxu
2014-11-06 15:32 ` [dpdk-dev] [PATCH v5] " lxu
2014-11-06 15:41 ` Burakov, Anatoly [this message]
2014-11-06 15:58 ` Thomas Monjalon
2014-11-06 16:10 ` Burakov, Anatoly
2014-11-06 17:30 ` Bruce Richardson
2014-11-07 8:01 ` [dpdk-dev] [PATCH v6] " lxu
2014-11-07 9:42 ` Bruce Richardson
2014-11-07 9:47 ` Burakov, Anatoly
2014-11-07 9:57 ` XU Liang
2014-11-07 14:37 ` XU Liang
2014-11-10 11:34 ` [dpdk-dev] [PATCH v7] eal: map PCI memory resources after hugepages Anatoly Burakov
2014-11-10 13:33 ` Burakov, Anatoly
2014-11-11 3:53 ` XU Liang
2014-11-11 10:09 ` [dpdk-dev] [PATCH v8] " Anatoly Burakov
2014-11-13 11:34 ` Burakov, Anatoly
2014-11-13 12:58 ` Bruce Richardson
2014-11-13 13:44 ` Burakov, Anatoly
2014-11-13 13:46 ` Bruce Richardson
2014-11-25 17:17 ` Thomas Monjalon
2014-11-07 14:57 ` [dpdk-dev] [PATCH v7] eal: map uio " lxu
2014-11-07 15:14 ` Burakov, Anatoly
2014-11-07 15:15 ` Thomas Monjalon
2014-11-07 15:19 ` XU Liang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C6ECDF3AB251BE4894318F4E4512369780C07670@IRSMSX109.ger.corp.intel.com \
--to=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=liang.xu@cinfotech.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).