From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 7E92D1B6A0 for ; Fri, 3 Nov 2017 14:58:45 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CDCA32113A; Fri, 3 Nov 2017 09:58:44 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 03 Nov 2017 09:58:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=/metpdzkb8YFdB7Mwjr6CajRlf LQMRpxtYPokzrpNXg=; b=p/CFggaQVnWbqbkvKpHpAUQPq9DEK4vNiSdLVSoyKo Wzqz10nMmpXBqNUbPxPch1j9Szb42gmwxmDWz/Yo8SU5DFmOslxNsHvmQVMlL7XJ MEk8TSNhZ1ZRKuizWaXEdaPrTKjbiUuUnWzU51JhBDA4EG3KJtEbUIWEeNmJeiyq Y= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=/metpd zkb8YFdB7Mwjr6CajRlfLQMRpxtYPokzrpNXg=; b=cBEj3cpIu1Py4LYBtLEy/C JauwlnxPU4Vklc/MN6+dJ7skq0ShWVRYRdwpETqVu7YTHy9LlZQpeBOZcGhL4CbO ArpYnKlZjoNXw220Nz2pmctD7DCjJ5Ktb4yAujYyM8Jcgg4EoEV/1NICwJ2xVYZL DzxeLAjiZVC0fuKSbMoVNuza4RuwqSIq9L4xotMa5NBXme1tWVyTKQG1dRoeviUi 1Dy+e3cYMMcRVhe8vwuh4AyGX21YTmyuNSasTjjnjZmPQ1paX9UJG2fZz3/qzVaE RExTELa2NVtYqThj2P71LeM6Jc4XFPoP/l/zuJTJpIalOuHCe2fFffUVP7+cvaxg == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 9204F7F9CC; Fri, 3 Nov 2017 09:58:44 -0400 (EDT) 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: Fri, 03 Nov 2017 14:58:43 +0100 Message-ID: <16080450.FyQkJaYVGX@xps> In-Reply-To: <2572bad0-8023-3146-dfd1-1e0ef874fe70@caviumnetworks.com> References: <20170905103119.20511-1-santosh.shukla@caviumnetworks.com> <5335497.nnbAZL8Naz@xps> <2572bad0-8023-3146-dfd1-1e0ef874fe70@caviumnetworks.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 4/6] eal/memory: rename memory API to iova types 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 13:58:45 -0000 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 _iova types. > >> The following api renamed from: > >> > >> rte_mempool_populate_phys() > >> rte_mempool_populate_phys_tab() > > These functions still have "physical addresses" in their description. > > It is not consistent. > > > > Please provide ABI compatibility for mempool functions. > > > >> rte_eal_using_phys_addrs() > > Why renaming rte_eal_using_phys_addrs? > > I think we need to review how it is used. > > Maybe it requires a rework. > > > >> rte_mem_virt2phy() > >> rte_dump_physmem_layout() > >> rte_eal_get_physmem_layout() > >> rte_eal_get_physmem_size() > > Those 3 functions deal with physical memory layout. > > I don't see a need to rename them. > > In iova=va 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_malloc_virt2phy() > >> rte_mem_phy2mch() > > 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_mempool_populate_iova() > >> rte_mempool_populate_iova_tab() > >> rte_eal_using_iova_addrs() > >> rte_mem_virt2iova() > > [...] > >> rte_malloc_virt2iova() > > I am not convinced by the names virt2iova. > > I sounds like "virt to virt". > > What about "virt2io" or "virt2io_addr"? > > no, iova can be _pa or _va, its an io_addr indeed but > I prefer virt2iova, same mentioned in deprecation notice (no strong opinion), > > More suggestion on naming pl.? I like virt2io_addr but virt2iova is not so bad. I agree with Santosh that we need more opinions. > > 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.