From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id DF0735683 for ; Wed, 4 Mar 2015 14:08:53 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 04 Mar 2015 05:08:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,687,1418112000"; d="scan'208";a="675005839" Received: from bricha3-mobl3.ger.corp.intel.com ([10.243.20.24]) by fmsmga001.fm.intel.com with SMTP; 04 Mar 2015 05:08:50 -0800 Received: by (sSMTP sendmail emulation); Wed, 04 Mar 2015 13:08:49 +0025 Date: Wed, 4 Mar 2015 13:08:49 +0000 From: Bruce Richardson To: Neil Horman Message-ID: <20150304130848.GA544@bricha3-MOBL3> References: <1534932.rt5IAT3UZl@xps13> <54F6E6E3.50404@redhat.com> <20150304112805.GA5808@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150304112805.GA5808@hmsreliant.think-freely.org> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] config: default to shared library 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: Wed, 04 Mar 2015 13:08:54 -0000 On Wed, Mar 04, 2015 at 06:28:05AM -0500, Neil Horman wrote: > On Wed, Mar 04, 2015 at 01:05:07PM +0200, Panu Matilainen wrote: > > On 03/04/2015 11:24 AM, Thomas Monjalon wrote: > > >Hi Panu, > > > > > >2015-03-04 08:17, Panu Matilainen: > > >>With symbol versioning its vital that developers test their code in > > >>shared library mode, otherwise we'll be playing "add the forgotten > > >>symbol export" from here to eternity. > > > > > >Yes we must improve the sanity checks. > > >A lot of options must be tested (or removed) and not only shared libs. > > >But the error you reported before (missing export of rte_eth_dev_release_port) > > >cannot be seen even with this patch. > > > > I know, I didn't say it would have directly caught it. It would've likely > > been found earlier though, if nothing else then in testing of the new > > librte_pmd_null which clearly nobody had tried in shared lib configuration. > > > This is accurate. The default config is a tool, in the sense that it leverages > the implicit testing of any users who are experimenting with the DPDK. Any > users out there using the DPDK test/example applications would have realized > something was amiss when the testpmd app refused to run with the null or pcap > pmd, since there was a missing symbol. That "social fuzzing" has value, but it > only works if the defaults are carefully selected. Currently, building for > shared libraries exposes more existing bugs than static libraries, and so we > should set that as our default so as to catch them. > > > >It means we need more tools. > > >Though, default configuration is not a tool. > > > > Yes, default config is not a tool, its a recommendation of sorts both for > > developers and users. It also tends to be the setup that is rarely broken > > because it happens to get the most testing :) > > > And it is a tool (see above). > > > > > > >>By defaulting to shared we should catch more of these cases early, > > >>but without taking away anybodys ability to build static. > > > > > >Shared libraries are convenient for distributions but have a performance > > >impact. I think that static build must remain the default choice. > > > > If utmost performance is the concern, isn't it reasonable to assume that users > in that demographic will customize their configuration to achieve that? No one > assumes that something is tuned to be perfect for their needs out of the box if > their needs are extreemely biased to a single quality. The best course of > action here is to set the default to be adventageous toward catching bugs, and > document the changes needed to bias for performance. > > > For distros, this is not a matter of *convenience*, its the only technically > > feasible choice. As I understand it, build for the "default" cpu rather than "native" is the only feasible choice also, so how about re-introducing a new defconfig file for "default" (or perhaps better name), where you have lowest-common denominator instruction-set and building for shared libraries? Would that work for everyone, or do people feel it would be too confusing to have more defconfig files available? /Bruce > > > > I didn't want to make the commit message into a shared library sermon, but > > if you look at the OSS landscape overall the common wisdom is that shared > > library benefits outweigh any performance impact by so much that static libs > > are almost nowhere to be found. I can change the text into a full-blown > > rationale why shared libraries should be the default if that makes any > > difference. > > > Embedded applications actually do make extensive use of static linking to try > achieve greater performance, but they tend to be proprietary, and as such are > the exception that proves the rule. Once an application itself becomes open > source, it biases toward shared libraries, because the minor performance impact > is well worth the increased manageability and security found in DSO's > > Acked-by: Neil Horman > > > - Panu - > > > >