DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Liang Xu <liang.xu@cinfotech.cn>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] eal: map PCI memory resources after hugepages
Date: Mon, 10 Nov 2014 09:53:22 +0000	[thread overview]
Message-ID: <C6ECDF3AB251BE4894318F4E4512369780C07DC0@IRSMSX109.ger.corp.intel.com> (raw)
In-Reply-To: <1415417532-4363-1-git-send-email-liang.xu@cinfotech.cn>

Hi Liang

I don't think that overriding the value passed to pci_map_resource as argument is the way to go. While it results in less code, it looks weird, in my opinion at least, as I believe tracking the correctness of address being requested should be the responsibility of the caller, i.e. either UIO or VFIO code. Which is why I keep insisting that you make requested_pci_addr global to linuxapp EAL PCI section and put it into include/eal_pci_init.h. Would you mind if I made a patch for this issue based on your code?

Thanks,
Anatoly

-----Original Message-----
From: Liang Xu [mailto:liang.xu@cinfotech.cn] 
Sent: Saturday, November 8, 2014 3:32 AM
To: dev@dpdk.org
Cc: Burakov, Anatoly; thomas.monjalon@6wind.com
Subject: [PATCH] eal: map PCI memory resources after hugepages

A multiple process DPDK application must mmap hugepages and pci resources into same virtual addresses. By default the virtual addresses chosen by the primary process automatically when calling the mmap. But sometime the chosen virtual addresses 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 pci resources mapped still does not refer to the parameter. In that case "EAL: pci_map_resource(): cannot mmap" 
will be got.

This patch try to map pci resources after hugepages. So the error can be resolved by set base-virtaddr into free virtual address space.

Signed-off-by: Liang Xu <liang.xu@cinfotech.cn>
---
 lib/librte_eal/linuxapp/eal/eal_pci.c | 32 +++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c b/lib/librte_eal/linuxapp/eal/eal_pci.c
index ddb0535..502eef2 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -97,14 +97,42 @@ error:
 	return -1;
 }
 
+static void *
+pci_find_max_end_va(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 RTE_PTR_ADD(last->addr, last->len); }
+
 /* map a particular resource from a file */  void *  pci_map_resource(void *requested_addr, int fd, off_t offset, size_t size)  {
 	void *mapaddr;
 
+	/* By default the PCI memory resource will be mapped after hugepages */
+	static void *default_map_addr;
+	if (NULL == requested_addr) {
+		if (NULL == default_map_addr)
+			default_map_addr = pci_find_max_end_va();
+		mapaddr = default_map_addr;
+	} else {
+	    mapaddr = requested_addr;
+	}
+
 	/* Map the PCI memory resource of device */
-	mapaddr = mmap(requested_addr, size, PROT_READ | PROT_WRITE,
+	mapaddr = mmap(mapaddr, size, PROT_READ | PROT_WRITE,
 			MAP_SHARED, fd, offset);
 	if (mapaddr == MAP_FAILED ||
 			(requested_addr != NULL && mapaddr != requested_addr)) { @@ -114,6 +142,8 @@ pci_map_resource(void *requested_addr, int fd, off_t offset, size_t size)
 			strerror(errno), mapaddr);
 		goto fail;
 	}
+	if (NULL == requested_addr)
+		default_map_addr = RTE_PTR_ADD(mapaddr, size);
 
 	RTE_LOG(DEBUG, EAL, "  PCI memory mapped at %p\n", mapaddr);
 
--
1.9.1

  reply	other threads:[~2014-11-10  9:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-08  3:32 Liang Xu
2014-11-10  9:53 ` Burakov, Anatoly [this message]
2014-11-10 10:01 ` XU Liang
2014-11-10 10:04 ` XU Liang
2014-11-10 11:16 ` 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=C6ECDF3AB251BE4894318F4E4512369780C07DC0@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).