From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id F21794D27; Fri, 10 May 2019 15:43:40 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2019 06:43:39 -0700 X-ExtLoop1: 1 Received: from bricha3-mobl.ger.corp.intel.com ([10.252.21.38]) by fmsmga005.fm.intel.com with SMTP; 10 May 2019 06:43:35 -0700 Received: by (sSMTP sendmail emulation); Fri, 10 May 2019 14:43:34 +0100 Date: Fri, 10 May 2019 14:43:33 +0100 From: Bruce Richardson To: Ray Kinsella Cc: "techboard@dpdk.org" , Billy McFall , Thomas F Herbert , dpdk-dev , Luca Boccassi , ndas@suse.de, Christian Ehrhardt , "Stokes, Ian" Message-ID: <20190510134333.GA87@bricha3-MOBL.ger.corp.intel.com> References: <80c4f1df-da68-520e-d47d-b4ccaeedb69f@ashroe.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80c4f1df-da68-520e-d47d-b4ccaeedb69f@ashroe.eu> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [dpdk-techboard] Discussion on the OS Packaging of DPDK 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: Fri, 10 May 2019 13:43:41 -0000 On Fri, May 10, 2019 at 02:01:54PM +0100, Ray Kinsella wrote: > ( from the undersigned ) > > Hi folks, > > In light of the renewed community discussion on API Stability > (https://mails.dpdk.org/archives/dev/2019-April/128969.html), now is > right time to open a discussion on how DPDK is distributed and updated. > > To this point in time, DPDK's primary distribution method has been as > source code distributed as a tarball from dpdk.org. This distribution > method, in addition to abi instability and the dpdk's build system > default behaviour of static linking have all encouraged the "tight > coupling" or "vendorization" of DPDK. > > These behaviours makes it a challenge for end users, those deploying > applications based on DPDK, to manage and update DPDK in a method > consistent with other system libraries. For instance, an end user may > not have any idea which version of DPDK a consuming application may be > using and if this DPDK version is reasonably up to date with the latest > upstream version. This would not be the case for other system libraries > such as glibc. > > For these reasons, now is the right time for DPDK to embrace standard > Operating System practices for distributing and updating system > libraries. The current industry push towards cloud and > cloud-friendliness make addressing this issue all the more timely. > > To this end, the following proposals are made for discussion at the next > techboard meeting:- > > * The primary method of distributing DPDK should be as an operating > system package, dpdk.org should be updated to reflect this reality and > provide OS installation details in place of tarball downloads. I really like that idea. Since DPDK is available in distro packages that should be the first port of call for users getting DPDK. Since it's just a doc update - as I understand it anyway - it should be easy to implement if agreed, which is a nice bonus. > > * DPDK should build as a dynamic shared libraries by default, to > encourage loose coupling with consuming applications. > To a certain extent, this only applies with the "make" build system, which is due to be deprecated in the next release and removed sometime next year. With builds done with meson and ninja, both shared and static libraries are always built. The default setting though remains as "static" which applies only to the linking of applications as part of the DPDK build. This default was set mainly for legacy purposes, but also has benefits for us developers working on DPDK, since we don't need to worry about setting LD_LIBRARY_PATH and EAL_PMD_PATH values for running applications we've built. Therefore, I'm not sure of the value of changing the default here - it's certainly less important than the default in the "make" build system where only one library type at a time was built. > * Future guarantees around ABI/API stability should be provided, so that > OS packagers can offer safe upgrade paths for consuming applications. > > Look forward to the discussion, thank you, > > Luca Boccassi, Debian maintainer and DPDK LTS maintainer > Nirmoy Das, SUSE dpdk maintainer > Christian Ehrhardt, Ubuntu maintainer and former DPDK LTS maintainer > Ian Stokes, Open vSwitch maintainer > Tom Herbert, FD.io/VPP contributor. CentOS NFV SIG chair. > Billy McFall, DPDK consumer and FD.io/VPP Contributor > Ray Kinsella, DPDK and FD.io Contributor Thanks all for kicking off this discussion. /Bruce 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 F0D68A0096 for ; Fri, 10 May 2019 15:43:44 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2B11C4F93; Fri, 10 May 2019 15:43:43 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id F21794D27; Fri, 10 May 2019 15:43:40 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2019 06:43:39 -0700 X-ExtLoop1: 1 Received: from bricha3-mobl.ger.corp.intel.com ([10.252.21.38]) by fmsmga005.fm.intel.com with SMTP; 10 May 2019 06:43:35 -0700 Received: by (sSMTP sendmail emulation); Fri, 10 May 2019 14:43:34 +0100 Date: Fri, 10 May 2019 14:43:33 +0100 From: Bruce Richardson To: Ray Kinsella Cc: "techboard@dpdk.org" , Billy McFall , Thomas F Herbert , dpdk-dev , Luca Boccassi , ndas@suse.de, Christian Ehrhardt , "Stokes, Ian" Message-ID: <20190510134333.GA87@bricha3-MOBL.ger.corp.intel.com> References: <80c4f1df-da68-520e-d47d-b4ccaeedb69f@ashroe.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <80c4f1df-da68-520e-d47d-b4ccaeedb69f@ashroe.eu> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [dpdk-techboard] Discussion on the OS Packaging of DPDK 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: <20190510134333.k4BzLO89m2yMDVQODAHOsevNmJSyvDOUyTDntbVlXAs@z> On Fri, May 10, 2019 at 02:01:54PM +0100, Ray Kinsella wrote: > ( from the undersigned ) > > Hi folks, > > In light of the renewed community discussion on API Stability > (https://mails.dpdk.org/archives/dev/2019-April/128969.html), now is > right time to open a discussion on how DPDK is distributed and updated. > > To this point in time, DPDK's primary distribution method has been as > source code distributed as a tarball from dpdk.org. This distribution > method, in addition to abi instability and the dpdk's build system > default behaviour of static linking have all encouraged the "tight > coupling" or "vendorization" of DPDK. > > These behaviours makes it a challenge for end users, those deploying > applications based on DPDK, to manage and update DPDK in a method > consistent with other system libraries. For instance, an end user may > not have any idea which version of DPDK a consuming application may be > using and if this DPDK version is reasonably up to date with the latest > upstream version. This would not be the case for other system libraries > such as glibc. > > For these reasons, now is the right time for DPDK to embrace standard > Operating System practices for distributing and updating system > libraries. The current industry push towards cloud and > cloud-friendliness make addressing this issue all the more timely. > > To this end, the following proposals are made for discussion at the next > techboard meeting:- > > * The primary method of distributing DPDK should be as an operating > system package, dpdk.org should be updated to reflect this reality and > provide OS installation details in place of tarball downloads. I really like that idea. Since DPDK is available in distro packages that should be the first port of call for users getting DPDK. Since it's just a doc update - as I understand it anyway - it should be easy to implement if agreed, which is a nice bonus. > > * DPDK should build as a dynamic shared libraries by default, to > encourage loose coupling with consuming applications. > To a certain extent, this only applies with the "make" build system, which is due to be deprecated in the next release and removed sometime next year. With builds done with meson and ninja, both shared and static libraries are always built. The default setting though remains as "static" which applies only to the linking of applications as part of the DPDK build. This default was set mainly for legacy purposes, but also has benefits for us developers working on DPDK, since we don't need to worry about setting LD_LIBRARY_PATH and EAL_PMD_PATH values for running applications we've built. Therefore, I'm not sure of the value of changing the default here - it's certainly less important than the default in the "make" build system where only one library type at a time was built. > * Future guarantees around ABI/API stability should be provided, so that > OS packagers can offer safe upgrade paths for consuming applications. > > Look forward to the discussion, thank you, > > Luca Boccassi, Debian maintainer and DPDK LTS maintainer > Nirmoy Das, SUSE dpdk maintainer > Christian Ehrhardt, Ubuntu maintainer and former DPDK LTS maintainer > Ian Stokes, Open vSwitch maintainer > Tom Herbert, FD.io/VPP contributor. CentOS NFV SIG chair. > Billy McFall, DPDK consumer and FD.io/VPP Contributor > Ray Kinsella, DPDK and FD.io Contributor Thanks all for kicking off this discussion. /Bruce