From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 365CE5A9C for ; Mon, 12 Jan 2015 19:16:10 +0100 (CET) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YAjX2-0002FA-Fb; Mon, 12 Jan 2015 13:16:06 -0500 Date: Mon, 12 Jan 2015 13:16:02 -0500 From: Neil Horman To: "Gonzalez Monroy, Sergio" Message-ID: <20150112181602.GD23467@hmsreliant.think-freely.org> References: <1421080446-19249-1-git-send-email-sergio.gonzalez.monroy@intel.com> <16150803.N0UIx0csq3@xps13> <91383E96CE459D47BCE92EFBF5CE73B004F26FD1@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91383E96CE459D47BCE92EFBF5CE73B004F26FD1@IRSMSX108.ger.corp.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH RFC 00/13] Update build system 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: Mon, 12 Jan 2015 18:16:10 -0000 On Mon, Jan 12, 2015 at 05:21:48PM +0000, Gonzalez Monroy, Sergio wrote: > Hi Thomas, > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > Sent: Monday, January 12, 2015 4:52 PM > > > > Hi Sergio, > > > > 2015-01-12 16:33, Sergio Gonzalez Monroy: > > > This patch series updates the DPDK build system. > > > > Thanks for proposing such rework. > > We need discussions on that topic. So I ask some questions below. > > > > > Following are the goals it tries to accomplish: > > > - Create a library containing core DPDK libraries (librte_eal, > > > librte_malloc, librte_mempool, librte_mbuf and librte_ring). > > > The idea of core libraries is to group those libraries that are > > > always required for any DPDK application. > > > > How is it better? Is it only to reduce dependencies lines? > > > In my opinion I think that there are a set of libraries that are always required > and therefore should be grouped as a single one. > Basically all apps and other DPDK libs would have dependencies to these core libraries. > > Aside from that, I don't think there is any difference. Note that this affects shared libraries, > with no difference for apps linked against static libs. > > > > - Remove config option to build a combined library. > > > > Why removing combined library? Is there people finding it helpful? > > > I don't think it makes sense from a shared library point of view, maybe it does for static? > For example, in the case of shared libraries I think we want to try to avoid the case where > we have an app linked against librte_dpdk.so, but such library may contain different libraries > depending on the options that were enabled when the lib was built. > > The core libraries would be that set of libraries that are always required for an app, and its content > would be fixed regardless of the option libraries (like acl, hash, distributor, etc.) > We could add more libraries as core if we think it is a better solution, but the goal should be that > librte_core.so contains the same libraries/API regardless of the system/arch. > FWIW, I think Sergios approach is likely a good balance. As he notes, mempool, eal, malloc and mbuf are needed for any dpdk application, and have interdepedencies, so it makes sense to link them as a single library. Everything else is optional. For static libraries, you can just add a few extra lines to the linker, but for DSO's you might want the option of not linking against a PMD, option to dynamically load it via the dlopen interface (using the -d option). Theres not much sense in adding those PMD DSO's to a single library just to save a few lines in the makefile there. This approach strikes a good balance, combining items that will have to be linked together anyway, and leaving everying else separate. Neil