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 22DFEA0096 for ; Sun, 7 Apr 2019 11:37:54 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 624572B95; Sun, 7 Apr 2019 11:37:52 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 87BDE5A; Sun, 7 Apr 2019 11:37:50 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2363A20D12; Sun, 7 Apr 2019 05:37:50 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 07 Apr 2019 05:37:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=uTj7q+OkQoouEg3J0tPNJjPsjJ1777VoJSmIQj2fV4s=; b=KxVmuyBNzuEh 0vG0TtiMWkrdBDGoKpnxIYYERzkg78d6+q1wHi/Q3jHnvWQFF2ZpGY3R8UApQv9O tjZDIdOg0jAszrqidDE75sWz4KwZmzJtS85BBXA56FiHndHuNwVUSDg8j00eceS6 S3h0wyG0VBDjKFnwr5F0djTaRVNDUS4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=uTj7q+OkQoouEg3J0tPNJjPsjJ1777VoJSmIQj2fV 4s=; b=R8+b6UyZKB1nHeXvrx2zgO1npBzO1Q/WTFr+hepJ1Y+ubm739W22/rjxo UXCelGtyBxtqPs5UE9Y5EqXx87TVHlMJmfSgtn5RKAak8nc10YlaD6uehY6ih341 W0Z2LwO0DQX4MY1V0cVhIsNhjUVSnLvieuBn070FPy3g0oANGc2fshmIf+bqjZbN hwNviY81cN2hBExqkWx/+Ss7Nse1K37Of+mSoz/vDl+aw6nwY7Xy25Cy/9hByleV ceEmevqQt++49/H3qLuu7LGolAlbvPsaltYCw2FcEM2AOJ6laqtIWRIn3X/QCioG BX2r6n+BoAm9H/T2+egN3yVTGhvPw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddugddukeculddtuddrgedutddrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvden ucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrg hlohhnrdhnvghtqeenucfkphepjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhep mhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 271CC10316; Sun, 7 Apr 2019 05:37:47 -0400 (EDT) From: Thomas Monjalon To: techboard@dpdk.org Cc: Ray Kinsella , Bruce Richardson , Luca Boccassi , "Burakov, Anatoly" , dev@dpdk.org, Kevin Traynor Date: Sun, 07 Apr 2019 11:37:45 +0200 Message-ID: <4860404.x3fkfWTsNL@xps> In-Reply-To: <1c2381f0-2438-f09e-8e55-7d20aa1cbec5@ashroe.eu> References: <20190404131028.GB1355@bricha3-MOBL.ger.corp.intel.com> <1c2381f0-2438-f09e-8e55-7d20aa1cbec5@ashroe.eu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" 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: <20190407093745.O6AMu5FcLVdrJixTtFTL_seVgsD47bhYOtoDJnpL2o8@z> 05/04/2019 15:25, Ray Kinsella: > On 04/04/2019 14:10, Bruce Richardson wrote: > > On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote: > >> On 04/04/2019 13:02, Luca Boccassi wrote: > >>> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote: > >>>> On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote: > >>>>> On 03-Apr-19 4:42 PM, Ray Kinsella wrote: > >> > > I would be too, with certain exceptions - rte_mbuf for one. Any structures > > that are used by applications cannot be made opaque, as apps do not want to > > pay the cost of having to call a function every time they want to access > > something from one of those structures. > > These the layout of these structures really must become sacrosanct. > As Stephen points out, there may be room for a one more change - fool me > once - to future poof the structure but after, that these structure will > become very hard to change. Yes, looks like a good plan. > > Thankfully for us, we have plenty of other structures that we can work on > > in the meantime that can be made private to avoid ABI breaks! :-) I suggest > > we work through those first, allowing us to hone our ABI-break avoidance > > skills. +1 to work on obvious cases first. I think we should not wait too much to improve mbuf with some dynamically registered fields, because it may be long to achieve such an important feature and make everybody happy. Note: we may have to sacrifice a few cycles for some features like distributor or IPsec.