From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1134-226.mail.aliyun.com (out1134-226.mail.aliyun.com [42.120.134.226]) by dpdk.org (Postfix) with ESMTP id 1A7B82E89 for ; Mon, 10 Nov 2014 10:51:30 +0100 (CET) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.04369255|-1; FP=0|0|0|0|0|-1|-1|-1; HT=r41g08149; MF=liang.xu@cinfotech.cn; PH=DW; RN=3; RT=3; SR=0; Received: from WS-web (liang.xu@cinfotech.cn[203.110.175.218]) by r41g06011.xy2.aliyun.com at Mon, 10 Nov 2014 18:01:09 +0800 Date: Mon, 10 Nov 2014 18:01:09 +0800 From: "XU Liang" To: "=?UTF-8?B?QnVyYWtvdiwgQW5hdG9seQ==?=" , "dev@dpdk.org" Message-ID: X-Mailer: Alimail-Mailagent revision 2667797 MIME-Version: 1.0 References: <1415417532-4363-1-git-send-email-liang.xu@cinfotech.cn>, C6ECDF3AB251BE4894318F4E4512369780C07DC0@IRSMSX109.ger.corp.intel.com In-Reply-To: C6ECDF3AB251BE4894318F4E4512369780C07DC0@IRSMSX109.ger.corp.intel.com x-aliyun-mail-creator: Webmail4_2670074_M3LTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTBfMSkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzM4LjAuMjEyNS4xMTEgU2FmYXJpLzUzNy4zNg==vN Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] =?utf-8?q?=5BPATCH=5D_eal=3A_map_PCI_memory_resources_?= =?utf-8?q?after_hugepages?= X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: XU Liang List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 09:51:32 -0000 It is a default value when the requested_addr isn't exist, not an overide. Whe= n the=C2=A0pci_map_resource is called at the primary process, the=C2=A0request= ed_addr is NULL. The default value will be provided by=C2=A0default_map_addr.=0A= When the=C2=A0pci_map_resource is called at the secondery process, the=C2=A0re= quested_addr is exist. Then everything isn't be changed.----------------------= --------------------------------------------From:Burakov, Anatoly Time:2014 Nov 10 (Mon) 17 : 54To:=E5=BE=90=E4=BA=AE , dev@dpdk.org Cc:thomas.monjalon@6wind.com Subject:RE: [PATCH] eal: map PCI memory resources after hug= epages=0AHi Liang=0A=0AI don't think that overriding the value passed to pci_m= ap_resource as argument is the way to go. While it results in less code, it lo= oks weird, in my opinion at least, as I believe tracking the correctness of ad= dress 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_ad= dr 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?=0A=0AThank= s,=0AAnatoly=0A=0A-----Original Message-----=0AFrom: Liang Xu [mailto:liang.xu= @cinfotech.cn] =0ASent: Saturday, November 8, 2014 3:32 AM=0ATo: dev@dpdk.org=0A= Cc: Burakov, Anatoly; thomas.monjalon@6wind.com=0ASubject: [PATCH] eal: map PC= I memory resources after hugepages=0A=0AA multiple process DPDK application mu= st mmap hugepages and pci resources into same virtual addresses. By default th= e virtual addresses chosen by the primary process automatically when calling t= he mmap. But sometime the chosen virtual addresses isn't usable at secondary p= rocess. Such as the secondary process linked with more libraries than primary = process. The library has been mapped into this virtual address. The command li= ne parameter 'base-virtaddr' has been added for this situation. If it's config= ured, the hugepages will be mapped into this base address. But the virtual add= ress of pci resources mapped still does not refer to the parameter. In that ca= se "EAL: pci_map_resource(): cannot mmap" =0Awill be got.=0A=0AThis patch try = to map pci resources after hugepages. So the error can be resolved by set base= -virtaddr into free virtual address space.=0A=0ASigned-off-by: Liang Xu =0A---=0A lib/librte_eal/linuxapp/eal/eal_pci.c | 32 ++++++++= +++++++++++++++++++++++-=0A 1 file changed, 31 insertions(+), 1 deletion(-)=0A= =0Adiff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c b/lib/librte_eal/linuxap= p/eal/eal_pci.c=0Aindex ddb0535..502eef2 100644=0A--- a/lib/librte_eal/linuxap= p/eal/eal_pci.c=0A+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c=0A@@ -97,14 +97,= 42 @@ error:=0A return -1;=0A }=0A =0A+static void *=0A+pci_find_max_end_va(v= oid)=0A+{=0A+ const struct rte_memseg *seg =3D rte_eal_get_physmem_layout();=0A= + const struct rte_memseg *last =3D seg;=0A+ unsigned i =3D 0;=0A+=0A+ for (i = =3D 0; i < RTE_MAX_MEMSEG; i++, seg++) {=0A+ if (seg->addr =3D=3D NULL)=0A+ = break;=0A+=0A+ if (seg->addr > last->addr)=0A+ last =3D seg;=0A+=0A+ }=0A+= return RTE_PTR_ADD(last->addr, last->len); }=0A+=0A /* map a particular resou= rce from a file */ void * pci_map_resource(void *requested_addr, int fd, off= _t offset, size_t size) {=0A void *mapaddr;=0A =0A+ /* By default the PCI me= mory resource will be mapped after hugepages */=0A+ static void *default_map_a= ddr;=0A+ if (NULL =3D=3D requested_addr) {=0A+ if (NULL =3D=3D default_map_ad= dr)=0A+ default_map_addr =3D pci_find_max_end_va();=0A+ mapaddr =3D default= _map_addr;=0A+ } else {=0A+ mapaddr =3D requested_addr;=0A+ }=0A+=0A /* M= ap the PCI memory resource of device */=0A- mapaddr =3D mmap(requested_addr, s= ize, PROT_READ | PROT_WRITE,=0A+ mapaddr =3D mmap(mapaddr, size, PROT_READ | P= ROT_WRITE,=0A MAP_SHARED, fd, offset);=0A if (mapaddr =3D=3D MAP_FAILED ||= =0A (requested_addr !=3D NULL && mapaddr !=3D requested_addr)) { @@ -114,6 = +142,8 @@ pci_map_resource(void *requested_addr, int fd, off_t offset, size_t = size)=0A strerror(errno), mapaddr);=0A goto fail;=0A }=0A+ if (NULL =3D=3D= requested_addr)=0A+ default_map_addr =3D RTE_PTR_ADD(mapaddr, size);=0A =0A = RTE_LOG(DEBUG, EAL, " PCI memory mapped at %p\n", mapaddr);=0A =0A--=0A1.9.1 >From thomas.monjalon@6wind.com Mon Nov 10 10:54:11 2014 Return-Path: Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by dpdk.org (Postfix) with ESMTP id C38582E89 for ; Mon, 10 Nov 2014 10:54:11 +0100 (CET) Received: by mail-wi0-f172.google.com with SMTP id bs8so9734150wib.11 for ; Mon, 10 Nov 2014 02:03:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=boS8myAu9T2LhsGLlflh1gTZs6fn3na8zppnVl5Nkt0=; b=IaJOJUS/JrF4U3PkAUw2VydRtST+peS3IpSMmXPLNsuEZYzxeO43UJso5BOmcI/mMq QzHhckAcg6gVVNbR3zSknV5t95rBtKFzqMOBSZkBNp5zx6lraLSV7cOWsxz69QSTn5aa IJScbNMrzQ4oFhnBddxnewYwgjrbYfZCKkMlb1aXAmD0oowSG9fNpwqPNsiBjfKCdIni r1qNErpwflVOVCJD3Cd8Fg/ZEbkrnS0fgSp4bdJqzIDLIYxnlWX/iRhPQ28Er+mIWKUA WdoZgxmnG7FNDPwINoehsEZy2Jk0gj01APXuEO6fotBAxBcy9cgGjNBS0YFnOgefwHtX WKew== X-Gm-Message-State: ALoCoQlQQ/m8Xk75za5kGhi2XnYX3zSCMpPf7ucHc7ycV0rAJmgo0ezWQbkZpGOT69QBzeeh1O1E X-Received: by 10.180.19.164 with SMTP id g4mr28712962wie.51.1415613836517; Mon, 10 Nov 2014 02:03:56 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id hk9sm22516289wjb.46.2014.11.10.02.03.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Nov 2014 02:03:55 -0800 (PST) From: Thomas Monjalon To: "Sujith Sankar (ssujith)" Date: Mon, 10 Nov 2014 11:03:37 +0100 Message-ID: <2661634.q9QAmChB5I@xps13> Organization: 6WIND User-Agent: KMail/4.14.2 (Linux/3.17.2-1-ARCH; KDE/4.14.2; x86_64; ; ) In-Reply-To: References: <1415390747-9532-1-git-send-email-ssujith@cisco.com> <1794590.eegJuKmrRB@xps13> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/7] Cisco Systems Inc. VIC Ethernet PMD - ENIC PMD 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: Mon, 10 Nov 2014 09:54:12 -0000 2014-11-10 09:27, Sujith Sankar: > On 07/11/14 9:17 pm, "Thomas Monjalon" wrote: > >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 the > 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 PMD incompatible. That's why the rule is to base the patches on the latest HEAD. Thanks for your efforts. -- Thomas