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 5371E9FE for ; Wed, 25 Oct 2017 11:45:40 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D7C08225BF; Wed, 25 Oct 2017 05:45:39 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 25 Oct 2017 05:45:39 -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=BM6NyMReryXqXMCwMckbKmh3Rl rDlTvcaBAD8ULCC9w=; b=YzH2IR2ZnJ/smIGpgsRIcxiwAc3CnqDm5+d+OzH8lC /bmL0Xt8ysr+WZZgIGs57dRlsO4yIEMP0DnwZ8PVq6wVtt6cm+0XdebgDv3fMQQk fd+hCZ93d0/ll9Ppq3B0Lx5cdaEPPbQAdeDH1CHFmrRRg4ZqevTxfd/VZSQZVvj0 o= 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=BM6NyM ReryXqXMCwMckbKmh3RlrDlTvcaBAD8ULCC9w=; b=Dn69x3ohyZKuxVQeTaFXMd 3CsW2LzIGolr8a8P0rKPajjAwvyQtRCJQUwBr+vnzwVLOJkfh744/VdYanpmTlxW 78/vxg9quxyAids/AzuEjRfgdmBeTxEQfgi0GegDfvxiOWbjgROLbWBzHhLgdN8X vxJQAj2qeyn059YlS+sUoE67WdoWcFKCq8834vqOZhfonIOQPwSf0gBxTFfBD4KT bC0R10WCTN2np8K/wzpIfoqWaPsPOfERlvN35thBBwKnv73KCkRbElEtUw7FQyXf wqR3eklMkljgPQwXBxSFqdSGHtP96ONAXTm3iUzgPJtyeIzTOn3Bac03PZ6a7K5g == 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 762467FA80; Wed, 25 Oct 2017 05:45:39 -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: Wed, 25 Oct 2017 11:45:38 +0200 Message-ID: <1947820.k6ijHbkXh2@xps> In-Reply-To: <4cc3e70d-68d1-70e3-a23b-9aa6c37b1738@caviumnetworks.com> References: <20170905103119.20511-1-santosh.shukla@caviumnetworks.com> <3176198.eLQH8UvYp5@xps> <4cc3e70d-68d1-70e3-a23b-9aa6c37b1738@caviumnetworks.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 5/6] doc: remove dpdk iova aware notice 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: Wed, 25 Oct 2017 09:45:40 -0000 Hi Santosh, 24/10/2017 07:06, santosh: > Hi Thomas, > > > On Tuesday 24 October 2017 01:59 AM, Thomas Monjalon wrote: > > 20/10/2017 14:31, Santosh Shukla: > >> Removed dpdk iova aware ABI deprecation notice, > >> and updated ABI change details in release_17.11.rst. > >> > >> Signed-off-by: Santosh Shukla > >> Acked-by: John McNamara > >> --- > >> --- a/doc/guides/rel_notes/deprecation.rst > >> +++ b/doc/guides/rel_notes/deprecation.rst > >> -* eal: An ABI change is planned for 17.11 to make DPDK aware of IOVA address > >> - translation scheme. > >> - Reference to phys address in EAL data-structure or functions may change to > >> - IOVA address or more appropriate name. > >> - The change will be only for the name. > >> - Functional aspects of the API or data-structure will remain same. > > Sorry, this series cannot be applied as is because it is breaking > > more than EAL API. The API of mbuf and mempool are also changed. > > We need to choose one of these three options: > > 1/ accept to break all API in 17.11 > > 2/ postpone the whole series to 18.02 > > Theme of series is to make dpdk iova aware so I would prefer option 1) or 2). > However I have no strong opinion on this topic. > Lets get more opinion from others about option 1/2/3. > > > 3/ rename only EAL API in 17.11 and postpone mbuf/mempool After discussing with Olivier it appeared there is a fourth solution. We should not break any API (EAL, mbuf, mempool). I would like to merge these changes in RC2, but keeping compatibility with old names: - When you rename a function or a type, you can define a macro for the old name, alias the new name. - When you rename a struct field, you can make an anonymous union to allow both names. Then we can deprecate the old names and remove them later. Are you able to do these small changes today please?