From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1134-185.mail.aliyun.com (out1134-185.mail.aliyun.com [42.120.134.185]) by dpdk.org (Postfix) with ESMTP id C72A62E89 for ; Mon, 10 Nov 2014 10:54:51 +0100 (CET) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.0435036|-1; FP=0|0|0|0|0|-1|-1|-1; HT=r46d02009; 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 r41g06012.xy2.aliyun.com at Mon, 10 Nov 2014 18:04:31 +0800 Date: Mon, 10 Nov 2014 18:04:31 +0800 From: "XU Liang" To: "=?UTF-8?B?QnVyYWtvdiwgQW5hdG9seQ==?=" , "dev@dpdk.org" Message-ID: <0940c02e-7bf7-4019-b400-1bd377bc667d@cinfotech.cn> 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, dd048730-152d-4922-9edc-985aa3a6a885@cinfotech.cn In-Reply-To: dd048730-152d-4922-9edc-985aa3a6a885@cinfotech.cn 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:54:53 -0000 Of course you can take this job. Thanks you for your help.--------------------= ----------------------------------------------From:=E5=BE=90=E4=BA=AE Time:2014 Nov 10 (Mon) 18 : 01To:Burakov, Anatoly , dev@dpdk.org Cc:thomas.monjalon@6wind.com Subject:Re: [PATCH] eal: map PCI memory resources after h= ugepages=0AIt is a default value when the requested_addr isn't exist, not an o= veride. When the=C2=A0pci_map_resource is called at the primary process, the=C2= =A0requested_addr is NULL. The default value will be provided by=C2=A0default_= map_addr.=0AWhen the=C2=A0pci_map_resource is called at the secondery process,= the=C2=A0requested_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 resourc= es after hugepages=0AHi Liang=0A=0AI don't think that overriding the value pas= sed 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 corre= ctness 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 requ= ested_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= ?=0A=0AThanks,=0AAnatoly=0A=0A-----Original Message-----=0AFrom: Liang Xu [mai= lto:liang.xu@cinfotech.cn] =0ASent: Saturday, November 8, 2014 3:32 AM=0ATo: d= ev@dpdk.org=0ACc: Burakov, Anatoly; thomas.monjalon@6wind.com=0ASubject: [PATC= H] eal: map PCI memory resources after hugepages=0A=0AA 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 t= he virtual address of pci resources mapped still does not refer to the paramet= er. In that case "EAL: pci_map_resource(): cannot mmap" =0Awill be got.=0A=0AT= his patch try to map pci resources after hugepages. So the error can be resolv= ed by set base-virtaddr into free virtual address space.=0A=0ASigned-off-by: L= iang 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/libr= te_eal/linuxapp/eal/eal_pci.c=0Aindex ddb0535..502eef2 100644=0A--- a/lib/libr= te_eal/linuxapp/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_fin= d_max_end_va(void)=0A+{=0A+ const struct rte_memseg *seg =3D rte_eal_get_physm= em_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 parti= cular resource 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 memory resource will be mapped after hugepages */=0A+ static void *de= fault_map_addr;=0A+ if (NULL =3D=3D requested_addr) {=0A+ if (NULL =3D=3D def= ault_map_addr)=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 /* Map the PCI memory resource of device */=0A- mapaddr =3D mmap(request= ed_addr, size, PROT_READ | PROT_WRITE,=0A+ mapaddr =3D mmap(mapaddr, size, PRO= T_READ | PROT_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 offse= t, 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, si= ze);=0A =0A RTE_LOG(DEBUG, EAL, " PCI memory mapped at %p\n", mapaddr);=0A =0A= --=0A1.9.1 >From ssujith@cisco.com Mon Nov 10 10:57:17 2014 Return-Path: Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by dpdk.org (Postfix) with ESMTP id 44EAC6828 for ; 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; l=774; q=dns/txt; s=iport; t=1415614022; x=1416823622; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uFCpu3xF3k70iotuGG9s8nhdOekv3HF6V7jwnh1pucI=; b=nDLdStQdJC6SKZYRqIVHzP8YPwAkN7ffsBIGOeq7/ByWvV/MITZhBSb+ qj8z3rchoIzb0lU8EbRUukjSB26JgUcegPbi/lyN9l2z2lMangcIPeO8K OaTS6DJ0NfumrNhIl14VUl+YxnLs0UnewvrQiL3EjCutjz+jENvqE4ecV Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFACWNYFStJV2b/2dsb2JhbABbgw6BLQTTRAKBJRYBAQEBAX2EAwEBBHkQAgEIRjIlAgQOBYhBzhMBAQEBAQEBAQEBAQEBAQEBAQEBGZEVB4RLAQSLRoZri3SBNJEihAqDemyBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.07,351,1413244800"; d="scan'208";a="95059985" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) 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 [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id sAAA71SJ000931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Nov 2014 10:07:01 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.60]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 04:07:01 -0600 From: "Sujith Sankar (ssujith)" To: Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH 0/7] Cisco Systems Inc. VIC Ethernet PMD - ENIC PMD Thread-Index: AQHP+na8i7p0q5/9ukKS4GqBREUQP5xVs+WAgASpMAD//63DgIAAXSuA Date: Mon, 10 Nov 2014 10:07:00 +0000 Message-ID: References: <1415390747-9532-1-git-send-email-ssujith@cisco.com> <1794590.eegJuKmrRB@xps13> <2661634.q9QAmChB5I@xps13> In-Reply-To: <2661634.q9QAmChB5I@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.127.148.111] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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:57:17 -0000 Thanks for the clear response. I=B9ll take a look at it. Regards, -Sujith On 10/11/14 3:33 pm, "Thomas Monjalon" wrote: >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? >>=20 >> 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. >--=20 >Thomas