From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1134-235.mail.aliyun.com (out1134-235.mail.aliyun.com [42.120.134.235]) by dpdk.org (Postfix) with ESMTP id D3EE46828 for ; Mon, 10 Nov 2014 12:06:20 +0100 (CET) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.04343338|-1; FP=0|0|0|0|0|-1|-1|-1; HT=r41g08147; MF=liang.xu@cinfotech.cn; PH=DW; RN=2; RT=2; SR=0; Received: from WS-web (liang.xu@cinfotech.cn[101.80.148.191]) by r41g08156.xy2.aliyun.com at Mon, 10 Nov 2014 19:16:03 +0800 Date: Mon, 10 Nov 2014 19:16:03 +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, dd048730-152d-4922-9edc-985aa3a6a885@cinfotech.cn, 0940c02e-7bf7-4019-b400-1bd377bc667d@cinfotech.cn In-Reply-To: 0940c02e-7bf7-4019-b400-1bd377bc667d@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 11:06:24 -0000 By the way, the=C2=A0pci_map_resource will check the mapaddr =3D=3D=C2=A0reque= sted_addr. So you must provide a usable=C2=A0requested_addr. It's a reason I m= odified the=C2=A0pci_map_resource().------------------------------------------= ------------------------From:=E5=BE=90=E4=BA=AE Time:20= 14 Nov 10 (Mon) 18 : 04To:Burakov, Anatoly , dev@dp= dk.org Subject:Re: [dpdk-dev] [PATCH] eal: map PCI memory resour= ces after hugepages=0AOf course you can take this job. Thanks you for your hel= p.------------------------------------------------------------------From:=E5=BE= =90=E4=BA=AE Time:2014 Nov 10 (Mon) 18 : 01To:Burakov, = Anatoly , dev@dpdk.org Cc:thomas.monj= alon@6wind.com Subject:Re: [PATCH] eal: map PCI mem= ory resources after hugepages=0AIt is a default value when the requested_addr = isn't exist, not an overide. When the=C2=A0pci_map_resource is called at the p= rimary process, the=C2=A0requested_addr is NULL. The default value will be pro= vided 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 : 5= 4To:=E5=BE=90=E4=BA=AE , dev@dpdk.org Cc:= thomas.monjalon@6wind.com Subject:RE: [PATCH] eal: = map PCI memory resources after hugepages=0AHi Liang=0A=0AI don't think that ov= erriding the value passed to pci_map_resource as argument is the way to go. Wh= ile it results in less code, it looks weird, in my opinion at least, as I beli= eve tracking the correctness of address being requested should be the responsi= bility of the caller, i.e. either UIO or VFIO code. Which is why I keep insist= ing that you make requested_pci_addr global to linuxapp EAL PCI section and pu= t it into include/eal_pci_init.h. Would you mind if I made a patch for this is= sue based on your code?=0A=0AThanks,=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=0ACc: Burakov, Anatoly; thomas.monjalon@6win= d.com=0ASubject: [PATCH] eal: map PCI memory resources after hugepages=0A=0AA = multiple process DPDK application must mmap hugepages and pci resources into s= ame virtual addresses. By default the virtual addresses chosen by the primary = process automatically when calling the mmap. But sometime the chosen virtual a= ddresses isn't usable at secondary process. Such as the secondary process link= ed with more libraries than primary process. The library has been mapped into = this virtual address. The command line parameter 'base-virtaddr' has been adde= d for this situation. If it's configured, the hugepages will be mapped into th= is base address. But the virtual address of pci resources mapped still does no= t refer to the parameter. In that case "EAL: pci_map_resource(): cannot mmap" = =0Awill be got.=0A=0AThis patch try to map pci resources after hugepages. So t= he 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/ea= l/eal_pci.c b/lib/librte_eal/linuxapp/eal/eal_pci.c=0Aindex ddb0535..502eef2 1= 00644=0A--- a/lib/librte_eal/linuxapp/eal/eal_pci.c=0A+++ b/lib/librte_eal/lin= uxapp/eal/eal_pci.c=0A@@ -97,14 +97,42 @@ error:=0A return -1;=0A }=0A =0A+st= atic void *=0A+pci_find_max_end_va(void)=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 resource from a file */ void * pci_map_resourc= e(void *requested_addr, int fd, off_t offset, size_t size) {=0A void *mapadd= r;=0A =0A+ /* By default the PCI memory resource will be mapped after hugepage= s */=0A+ static void *default_map_addr;=0A+ if (NULL =3D=3D requested_addr) {=0A= + if (NULL =3D=3D default_map_addr)=0A+ default_map_addr =3D pci_find_max_e= nd_va();=0A+ mapaddr =3D default_map_addr;=0A+ } else {=0A+ mapaddr =3D r= equested_addr;=0A+ }=0A+=0A /* Map the PCI memory resource of device */=0A- m= apaddr =3D mmap(requested_addr, size, PROT_READ | PROT_WRITE,=0A+ mapaddr =3D = mmap(mapaddr, size, PROT_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_ad= dr, int fd, off_t offset, size_t size)=0A strerror(errno), mapaddr);=0A g= oto 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 a= t %p\n", mapaddr);=0A =0A--=0A1.9.1 >From nhorman@tuxdriver.com Mon Nov 10 12:10:38 2014 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 104D56828 for ; Mon, 10 Nov 2014 12:10:38 +0100 (CET) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Xnn14-0000fV-UC; Mon, 10 Nov 2014 06:20:21 -0500 Date: Mon, 10 Nov 2014 06:20:13 -0500 From: Neil Horman To: "Sujith Sankar (ssujith)" Message-ID: <20141110112013.GA26613@hmsreliant.think-freely.org> References: <1415390747-9532-1-git-send-email-ssujith@cisco.com> <1415390747-9532-4-git-send-email-ssujith@cisco.com> <20141107113449.GC25469@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH 3/7] ENIC PMD Makefile 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 11:10:38 -0000 On Mon, Nov 10, 2014 at 09:59:45AM +0000, Sujith Sankar (ssujith) wrote: > Neil, > > If I move the DPDK patch that accommodates ENIC PMD (that is the one that > patches lib/Makefile) to the last in the series, builds between commits > would succeed, wouldnąt it? Moving that to the last is anyway needed. > correct, yes. Neil > Thanks, > -Sujith > > On 07/11/14 9:16 pm, "Sujith Sankar (ssujith)" wrote: > > >Hi Neil, > > > >Thanks for the comments. I shall work on the modifications that you have > >suggested and get back with V2. > > > >Regards, > >-Sujith > > > >On 07/11/14 5:04 pm, "Neil Horman" wrote: > > > >>On Sat, Nov 08, 2014 at 01:35:43AM +0530, Sujith Sankar wrote: > >>> Signed-off-by: Sujith Sankar > >>> --- > >>> lib/librte_pmd_enic/Makefile | 66 > >>>++++++++++++++++++++++++++++++++++++++++++++ > >>> 1 file changed, 66 insertions(+) > >>> create mode 100644 lib/librte_pmd_enic/Makefile > >>> > >>> diff --git a/lib/librte_pmd_enic/Makefile > >>>b/lib/librte_pmd_enic/Makefile > >>> new file mode 100644 > >>> index 0000000..7605a8f > >>> --- /dev/null > >>> +++ b/lib/librte_pmd_enic/Makefile > >>> @@ -0,0 +1,66 @@ > >>> +# BSD LICENSE > >>> +# > >>> +# Copyright(c) 2010-2013 Intel Corporation. All rights reserved. > >>> +# All rights reserved. > >>> +# > >>> +# Redistribution and use in source and binary forms, with or without > >>> +# modification, are permitted provided that the following conditions > >>> +# are met: > >>> +# > >>> +# * Redistributions of source code must retain the above copyright > >>> +# notice, this list of conditions and the following disclaimer. > >>> +# * Redistributions in binary form must reproduce the above > >>>copyright > >>> +# notice, this list of conditions and the following disclaimer > >>>in > >>> +# the documentation and/or other materials provided with the > >>> +# distribution. > >>> +# * Neither the name of Intel Corporation nor the names of its > >>> +# contributors may be used to endorse or promote products > >>>derived > >>> +# from this software without specific prior written permission. > >>> +# > >>> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND > >>>CONTRIBUTORS > >>> +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > >>> +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS > >>>FOR > >>> +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE > >>>COPYRIGHT > >>> +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, > >>>INCIDENTAL, > >>> +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT > >>> +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF > >>>USE, > >>> +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON > >>>ANY > >>> +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR > >>>TORT > >>> +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE > >>>USE > >>> +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH > >>>DAMAGE. > >>> +# > >>> + > >>> +include $(RTE_SDK)/mk/rte.vars.mk > >>> + > >>> +# > >>> +# library name > >>> +# > >>> +LIB = librte_pmd_enic.a > >>> + > >>> +CFLAGS += -I$(RTE_SDK)/lib/librte_hash/ > >>> +CFLAGS += -O3 -Wno-deprecated > >>> + > >>> +VPATH += $(RTE_SDK)/lib/librte_pmd_enic/src > >>> + > >>> +# > >>> +# all source are stored in SRCS-y > >>> +# > >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_main.c > >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_clsf.c > >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_cq.c > >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_wq.c > >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_dev.c > >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_intr.c > >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_rq.c > >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_etherdev.c > >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic_res.c > >>> +SRCS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += vnic_rss.c > >>> + > >>> + > >>> +# this lib depends upon: > >>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_eal > >>>lib/librte_ether > >>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_mempool > >>>lib/librte_mbuf > >>> +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += lib/librte_net > >>>lib/librte_malloc > >>> + > >>> +include $(RTE_SDK)/mk/rte.lib.mk > >>> + > >>> -- > >>> 1.9.1 > >>> > >>> > >> > >>Make this the last patch in your series, and merge it with the chunk from > >>the > >>last patch that adds the enic directory to the lib/Makefile, so that a > >>bisect > >>will build between these commits. > >> > >>Neil > >> > > > >