From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id E6D8111C5 for ; Wed, 4 Mar 2015 14:41:57 +0100 (CET) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t24DfqUQ002908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 4 Mar 2015 08:41:56 -0500 Received: from localhost.localdomain (vpn1-4-127.ams2.redhat.com [10.36.4.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t24Dfodh028361; Wed, 4 Mar 2015 08:41:50 -0500 Message-ID: <54F70B9D.7040903@redhat.com> Date: Wed, 04 Mar 2015 15:41:49 +0200 From: Panu Matilainen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Bruce Richardson References: <1534932.rt5IAT3UZl@xps13> <54F6E6E3.50404@redhat.com> <20150304112805.GA5808@hmsreliant.think-freely.org> <20150304130848.GA544@bricha3-MOBL3> <54F7077C.1010504@redhat.com> <20150304133129.GB544@bricha3-MOBL3> In-Reply-To: <20150304133129.GB544@bricha3-MOBL3> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 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:41:58 -0000 On 03/04/2015 03:31 PM, Bruce Richardson wrote: > 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. Right, but then there's "ivshmem" that doesn't fit that description either AFAICS. > 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. Works for me. It is indeed more descriptive than either "default" or "shared" for the purpose. - Panu -