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 A90A85958 for ; Sat, 1 Nov 2014 13:44:45 +0100 (CET) Received: from [2001:470:8:a08:215:ff:fecc:4872] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1XkYBa-0001Bd-I2; Sat, 01 Nov 2014 08:53:47 -0400 Date: Sat, 1 Nov 2014 08:53:36 -0400 From: Neil Horman To: "Gonzalez Monroy, Sergio" Message-ID: <20141101125336.GA9971@localhost.localdomain> References: <91383E96CE459D47BCE92EFBF5CE73B004E97FFB@IRSMSX108.ger.corp.intel.com> <20141030205000.GA9956@mhcomputing.net> <91383E96CE459D47BCE92EFBF5CE73B004E9AAFB@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91383E96CE459D47BCE92EFBF5CE73B004E9AAFB@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] Update/Improve 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: Sat, 01 Nov 2014 12:44:46 -0000 On Fri, Oct 31, 2014 at 10:45:07AM +0000, Gonzalez Monroy, Sergio wrote: > > From: Matthew Hall [mailto:mhall@mhcomputing.net] > > Sent: Thursday, October 30, 2014 8:50 PM > > > > On Thu, Oct 30, 2014 at 09:18:23AM +0000, Gonzalez Monroy, Sergio wrote: > > > I would say that D) is a good balance, although not being the simplest. > > > > A, or D. Depending on things such as, "If you run the DPDK on Random > > Platform X," where X could be something like Power CPUs or other weird > > stuff, will all of the things needed for the Combined Lib 1) be compilable, 2) > > be able to load w/o errors. > > > > For example, I could see probe ctor functions from various PMD's blowing up > > on unsupported hardware. Like how the rte_pmd_virtio had issues when I > > tried it on my VM system. > > > IMHO the underlying issue was that virtio was unsupported for that platform. > What I am trying to say is that any app built against a combined shared lib or combined/separated > static lib will have that same issue if the feature/PMD is unsupported for the platform. > In the virtio case, building against combined shared or combined/separated static DPDK libs > would have the same result because the virtio PMD would be in the app. > > > If we think we can make sure no platform specific stuff breaks when it ends > > up in Combined Lib A then A is probably the easiest for all. > > > I agree, a combined lib would simplify all app/lib linking, making it easier for the user and less error prone. > > One of the downsides that comes to mind is a flow work (I think you mentioned it) where you > have multiple apps building against a single DPDK copy, and each app uses different features/PMDs. > In that scenario, having separated libs would make your life easier as you would not need to have > multiple DPDK copies customized for each app, giving you the flexibility to hand pick each lib you > want to include into your app. > That flow work still presents some issues as they may be features that are incompatible between > each other and would need to be in different DPDK copies. > It might be reasonable here to consider pmd's separately from the rest of the system, given that, they are supposed be built as isolated libraries that don't export any symbols. Some pmd's break that assumption, but they should really be fixed anyway. If you did that, you can build the dpdk as a single library, and build the pmds as separate libraries (shared or static). Neil > Regards, > Sergio > > > Matthew. >