From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 16FC25B20 for ; Tue, 30 Apr 2019 10:52:26 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7D9DA22460; Tue, 30 Apr 2019 04:52:25 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 30 Apr 2019 04:52:25 -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=nUEa5SaXvuT+Np/8yXme5nxPPdO5Qf/K8sqatP2ccZA=; b=kxFTDMZwYF8J 9k1jh3JxT8HnZysFijK6/Wt0GGWZUgcF72JDH6dzUntq0ZNSSk5KD36xlSO3LrzG S+cHIflWfU4oELbsliVSDdWi8IdAJ8Ng3KOhaUdSTsudZ+OQzk9JsuduIIlu4Nll iyEP3/pON1/pF31yNILrsQC4vNyFcKY= 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=nUEa5SaXvuT+Np/8yXme5nxPPdO5Qf/K8sqatP2cc ZA=; b=n7MIVBMdxX/u8bQqQSqCz8+LWfkCJUEsOJOBEiyieWOe6IxiOf7t41OJF YhbEKSVRoPb+JZg5yfLGzDs6H4DR73e1+Wo9a1HmK7FB82tFmQvKmPJancGRIrvB 7YnW6VJJTCyZLv6Lcy1kZ6c8txku3bKdbQMoo8h1wf+Bcv3ofmHSdfuF0UpB0YBY jPytZg/11qxszQ51aM/uJtFS1lRMxEIJsmFe4rYggaoGGa78CksPWn6aTy3rIGDG 87gDSjMGVx915eXCJCcPF1TWNastUjPEG1yXsJ9O5cum06R0PmiaQ9IWUsvQhlKI P6p37XQSUEFxtWQ2Y9OjYRN83Y5Pg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieeggddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinhepohhrrdhnvghtnecukfhppeejjedrudefgedrvddtfedrudekgeenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlh hushhtvghrufhiiigvpedt 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 72866103C8; Tue, 30 Apr 2019 04:52:23 -0400 (EDT) From: Thomas Monjalon To: dev@dpdk.org Cc: Ray Kinsella , "Burakov, Anatoly" , Bruce Richardson , Honnappa Nagarahalli , Stephen Hemminger , "Ananyev, Konstantin" , nd Date: Tue, 30 Apr 2019 10:52:22 +0200 Message-ID: <2689803.gVaTpSEii3@xps> In-Reply-To: <74f22653-c0e8-3b4d-20e3-5d30d5a693bb@ashroe.eu> References: <43980ebb-ef8a-6e6d-c152-cf6160ace892@intel.com> <74f22653-c0e8-3b4d-20e3-5d30d5a693bb@ashroe.eu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] ABI and inline functions 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: , X-List-Received-Date: Tue, 30 Apr 2019 08:52:26 -0000 24/04/2019 14:22, Ray Kinsella: > On 24/04/2019 12:08, Burakov, Anatoly wrote: > > To me, part of the problem is that DPDK is an "everything and the > > kitchen sink" kind of library where there is a bunch of drivers, a whole > > quasi-OS layer of dealing with hardware in a cross-platform manner, a > > separate memory management system, a bunch of libraries such as hash/lpm > > tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a > > library" would concentrate on doing one thing well. DPDK, on the other > > hand, tries to do *everything* well. The sheer breadth of DPDK's scope > > is, i think, contributing to the breakages. If you keep 99% of your > > libraries stable between version, but there's a small ABI tweak in an > > LPM library, the entire DPDK stability gets invalidated. Yes, that's why we keep the split in libraries. So we can update LPM library version while keeping the same ethdev version to allow applications to load the shared library of the same name without any re-compilation. In this case, the need for re-compilation is only for applications using LPM. But this model is not convenient for distributions because they manage DPDK as one package. It means they have to re-compile all applications if one LPM ABI is broken, even if it is experimental. Should the libraries be split in packages? > Well I guess DPDK is no more complex than Java or .NET Framework in that > respect, as these also feature OS-layers, memory management systems, > application frameworks, primitives etc but do manage to give their > consumers strong guarantee's on API stability. Clearly ABI stability has > a no meaning when you always being JIT compiled. > > I understand that doing everything right the first time, allowing for > future evolution, while keep ABI/APIs relatively stable is a tough ask. > > I would propose that API's marked as "experimental" be given greater > freedom to change to give time of API's to bake, so they don't need to > be always "right first time", that there is wriggle room for these. As said above, experimental level does not solve ABI stability. If we break an experimental API, the ABI is broken, requiring to re-compile the application. > I would also propose more use of ABI Versioning to enable evolution of > DPDK while preserving backward compatibility. Yes, if all other obvious versioning issues are solved, we can walk the extra mile of better using ABI versioning. > > Perhaps limiting DPDK's scope would help with this as well. > > I agree. Yes, either split the project in more limited scope areas, or split the packages. 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 40C95A0679 for ; Tue, 30 Apr 2019 10:52:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0FAEB5B40; Tue, 30 Apr 2019 10:52:27 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 16FC25B20 for ; Tue, 30 Apr 2019 10:52:26 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7D9DA22460; Tue, 30 Apr 2019 04:52:25 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 30 Apr 2019 04:52:25 -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=nUEa5SaXvuT+Np/8yXme5nxPPdO5Qf/K8sqatP2ccZA=; b=kxFTDMZwYF8J 9k1jh3JxT8HnZysFijK6/Wt0GGWZUgcF72JDH6dzUntq0ZNSSk5KD36xlSO3LrzG S+cHIflWfU4oELbsliVSDdWi8IdAJ8Ng3KOhaUdSTsudZ+OQzk9JsuduIIlu4Nll iyEP3/pON1/pF31yNILrsQC4vNyFcKY= 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=nUEa5SaXvuT+Np/8yXme5nxPPdO5Qf/K8sqatP2cc ZA=; b=n7MIVBMdxX/u8bQqQSqCz8+LWfkCJUEsOJOBEiyieWOe6IxiOf7t41OJF YhbEKSVRoPb+JZg5yfLGzDs6H4DR73e1+Wo9a1HmK7FB82tFmQvKmPJancGRIrvB 7YnW6VJJTCyZLv6Lcy1kZ6c8txku3bKdbQMoo8h1wf+Bcv3ofmHSdfuF0UpB0YBY jPytZg/11qxszQ51aM/uJtFS1lRMxEIJsmFe4rYggaoGGa78CksPWn6aTy3rIGDG 87gDSjMGVx915eXCJCcPF1TWNastUjPEG1yXsJ9O5cum06R0PmiaQ9IWUsvQhlKI P6p37XQSUEFxtWQ2Y9OjYRN83Y5Pg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieeggddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinhepohhrrdhnvghtnecukfhppeejjedrudefgedrvddtfedrudekgeenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlh hushhtvghrufhiiigvpedt 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 72866103C8; Tue, 30 Apr 2019 04:52:23 -0400 (EDT) From: Thomas Monjalon To: dev@dpdk.org Cc: Ray Kinsella , "Burakov, Anatoly" , Bruce Richardson , Honnappa Nagarahalli , Stephen Hemminger , "Ananyev, Konstantin" , nd Date: Tue, 30 Apr 2019 10:52:22 +0200 Message-ID: <2689803.gVaTpSEii3@xps> In-Reply-To: <74f22653-c0e8-3b4d-20e3-5d30d5a693bb@ashroe.eu> References: <43980ebb-ef8a-6e6d-c152-cf6160ace892@intel.com> <74f22653-c0e8-3b4d-20e3-5d30d5a693bb@ashroe.eu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] ABI and inline functions 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: <20190430085222.qFS4dGlWzLvFCAo3KZKt5qx11OgzT3CmTZuac0u0rcU@z> 24/04/2019 14:22, Ray Kinsella: > On 24/04/2019 12:08, Burakov, Anatoly wrote: > > To me, part of the problem is that DPDK is an "everything and the > > kitchen sink" kind of library where there is a bunch of drivers, a whole > > quasi-OS layer of dealing with hardware in a cross-platform manner, a > > separate memory management system, a bunch of libraries such as hash/lpm > > tables, plus there's QOS, IP Pipeline, flow stuff, etc. - normally, "a > > library" would concentrate on doing one thing well. DPDK, on the other > > hand, tries to do *everything* well. The sheer breadth of DPDK's scope > > is, i think, contributing to the breakages. If you keep 99% of your > > libraries stable between version, but there's a small ABI tweak in an > > LPM library, the entire DPDK stability gets invalidated. Yes, that's why we keep the split in libraries. So we can update LPM library version while keeping the same ethdev version to allow applications to load the shared library of the same name without any re-compilation. In this case, the need for re-compilation is only for applications using LPM. But this model is not convenient for distributions because they manage DPDK as one package. It means they have to re-compile all applications if one LPM ABI is broken, even if it is experimental. Should the libraries be split in packages? > Well I guess DPDK is no more complex than Java or .NET Framework in that > respect, as these also feature OS-layers, memory management systems, > application frameworks, primitives etc but do manage to give their > consumers strong guarantee's on API stability. Clearly ABI stability has > a no meaning when you always being JIT compiled. > > I understand that doing everything right the first time, allowing for > future evolution, while keep ABI/APIs relatively stable is a tough ask. > > I would propose that API's marked as "experimental" be given greater > freedom to change to give time of API's to bake, so they don't need to > be always "right first time", that there is wriggle room for these. As said above, experimental level does not solve ABI stability. If we break an experimental API, the ABI is broken, requiring to re-compile the application. > I would also propose more use of ABI Versioning to enable evolution of > DPDK while preserving backward compatibility. Yes, if all other obvious versioning issues are solved, we can walk the extra mile of better using ABI versioning. > > Perhaps limiting DPDK's scope would help with this as well. > > I agree. Yes, either split the project in more limited scope areas, or split the packages.