From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id BF00AA0679 for ; Thu, 4 Apr 2019 21:08:36 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B5D001B3EA; Thu, 4 Apr 2019 21:08:35 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 2FF131B3BB; Thu, 4 Apr 2019 21:08:33 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2019 12:08:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,309,1549958400"; d="scan'208";a="335056456" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga005.fm.intel.com with ESMTP; 04 Apr 2019 12:08:32 -0700 Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 4 Apr 2019 12:08:32 -0700 Received: from fmsmsx117.amr.corp.intel.com ([169.254.3.142]) by fmsmsx156.amr.corp.intel.com ([169.254.13.6]) with mapi id 14.03.0415.000; Thu, 4 Apr 2019 12:08:31 -0700 From: "Wiles, Keith" To: Kevin Traynor CC: "Richardson, Bruce" , "Burakov, Anatoly" , Ray Kinsella , dpdk-dev , "techboard@dpdk.org" Thread-Topic: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability Thread-Index: AQHU6tTjwvKa2Jf6m0WKNTdCkXaJOqYsrnuAgAAkvgA= Date: Thu, 4 Apr 2019 19:08:30 +0000 Message-ID: References: <94df3cc4-de54-72d6-84c6-81bebd209a81@intel.com> <20190404105447.GA1351@bricha3-MOBL.ger.corp.intel.com> <3d4dfde3-cf8c-8220-18a3-1542567cc3eb@redhat.com> In-Reply-To: <3d4dfde3-cf8c-8220-18a3-1542567cc3eb@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.102.28] Content-Type: text/plain; charset="UTF-8" Content-ID: <82C84E30F8D3E344BA2D6A0A8B053089@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190404190830.MNmGfGC8XFrcXLKHgtwzNSiNQyrUCBm46BMMk_-jAPc@z> > On Apr 4, 2019, at 11:56 AM, Kevin Traynor wrote: >=20 > On 04/04/2019 11:54, Bruce Richardson wrote: > >=20 >>=20 >> My thoughts on the matter are: >> 1. I think we really need to do work to start hiding more of our data >> structures - like what Stephen's latest RFC does. This hiding should red= uce >> the scope for ABI breaks. >> 2. Once done, I think we should commit to having an ABI break only in th= e >> rarest of circumstances, and only with very large justification. I want = us >> to get to the point where DPDK releases can immediately be picked up by = all >> linux distros and rolled out because they are ABI compatible. >>=20 >=20 > Maybe techboard should explicitly approve ABI breaks and new APIs (or > APIs at transition from experimental to core). Just as a way to get more > eyeballs and scrutiny on them. ABI breaks should be handled by the board. As for new APIs they are not so = bad and they do not need to be approved by the board just handled in the no= rmal way. For API changes (I guess that is ABI) needs to be handled by the = board unless we use the version control and maintain both APIs for a while. >=20 >> I'm not sure I like the idea of planned ABI break releases - that strike= s >> me as a plan where we end up with the same number of ABI breaks as befor= e, >> just balled into one release. >>=20 >> Question for Kevin, Luca and others who look at distro-packaging: is it = the >> case that each distro will only ship one version of DPDK, or is it possi= ble >> that if we have ABI breaks, a distro will provide two copies of DPDK >> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version? >>=20 >=20 > It would probably double validation and maintenance, so it would require > a lot of extra effort. >=20 >>=20 >> So, in short, I'm generally in favour of a zero-tolerance approach for D= PDK >> ABI breaks, and having ABI breaks as a major event reserved only for >> massive rework changes, such as major mbuf changes, or new memory layout= or >> similar. >>=20 >> Regards, >> /Bruce >>=20 >=20 Regards, Keith