From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id B03AC9175 for ; Wed, 16 Aug 2017 13:31:56 +0200 (CEST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Aug 2017 04:31:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,382,1498546800"; d="scan'208";a="140280552" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by fmsmga005.fm.intel.com with ESMTP; 16 Aug 2017 04:31:54 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.91]) by irsmsx105.ger.corp.intel.com ([169.254.7.25]) with mapi id 14.03.0319.002; Wed, 16 Aug 2017 12:31:54 +0100 From: "Van Haaren, Harry" To: Neil Horman CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 0/8] service: rework for usability Thread-Index: AQHTFcKdjbTGqLBnbUqwHRr+XvLNdqKGxeKAgAAR8BA= Date: Wed, 16 Aug 2017 11:31:53 +0000 Message-ID: References: <1502800360-15782-1-git-send-email-harry.van.haaren@intel.com> <20170816111619.GA9348@hmswarspite.think-freely.org> In-Reply-To: <20170816111619.GA9348@hmswarspite.think-freely.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODkyODQxMjMtMjM3NS00OWZhLWEzZWItMTJiNGE5YWUzZTMwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IjVIYnpWcXNHYXhsT25IaFpGVUsxbDFXazM5elZ3UUdhd05sUlk3SUhGTFk9In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 0/8] service: rework for usability 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, 16 Aug 2017 11:31:57 -0000 > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Wednesday, August 16, 2017 12:16 PM > To: Van Haaren, Harry > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 0/8] service: rework for usability >=20 > On Tue, Aug 15, 2017 at 01:32:32PM +0100, Harry van Haaren wrote: > > This patchset reworks the service apis to be more user > > friendly. In particular, the various rte_service_* functions > > now take an integer id parameter instead of a service pointer. > > This both reduces the API surface (no service_get_from_id()), > > and allows easier debugging (gdb function calls with integer args), > > and various other benefits (better encapsulation, less pointers :) > > > > Finally, some APIs are changed or renamed for consistency and > > clarity of what they do. See commit messages for details. > > Note that the service library is merged as EXPERIMENTAL in > > the 17.08 release, allowing API improvements for 17.11 release. > > > > I hope to merge this patchset early in the 17.11 timeframe, > > so please review ASAP to allow time for other DPDK components > > to utilize services in this release :) > > > > Feedback and input welcome, -Harry > > > You need to add a deprecation note in the rel notes area so that people a= re > aware of the upcomming ABI changes Service cores was merged into 17.08 with the EXPERIMENTAL tag, which indica= tes that the API and ABI are not stable. The version map file has the servi= ce cores functions added in the Experimental staging area, instead of in th= e 17.08 stable ABI[1]. To make this very visible to the users, the document= ation has large "Warning: Experimental, this API may change without prior n= otice" marks[2], and the MAINTAINERS file[3] has the Experimental tag. As far as I am aware, those are all the requirements to be able to remove /= change / update / fix APIs. It was discussed on #IRC that it would be bett= er to merge service-cores as experimental to allow faster iteration, and to= get improvements out the door, and I'm still of that opinion. Given the above, I don't see any issue with merging service-core changes in= to the 17.11 release. [1] http://dpdk.org/browse/dpdk/tree/lib/librte_eal/linuxapp/eal/rte_eal_ve= rsion.map#n212 [2] http://dpdk.org/doc/api/rte__service_8h.html#aea7fce2a101bf2c00194dffb3= 0bfc4ea [3] http://dpdk.org/browse/dpdk/tree/MAINTAINERS#n138