From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id D81CCA6A for ; Wed, 4 Mar 2015 14:31:34 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 04 Mar 2015 05:31:32 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,687,1418112000"; d="scan'208";a="660307305" Received: from bricha3-mobl3.ger.corp.intel.com ([10.243.20.24]) by orsmga001.jf.intel.com with SMTP; 04 Mar 2015 05:31:31 -0800 Received: by (sSMTP sendmail emulation); Wed, 04 Mar 2015 13:31:29 +0025 Date: Wed, 4 Mar 2015 13:31:29 +0000 From: Bruce Richardson To: Panu Matilainen Message-ID: <20150304133129.GB544@bricha3-MOBL3> References: <1534932.rt5IAT3UZl@xps13> <54F6E6E3.50404@redhat.com> <20150304112805.GA5808@hmsreliant.think-freely.org> <20150304130848.GA544@bricha3-MOBL3> <54F7077C.1010504@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54F7077C.1010504@redhat.com> 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:31:35 -0000 On Wed, Mar 04, 2015 at 03:24:12PM +0200, Panu Matilainen wrote: > On 03/04/2015 03:08 PM, Bruce Richardson wrote: > >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? > > Given the opposition to defaulting to shared, another config file seems like > a fair compromise to me, whether "default" or something else. As for the > naming, one possibility would be calling it "shared", implying both > lowest-common denominator instruction set to be shareable across many > systems and shared libraries. > > - Panu - The naming scheme for configs is meant to be: "ARCH-MACHINE-EXECENV-TOOLCHAIN" as documented in the Getting Started Guide. "Default" has been used up till now to refer to the lowest common denominator instruction set supported, which for x86_64 is a core2 baseline, I believe. "shared" doesn't really fit into this naming scheme, and there is nothing to allow extra notes to be added to the name. Without changing this scheme, I would suggest we rename "default" to "generic", which I think is a slightly better term for it, and we set the "x86_64-generic-linuxapp-gcc" target to build shared libs. /Bruce