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 E6A3B1B659 for ; Fri, 3 Nov 2017 12:11:49 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CF8ED20D05; Fri, 3 Nov 2017 07:11:48 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 03 Nov 2017 07:11:48 -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=u9X4KOAtwvQyyaMTvjxYMsdM4l pDr6l2smCKoud3noE=; b=nclxU5rSePD3cOLqZu93d54PFm5SkRQ7GEY0NFrOYT P9chZZ095Gr4fpiaZ2Iz9UV4KB70i/BVWzxwysE2fwiV53573ZWWafl/J5hexTWd keldEpqjpfXWWeJHyRosDkXOqWkwEOxrVuRqzhxw8zOk4lpnu7fQkHCJyc6IOH67 E= 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=u9X4KO AtwvQyyaMTvjxYMsdM4lpDr6l2smCKoud3noE=; b=VLd8X00ocPvSQ5wCetuEDW fNlDbBOexcJyLFR/38gYm97HW9ZhECHsSqNHdPK7zVoKF4ziaJ32gIHP1NMjLi64 ZjFJ+H3CeERrZwXfYU6mzLFn58up34XWYEoUCComLwmbEtKdN/pJAxynou0ocVEg D90/943ZLVXinUI8SpTeRBm+1A8siQMfKuDgO146KjUKQ9/cvtYjwMgED2Jrh6/P Q1QjkwppZAOfhWqlxbsk6Wqf56k1f4LmyA4VMNIeu1hoJgQ2rdvIx2uFwEeW1PG1 RAsvhUVtTLKnPXySPDo6fF8uufAHKRzIWYyGRVvYx2Vu7X0lrQ7IfTjZvG+n8yGA == 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 7CA90246D5; Fri, 3 Nov 2017 07:11:48 -0400 (EDT) From: Thomas Monjalon To: Santosh Shukla 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 12:11:47 +0100 Message-ID: <5335497.nnbAZL8Naz@xps> In-Reply-To: <20171020123136.10557-5-santosh.shukla@caviumnetworks.com> References: <20170905103119.20511-1-santosh.shukla@caviumnetworks.com> <20171020123136.10557-1-santosh.shukla@caviumnetworks.com> <20171020123136.10557-5-santosh.shukla@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 11:11:50 -0000 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. 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"? 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.