From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Zhang, Helin" Subject: Re: [dpdk-announce] important design choices - statistics - ABI Date: Thu, 18 Jun 2015 08:36:13 +0000 Message-ID: References: <9092314.MoyqUJ5VU2@xps13> <20150617103521.GB24677@hmsreliant.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: Neil Horman , Thomas Monjalon Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id B220BC398 for ; Thu, 18 Jun 2015 10:38:46 +0200 (CEST) In-Reply-To: <20150617103521.GB24677@hmsreliant.think-freely.org> Content-Language: en-US List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Neil > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil Horman > Sent: Wednesday, June 17, 2015 6:35 PM > To: Thomas Monjalon > Cc: announce@dpdk.org > Subject: Re: [dpdk-dev] [dpdk-announce] important design choices - statis= tics - > ABI >=20 > On Wed, Jun 17, 2015 at 01:29:47AM +0200, Thomas Monjalon wrote: > > Hi all, > > > > Sometimes there are some important discussions about architecture or > > design which require opinions from several developers. Unfortunately, > > we cannot read every threads. Maybe that using the announce mailing > > list will help to bring more audience to these discussions. > > Please note that > > - the announce@ ML is moderated to keep a low traffic, > > - every announce email is forwarded to dev@ ML. > > In case you want to reply to this email, please use dev@dpdk.org addres= s. > > > > There were some debates about software statistics disabling. > > Should they be always on or possibly disabled when compiled? > > We need to take a decision shortly and discuss (or agree) this proposal= : > > http://dpdk.org/ml/archives/dev/2015-June/019461.html > > > > During the development of the release 2.0, there was an agreement to > > keep ABI compatibility or to bring new ABI while keeping old one during= one > release. > > In case it's not possible to have this transition, the (exceptional) > > break should be acknowledged by several developers. > > http://dpdk.org/doc/guides-2.0/rel_notes/abi.html > > There were some interesting discussions but not a lot of participants: > > > > http://thread.gmane.org/gmane.comp.networking.dpdk.devel/8367/focus=3D8= 4 > > 61 > > > > During the current development cycle for the release 2.1, the ABI > > question arises many times in different threads. > > To add the hash key size field, it is proposed to use a struct padding = gap: > > http://dpdk.org/ml/archives/dev/2015-June/019386.html > > To support the flow director for VF, there is no proposal yet: > > http://dpdk.org/ml/archives/dev/2015-June/019343.html > > To add the speed capability, it is proposed to break ABI in the release= 2.2: > > http://dpdk.org/ml/archives/dev/2015-June/019225.html > > To support vhost-user multiqueues, it is proposed to break ABI in 2.2: > > http://dpdk.org/ml/archives/dev/2015-June/019443.html > > To add the interrupt mode, it is proposed to add a build-time option > > CONFIG_RTE_EAL_RX_INTR to switch between compatible and ABI breaking > binary: > > http://dpdk.org/ml/archives/dev/2015-June/018947.html > > To add the packet type, there is a proposal to add a build-time option > > CONFIG_RTE_NEXT_ABI common to every ABI breaking features: > > http://dpdk.org/ml/archives/dev/2015-June/019172.html > > We must also better document how to remove a deprecated ABI: > > http://dpdk.org/ml/archives/dev/2015-June/019465.html > > The ABI compatibility is a new constraint and we need to better > > understand what it means and how to proceed. Even the macros are not ye= t > well documented: > > http://dpdk.org/ml/archives/dev/2015-June/019357.html > > > > Thanks for your attention and your participation in these important cho= ices. > > >=20 > Thomas- > Just to re-iterate what you said earlier, and what was discussed in the > previous ABI discussions >=20 > 1) ABI stability was introduced to promote DPDK's ability to be included = with > various linux and BSD distributions. Distributions, by and large, favor = building > libraries as DSO's, favoring security and updatability in favor of all ou= t > performance. >=20 > 2) The desire was to put DPDK developers in a mindset whereby ABI stabili= ty was > something they needed to think about during development, as the DPDK > exposes many data structures and instances that cannot be changed without > breaking ABI >=20 > 3) The versioning mechanism was introduced to allow for backward compatib= ility > during periods in which we needed to support both an old an new ABI >=20 > 4) As Stephan and others point out, its not expected that we will always = be able > to maintain ABI, and as such an easy library versioning mechanism was > introduced to prevent the loading of an incompatible library with an olde= r > application >=20 > 5) The ABI policy was introduced to create a method by which new ABI face= ts > could be scheduled while allowing distros to prepare their downstream use= rs for > the upcomming changes. >=20 >=20 > It seems to me, looking back over these last few months, that we're falli= ng down > a bit on our use of (3). I've seen several people take advantage of the = ABI > scheduled updates, but no one has tried the versioning interface, and as = a result > patches are getting delayed, which was never my intent. Not sure whats t= o be > done about that, but we should probably address it. Is use of the versio= nnig > interface just too hard or convoluted? That means we should try to use versioning mechanism as more as possible? Are there any rules/instructions to judge what type of changes we should tr= y versioning mechanism, and what else we shouldn't try? Is there any good examples of using versioning mechanism for reference? Even not in DPDK project. Thanks, Helin >=20 > Neil