DPDK patches and discussions
 help / color / mirror / Atom feed
From: "XU Liang" <liang.xu@cinfotech.cn>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] eal: map PCI memory resources after hugepages
Date: Mon, 10 Nov 2014 18:04:31 +0800
Message-ID: <0940c02e-7bf7-4019-b400-1bd377bc667d@cinfotech.cn> (raw)
In-Reply-To: dd048730-152d-4922-9edc-985aa3a6a885@cinfotech.cn

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 8520 bytes --]

Of course you can take this job. Thanks you for your help.------------------------------------------------------------------From:徐亮 <liang.xu@cinfotech.cn>Time:2014 Nov 10 (Mon) 18 : 01To:Burakov, Anatoly <anatoly.burakov@intel.com>, dev@dpdk.org <dev@dpdk.org>Cc:thomas.monjalon@6wind.com <thomas.monjalon@6wind.com>Subject:Re: [PATCH] eal: map PCI memory resources after hugepages
It is a default value when the requested_addr isn't exist, not an overide. When the pci_map_resource is called at the primary process, the requested_addr is NULL. The default value will be provided by default_map_addr.
When the pci_map_resource is called at the secondery process, the requested_addr is exist. Then everything isn't be changed.------------------------------------------------------------------From:Burakov, Anatoly <anatoly.burakov@intel.com>Time:2014 Nov 10 (Mon) 17 : 54To:徐亮 <liang.xu@cinfotech.cn>, dev@dpdk.org <dev@dpdk.org>Cc:thomas.monjalon@6wind.com <thomas.monjalon@6wind.com>Subject:RE: [PATCH] eal: map PCI memory resources after hugepages
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?


-----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 *
+	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);
From ssujith@cisco.com  Mon Nov 10 10:57:17 2014
Return-Path: <ssujith@cisco.com>
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [])
 by dpdk.org (Postfix) with ESMTP id 44EAC6828
 for <dev@dpdk.org>; Mon, 10 Nov 2014 10:57:17 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
 d=cisco.com; i=@cisco.com; lw4; q=dns/txt; s=iport;
 t\x1415614022; x\x1416823622;
 in-reply-to:content-id:content-transfer-encoding: mime-version;
 OaTS6DJ0NfumrNhIl14VUl+YxnLs0UnewvrQiL3EjCutjz+jENvqE4ecV Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.07,351,1413244800"; d="scan'208";a="95059985"
Received: from rcdn-core-4.cisco.com ([])
 by alln-iport-3.cisco.com with ESMTP; 10 Nov 2014 10:07:01 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [])
 by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sAAA71SJ000931
 (version=TLSv1/SSLv3 cipher®S128-SHA bits\x128 verifyúIL);
 Mon, 10 Nov 2014 10:07:01 GMT
Received: from xmb-aln-x07.cisco.com ([]) by xhc-rcd-x04.cisco.com
 ([fe80::200:5efe:]) with mapi id 14.03.0195.001;
 Mon, 10 Nov 2014 04:07:01 -0600
From: "Sujith Sankar (ssujith)" <ssujith@cisco.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Thread-Topic: [dpdk-dev] [PATCH 0/7] Cisco Systems Inc. VIC Ethernet PMD -
Thread-Index: AQHP+na8i7p0q5/9ukKS4GqBREUQP5xVs+WAgASpMAD//63DgIAAXSuA
Date: Mon, 10 Nov 2014 10:07:00 +0000
Message-ID: <D0868BD9.27351%ssujith@cisco.com>
References: <1415390747-9532-1-git-send-email-ssujith@cisco.com>
 <1794590.eegJuKmrRB@xps13> <D08682B4.27321%ssujith@cisco.com>
In-Reply-To: <2661634.q9QAmChB5I@xps13>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <DF103A805D2A6C4AAA21BFAEF841F571@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 0/7] Cisco Systems Inc. VIC Ethernet PMD -
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
X-List-Received-Date: Mon, 10 Nov 2014 09:57:17 -0000

Thanks for the clear response.  I¹ll take a look at it.


On 10/11/14 3:33 pm, "Thomas Monjalon" <thomas.monjalon@6wind.com> wrote:

>2014-11-10 09:27, Sujith Sankar:
>> On 07/11/14 9:17 pm, "Thomas Monjalon" <thomas.monjalon@6wind.com>
>> >It seems that this PMD is based on DPDK 1.7.
>> >Could you rebase it on HEAD?
>> This patch is based on 1.7.1.  Thought that is the latest.  And I got
>> diff from origin.
>> What made you feel that the patch is from 1.7?
>By saying 1.7, I meant 1.7.0 or 1.7.1.
>In current HEAD (future 1.8.0), there is a lot of changes which make your
>incompatible. That's why the rule is to base the patches on the latest
>Thanks for your efforts.

  parent reply	other threads:[~2014-11-10  9:54 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
2014-11-10 10:01 ` XU Liang
2014-11-10 10:04 ` XU Liang [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0940c02e-7bf7-4019-b400-1bd377bc667d@cinfotech.cn \
    --to=liang.xu@cinfotech.cn \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git