From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 37869A0613 for ; Wed, 25 Sep 2019 15:31:32 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 118272C6A; Wed, 25 Sep 2019 15:31:31 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 827BF2C57; Wed, 25 Sep 2019 15:31:29 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BD04F20F5; Wed, 25 Sep 2019 13:31:28 +0000 (UTC) Received: from [10.36.117.187] (ovpn-117-187.ams2.redhat.com [10.36.117.187]) by smtp.corp.redhat.com (Postfix) with ESMTP id 49D315C226; Wed, 25 Sep 2019 13:31:25 +0000 (UTC) To: Ray Kinsella , dpdk-dev , "O'Driscoll, Tim" , Brian Cc: "techboard@dpdk.org" References: <126e7de8-d2cd-d9f0-4fe8-d0d05963589f@ashroe.eu> From: Kevin Traynor Message-ID: <69a1da67-da6b-f004-7b84-279c55083e2e@redhat.com> Date: Wed, 25 Sep 2019 14:31:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <126e7de8-d2cd-d9f0-4fe8-d0d05963589f@ashroe.eu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.71]); Wed, 25 Sep 2019 13:31:28 +0000 (UTC) Subject: Re: [dpdk-dev] [RFC] Proposals and notes from ABI stability panel @ DPDK Userspace 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" On 23/09/2019 18:51, Ray Kinsella wrote: > Folks, >=20 > As you may be aware, there was a panel on ABI Stability @ DPDK > Userspace. There where a number of proposed amendments to the ABI > stability proposal made, as well as a number of points and comments, yo= u > will find all these below. The proposals needs further discussion so > please chime in below. >=20 > Thanks to Tim for capturing while I was busy on the stage. >=20 Thanks for the notes Tim, > Thanks, >=20 > Ray K >=20 >=20 > Table of Contents > _________________ >=20 > 1. Proposals from the panel discussion. > .. 1. Developer releases (versus User Releases) > .. 2. Core and non-core packaging > .. 3. Approach for public data structures > .. 4. Delaying v19.11 > 2. Other notes from the panel discussion. > .. 1. Performance as the paramount goal. > .. 2. Length of ABI Stability. > .. 3. Testing ABI Stability > .. 4. Call to action >=20 >=20 > 1 Proposals from the panel discussion. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1.1 Developer releases (versus User Releases) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > - Summary: Differentiate between "developer" and "user" releases. > - 1 year is too long to wait to upstream a new feature which breaks= > ABI. > - Developer releases would be for use by the development community > only. > - A proposed compromise was that the .08 release would be the only > "developer release". >=20 >=20 > 1.2 Core and non-core packaging > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > - Summary: OS packaging doesn't include all libraries. > - This would create a delta between the community ABI, and the OS > packaging. > - OS packagers rational is that some libraries are used very rarely= =2E >=20 >=20 > 1.3 Approach for public data structures > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > - Summary: Public/exposed data structures are tricky for ABI > stability. > - See discussion @ >=20 > >=20 >=20 > 1.4 Delaying v19.11 > ~~~~~~~~~~~~~~~~~~~ >=20 > - Summary: push v19.11 to v19.12 to make more time to prepare and wav= e > the depreciation process. > - OVS take Nov LTS release in their Feb release. Delaying 19.11 may= > have an impact on this. To give some more info about OVS. tldr there is a soft freeze on Jan 1st but an update that is being discussed/reviewed could go in until Jan 15th when the OVS 2.13 branch would be created. Thomas is indeed right in that there is a development branch in OVS that is intended to keep up with DPDK master with a view to finding any integration issues early. More info here http://docs.openvswitch.org/en/latest/internals/release-process/#release-= strategy > - Not easy to change release at this stage as many things depend on= > it (OS distros etc.). >=20 In the short term, based on the feedback at the conference and to give something concrete to be considered, here is a suggestion, ABI freeze starts at 20.02 for 9 months, with a review as planned to see if 20.11 should be frozen 2 years. pros: + Eliminates any need for delaying 19.11 release + Allows maintainers to stick to current deprecation policy if they need to make changes prior to freeze (Based on comment from Hemmant) + Not sure if it's worthy of a new bullet or clear from above but I would add that changing the release cycle/deprecation policy etc 2 weeks (I think) before RC1 is late to say the least and there is no notice to users + Means that any changes required prior to freeze are not rushed with usual big LTS release (19.11). Gives more time and maybe during a saner release cycle (20.02) cons: - With view for possible 20.11 freeze, gives 2 releases to tease out process instead of 3 - Perhaps it is desirable for some users to have the 19.11 LTS ABI compatible with 20.02/05/08 releases I've tried to keep them objective, of course people will have different opinions about starting a freeze now vs. later etc. too. thanks, Kevin. >=20 > 2 Other notes from the panel discussion. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 2.1 Performance as the paramount goal. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > - Some users, would trade performance for better readability and > debug-ability. > - Skepticism that micro-benchmarks reflect real world performance. >=20 >=20 > 2.2 Length of ABI Stability. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > - Some users, questioned if 1 year would be long enough. > - It was clarified that the 1 year period, would be reviewed after th= e > first year with the intention of lengthening the period. >=20 >=20 > 2.3 Testing ABI Stability > ~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > - More work for developers and validation teams. Need to validate > multiple paths for symbol versioning. >=20 >=20 > 2.4 Call to action > ~~~~~~~~~~~~~~~~~~ >=20 > - We should do something. So we don=E2=80=99t want to have the same > conversation again in a year. >=20