From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bruce.richardson@intel.com>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
 by dpdk.org (Postfix) with ESMTP id D81CCA6A
 for <dev@dpdk.org>; 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 <bruce.richardson@intel.com>
To: Panu Matilainen <pmatilai@redhat.com>
Message-ID: <20150304133129.GB544@bricha3-MOBL3>
References: <c826d83d78b0d24d0d840775b6ff6afaa848320c.1425449872.git.pmatilai@redhat.com>
 <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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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