From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <tim.o'driscoll@intel.com> Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 506AFC76A for <dev@dpdk.org>; Thu, 18 Jun 2015 18:55:49 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP; 18 Jun 2015 09:55:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,640,1427785200"; d="scan'208";a="713402457" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by orsmga001.jf.intel.com with ESMTP; 18 Jun 2015 09:55:46 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.117]) by IRSMSX108.ger.corp.intel.com ([169.254.11.201]) with mapi id 14.03.0224.002; Thu, 18 Jun 2015 17:55:46 +0100 From: "O'Driscoll, Tim" <tim.o'driscoll@intel.com> To: Thomas Monjalon <thomas.monjalon@6wind.com>, "dev@dpdk.org" <dev@dpdk.org> Thread-Topic: [dpdk-announce] important design choices - statistics - ABI Thread-Index: AQHQqIyFFePoIMplbUqAkjPR6P8mxZ2yeikw Date: Thu, 18 Jun 2015 16:55:45 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA54D6D24C@IRSMSX102.ger.corp.intel.com> References: <9092314.MoyqUJ5VU2@xps13> In-Reply-To: <9092314.MoyqUJ5VU2@xps13> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Thu, 18 Jun 2015 16:55:49 -0000 > -----Original Message----- > From: announce [mailto:announce-bounces@dpdk.org] On Behalf Of Thomas > Monjalon > Sent: Wednesday, June 17, 2015 12:30 AM > To: announce@dpdk.org > Subject: [dpdk-announce] important design choices - statistics - ABI >=20 > Hi all, >=20 > 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 > =3D8461 >=20 > 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 yet well > documented: > http://dpdk.org/ml/archives/dev/2015-June/019357.html >=20 > Thanks for your attention and your participation in these important > choices. There's been some good discussion on the ABI policy in various responses to= this email. I think we now need to reach a conclusion on how we're going t= o proceed for the 2.1 release. Then, we can have further discussion on the = use of versioning or other methods for avoiding the problem in future. For the 2.1 release, I think we should agree to make patches that change th= e ABI controllable via a compile-time option. I like Olivier's proposal on = using a single option (CONFIG_RTE_NEXT_ABI) to control all of these changes= instead of a separate option per patch set (see http://dpdk.org/ml/archive= s/dev/2015-June/019147.html), so I think we should rework the affected patc= h sets to use that approach for 2.1. Tim