DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Qiu, Michael" <michael.qiu@intel.com>
To: XU Liang <liang.xu@cinfotech.cn>,
	"Burakov, Anatoly" <anatoly.burakov@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] 答复:答复: [PATCH] eal: map uio resources after hugepages when the	base_virtaddr is configured.
Date: Wed, 26 Nov 2014 01:46:58 +0000
Message-ID: <533710CFB86FA344BFBF2D6802E60286C9A738@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <7600981e-fc3a-454b-a269-51dd3b9d535b@cinfotech.cn>

On 11/6/2014 12:12 AM, XU Liang wrote:
> I have a multiple processes application. When start a secondary process, we got error message "EAL: pci_map_resource(): cannot mmap(11, 0x7ffff7fba000, 0x20000, 0x0): Bad file descriptor (0x7ffff7fb9000)".The secondary process link difference shared libraries, so the address 0x7ffff7fba000 is used.

This is a known issue, and still not be solved yet.  The root cause is
exactly clear, that should be try to map an address have already used in
new process.

BTW, you should learn how to make a patch, like commit log,
signed-off-by, etc.

Thanks,
Michael

> ------------------------------------------------------------------发件人:Burakov, Anatoly <anatoly.burakov@intel.com>发送时间:2014年11月5日(星期三) 23:59收件人:徐亮 <liang.xu@cinfotech.cn>,dev@dpdk.org <dev@dpdk.org>主 题:RE: 答复:[dpdk-dev] [PATCH] eal: map uio resources after hugepages when the	base_virtaddr is configured.
>
>
>
> font-family: MS Gothic;panose-1: 2 11 6 9 7 2 5 8 2 4;font-family: Cambria Math;panose-1: 2 4 5 3 5 4 6 3 2 4;font-family: Calibri;panose-1: 2 15 5 2 2 2 4 3 2 4;font-family: Tahoma;panose-1: 2 11 6 4 3 5 4 4 2 4;font-family: \@MS Gothic;panose-1: 2 11 6 9 7 2 5 8 2 4;font-family: Microsoft JhengHei;panose-1: 2 11 6 4 3 5 4 4 2 4;font-family: \@Microsoft JhengHei;panose-1: 2 11 6 4 3 5 4 4 2 4;p.MsoNormal, li.MsoNormal, div.MsoNormal {margin: 0.0cm;margin-bottom: 1.0E-4pt;font-size: 12.0pt;font-family: Times New Roman , serif;}
> a:link, span.MsoHyperlink {mso-style-priority: 99;color: #0563c1;text-decoration: underline;}
> a:visited, span.MsoHyperlinkFollowed {mso-style-priority: 99;color: #954f72;text-decoration: underline;}
> span.EmailStyle17 {mso-style-type: personal-reply;font-family: Calibri , sans-serif;color: #1f497d;}
> *.MsoChpDefault {mso-style-type: export-only;font-family: Calibri , sans-serif;}
> size: 612.0pt 792.0pt;margin: 72.0pt 72.0pt 72.0pt 72.0pt;div.WordSection1 {page: WordSection1;}
>
>
>
>
> Hi Liang
>  
> Yes it is a problem. Even if it was carefully selected by user, nothing stops the DPDK application from mapping something into where you’re trying to map your
>  UIO devices. Plus, this changes the default behavior where a wrong base-virtaddr leads to a failure to initialize, rather than simply using a different address (remember that pci_map_resource fails if it cannot map the resource at the exact address you requested).
>  
> A very crude way of finding out where hugepages end would be to walk the hugepage memory (walk through memsegs and note the maximum start addr + length of that
>  memseg).
>  
> Could you perhaps explain what is the problem that you’re trying to solve with this? I can’t think of a situation where the location of UIO maps would matter,
>  to be honest.
>  
> Thanks,
> Anatoly
>  
> From: XU Liang [mailto:liang.xu@cinfotech.cn]
>
>
> Sent: Wednesday, November 5, 2014 3:49 PM
>
> To: Burakov, Anatoly; dev@dpdk.org
>
> Subject: 答复:[dpdk-dev] [PATCH] eal: map uio resources after hugepages when the base_virtaddr is configured.
>  
>
>
> I think the base_virtadd will be carefully selected by user when they need it. So maybe it's not a real problem.  :>
>
>
>  
>
>
> The real reason is I can't find a easy way to get the end address of hugepages. Can you give me some suggestions ?
>
>
>
> ------------------------------------------------------------------
>
>
> 发件人:Burakov, Anatoly <anatoly.burakov@intel.com>
>
>
> 发送时间:2014年11月5日(星期三)
>  23:10
>
>
> 收件人:徐亮 <liang.xu@cinfotech.cn>,dev@dpdk.org
>  <dev@dpdk.org>
>
>
> 主 题:RE:
>  [dpdk-dev] [PATCH] eal: map uio resources after hugepages when the base_virtaddr is configured.
>
>
>  
>
> I have a slight problems with this patch.
>
>
>
> The base_virtaddr doesn't necessarily correspond to an address that everything gets mapped to. It's a "hint" of sorts, that may or may not be taken into account by mmap. Therefore we can't simply assume that if we requested a base-virtaddr, everything will
>  get mapped at exactly that address. We also can't assume that hugepages will be ordered one after the other and occupy neatly all the contiguous virtual memory between base_virtaddr and base_virtaddr + internal_config.memory - there may be holes, for whatever
>  reasons.
>
>
>
> Also, 
>
>
>
> Thanks,
>
> Anatoly
>
>
>
> -----Original Message-----
>
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of lxu
>
> Sent: Wednesday, November 5, 2014 1:25 PM
>
> To: dev@dpdk.org
>
> Subject: [dpdk-dev] [PATCH] eal: map uio resources after hugepages when the base_virtaddr is configured.
>
>
>
> ---
>
> lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 9 ++++++++-
>
> 1 file changed, 8 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..bc7ed3a 100644
>
> --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
>
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
>
> @@ -289,6 +289,11 @@ pci_uio_map_resource(struct rte_pci_device *dev)
>
> struct rte_pci_addr *loc = &dev->addr;
>
> struct mapped_pci_resource *uio_res;
>
> struct pci_map *maps;
>
> + static void * requested_addr = NULL;
>
> + if (internal_config.base_virtaddr && NULL == requested_addr) {
>
> + requested_addr = (uint8_t *) internal_config.base_virtaddr 
>
> + + internal_config.memory;
>
> + }
>
>
>
> dev->intr_handle.fd = -1;
>
> dev->intr_handle.type = RTE_INTR_HANDLE_UNKNOWN; @@ -371,10 +376,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 = (uint8_t *)mapaddr + maps[j].size;
>
> }
>
>
>
> if (fail) {
>
> --
>
> 1.9.1
>
>
>
>


  reply	other threads:[~2014-11-26  1:36 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-05 13:25 [dpdk-dev] " 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 [this message]
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
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=533710CFB86FA344BFBF2D6802E60286C9A738@SHSMSX101.ccr.corp.intel.com \
    --to=michael.qiu@intel.com \
    --cc=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

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 \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


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