From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 2C24E1C00 for ; Wed, 25 Oct 2017 11:50:58 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Oct 2017 02:50:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,431,1503385200"; d="scan'208";a="142020352" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by orsmga004.jf.intel.com with ESMTP; 25 Oct 2017 02:50:56 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.49]) by IRSMSX107.ger.corp.intel.com ([169.254.10.239]) with mapi id 14.03.0319.002; Wed, 25 Oct 2017 10:50:55 +0100 From: "Richardson, Bruce" To: Thomas Monjalon , santosh CC: "dev@dpdk.org" , "olivier.matz@6wind.com" , "jerin.jacob@caviumnetworks.com" , "hemant.agrawal@nxp.com" , "Burakov, Anatoly" Thread-Topic: [dpdk-dev] [PATCH v3 5/6] doc: remove dpdk iova aware notice Thread-Index: AQHTSZ+sT0ivKISfXUKWrzEtwlxzeKLx1zcAgACQeYCAAeBTAIAAEebQ Date: Wed, 25 Oct 2017 09:50:54 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B0721ECB08@IRSMSX103.ger.corp.intel.com> References: <20170905103119.20511-1-santosh.shukla@caviumnetworks.com> <3176198.eLQH8UvYp5@xps> <4cc3e70d-68d1-70e3-a23b-9aa6c37b1738@caviumnetworks.com> <1947820.k6ijHbkXh2@xps> In-Reply-To: <1947820.k6ijHbkXh2@xps> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDg0NTc0MGUtZDdhNy00ODA1LWI1MzgtZjIzNTY3MGQ1MzM5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImtvY2FQNytwSmdkM2hRZFAwSmN3ZmR1WitINGl0RnFyODlmbVVjdXVib0U9In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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:50:59 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon > Sent: Wednesday, October 25, 2017 10:46 AM > To: santosh > Cc: dev@dpdk.org; olivier.matz@6wind.com; jerin.jacob@caviumnetworks.com; > hemant.agrawal@nxp.com; Burakov, Anatoly > Subject: Re: [dpdk-dev] [PATCH v3 5/6] doc: remove dpdk iova aware notice >=20 > Hi Santosh, >=20 > 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 >=20 > After discussing with Olivier it appeared there is a fourth solution. > We should not break any API (EAL, mbuf, mempool). >=20 > I would like to merge these changes in RC2, but keeping compatibility wit= h > old names: > - When you rename a function or a type, you can define a macro for the ol= d > name, alias the new name. Note: using a macro doesn't prevent the ABI being broken if you rename a pu= blic function. You'll need to use function versioning too.