From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP; 18 Jun 2015 01:38:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,638,1427785200"; d="scan'208";a="729797551" Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105]) by fmsmga001.fm.intel.com with ESMTP; 18 Jun 2015 01:38:44 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 18 Jun 2015 16:36:14 +0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.129]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.146]) with mapi id 14.03.0224.002; Thu, 18 Jun 2015 16:36:14 +0800 From: "Zhang, Helin" To: Neil Horman , Thomas Monjalon Thread-Topic: [dpdk-dev] [dpdk-announce] important design choices - statistics - ABI Thread-Index: AQHQqOlPaAWbAPbDSNa1yquoSADmtZ2x8aCA Date: Thu, 18 Jun 2015 08:36:13 +0000 Message-ID: References: <9092314.MoyqUJ5VU2@xps13> <20150617103521.GB24677@hmsreliant.think-freely.org> In-Reply-To: <20150617103521.GB24677@hmsreliant.think-freely.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [dpdk-announce] important design choices - statistics - ABI X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 08:38:47 -0000 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