From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by dpdk.org (Postfix) with ESMTP id 2FD941B68C for ; Fri, 3 Nov 2017 16:22:44 +0100 (CET) Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA3FL1iB003411 for ; Fri, 3 Nov 2017 11:22:44 -0400 Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [192.155.248.91]) by mx0a-001b2d01.pphosted.com with ESMTP id 2e0q2hqgd2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 03 Nov 2017 11:22:44 -0400 Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for from ; Fri, 3 Nov 2017 15:22:43 -0000 Received: from us1a3-smtp07.a3.dal06.isc4sb.com (10.146.103.14) by smtp.notes.na.collabserv.com (10.106.227.143) with smtp.notes.na.collabserv.com ESMTP; Fri, 3 Nov 2017 15:22:37 -0000 Received: from us1a3-mail173.a3.dal06.isc4sb.com ([10.146.71.126]) by us1a3-smtp07.a3.dal06.isc4sb.com with ESMTP id 2017110315223644-629258 ; Fri, 3 Nov 2017 15:22:36 +0000 MIME-Version: 1.0 In-Reply-To: <16080450.FyQkJaYVGX@xps> To: Thomas Monjalon Cc: santosh , dev@dpdk.org, olivier.matz@6wind.com, jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com, anatoly.burakov@intel.com From: "Jonas Pfefferle1" Date: Fri, 3 Nov 2017 16:22:34 +0100 References: <20170905103119.20511-1-santosh.shukla@caviumnetworks.com> <5335497.nnbAZL8Naz@xps> <2572bad0-8023-3146-dfd1-1e0ef874fe70@caviumnetworks.com> <16080450.FyQkJaYVGX@xps> X-KeepSent: 2CB1F1CB:430BCD79-C12581CD:005436F7; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1 October 14, 2013 X-LLNOutbound: False X-Disclaimed: 65507 X-TNEFEvaluated: 1 x-cbid: 17110315-9951-0000-0000-000004E89E1E X-IBM-SpamModules-Scores: BY=0.170555; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.433748; ST=0; TS=0; UL=0; ISC=; MB=0.000344 X-IBM-SpamModules-Versions: BY=3.00008003; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000239; SDB=6.00940596; UDB=6.00474317; IPR=6.00720852; BA=6.00005670; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017851; XFM=3.00000015; UTC=2017-11-03 15:22:41 X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused X-IBM-AV-VERSION: SAVI=2017-11-03 14:31:43 - 6.00007558 x-cbparentid: 17110315-9952-0000-0000-00002F82BC96 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-03_06:, , signatures=0 X-Proofpoint-Spam-Reason: safe Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v3 4/6] eal/memory: rename memory API to iovatypes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 15:22:45 -0000 "dev" wrote on 11/03/2017 02:58:43 PM: > From: Thomas Monjalon > To: santosh > Cc: dev@dpdk.org, olivier.matz@6wind.com, > jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com, > anatoly.burakov@intel.com > Date: 11/03/2017 02:59 PM > Subject: Re: [dpdk-dev] [PATCH v3 4/6] eal/memory: rename memory API > to iova types > Sent by: "dev" > > 03/11/2017 12:35, santosh: > > On Friday 03 November 2017 04:41 PM, Thomas Monjalon wrote: > > > 20/10/2017 14:31, Santosh Shukla: > > >> Renamed memory translational api to =5Fiova types. > > >> The following api renamed from: > > >> > > >> rte=5Fmempool=5Fpopulate=5Fphys() > > >> rte=5Fmempool=5Fpopulate=5Fphys=5Ftab() > > > These functions still have "physical addresses" in their description. > > > It is not consistent. > > > > > > Please provide ABI compatibility for mempool functions. > > > > > >> rte=5Feal=5Fusing=5Fphys=5Faddrs() > > > Why renaming rte=5Feal=5Fusing=5Fphys=5Faddrs? > > > I think we need to review how it is used. > > > Maybe it requires a rework. > > > > > >> rte=5Fmem=5Fvirt2phy() > > >> rte=5Fdump=5Fphysmem=5Flayout() > > >> rte=5Feal=5Fget=5Fphysmem=5Flayout() > > >> rte=5Feal=5Fget=5Fphysmem=5Fsize() > > > Those 3 functions deal with physical memory layout. > > > I don't see a need to rename them. > > > > In iova=3Dva mode, those api will have va address. > > Yes addresses can be virtual. > But it is still physically segmented. > > > > But the dump function needs a change to avoid printing > > > "phys" even in VA case. > > > > > >> rte=5Fmalloc=5Fvirt2phy() > > >> rte=5Fmem=5Fphy2mch() > > > This last function was removed with Xen. > > > It is wrong to rename it in the release notes. > > > It should just be removed from the map file (I will send a patch). > > > > > >> To the following iova types api: > > >> > > >> rte=5Fmempool=5Fpopulate=5Fiova() > > >> rte=5Fmempool=5Fpopulate=5Fiova=5Ftab() > > >> rte=5Feal=5Fusing=5Fiova=5Faddrs() > > >> rte=5Fmem=5Fvirt2iova() > > > [...] > > >> rte=5Fmalloc=5Fvirt2iova() > > > I am not convinced by the names virt2iova. > > > I sounds like "virt to virt". > > > What about "virt2io" or "virt2io=5Faddr"? > > > > no, iova can be =5Fpa or =5Fva, its an io=5Faddr indeed but > > I prefer virt2iova, same mentioned in deprecation notice (no > strong opinion), > > > > More suggestion on naming pl.? > > I like virt2io=5Faddr but virt2iova is not so bad. > I agree with Santosh that we need more opinions. virt2iova +1 Another suggestion va2iova to be consistent with the names > > > > As the ABI is broken in EAL 17.11, we do not care about compatibility. > > > But we must keep an alias to the old function name in order to allow > > > a smooth API transition for applications. > > > I suggest to add static inline functions with the old names and set > > > the deprecated attribute. > > > > ok, Will address in 18.02. > > I would prefer these changes made in 17.11 as announced. > As you are not willing to work on it, I am trying to send some > updated patches. >