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 64B18A6A for ; Wed, 4 Mar 2015 14:24:16 +0100 (CET) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t24DOEob020686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 4 Mar 2015 08:24:14 -0500 Received: from localhost.localdomain (vpn1-4-127.ams2.redhat.com [10.36.4.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t24DODQh019715; Wed, 4 Mar 2015 08:24:13 -0500 Message-ID: <54F7077C.1010504@redhat.com> Date: Wed, 04 Mar 2015 15:24:12 +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 , Neil Horman References: <1534932.rt5IAT3UZl@xps13> <54F6E6E3.50404@redhat.com> <20150304112805.GA5808@hmsreliant.think-freely.org> <20150304130848.GA544@bricha3-MOBL3> In-Reply-To: <20150304130848.GA544@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.27 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:24:17 -0000 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 -