From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id 56F035952 for ; Wed, 4 Mar 2015 14:57:01 +0100 (CET) Received: by wggx12 with SMTP id x12so46784924wgg.11 for ; Wed, 04 Mar 2015 05:57:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=fsEn1P4Usxwf+BifTFdDm5/UoPrqD+Xa6VNlqHfTnIQ=; b=Sac5r3I3gzs/nhdAoMVKs5uXEqXDMMoE87Y2V2yN4kue+hN4anXEaYj+Ip52yu3+Ih 7iNtku7mXSbW7oJCKQ4nD1ZKjJoDFcyK8J3xEfAGXb0NC+0ulM3TYmZPMNFXG4t54UqE z+yWJ2K1sYT5E8xLfIMNM2BljPHkNtAJjA10wsYDYldPTg1DhIYvwOn9OV/DkoFhnOWe uDDkqs7yWpCO8pRwu8xgCX2HP7TCHitjZ+NwJ5nr+jiZonX9rTkTPgjwT78CROWYqRFu ZqKh25xJTKnkSAKaLJelAV8m02jdzywpXuDmG2KXIXE+U0vUaCYHT80IrtQpc1H/wi6j VBig== X-Gm-Message-State: ALoCoQkVsDTp/qldYFpSzJcwVJhgIIDZLVXhX9Y19Vpdadi5HTd46o5cVg7YCANCGZaBdjisUY9j X-Received: by 10.181.11.136 with SMTP id ei8mr13393260wid.10.1425477421136; Wed, 04 Mar 2015 05:57:01 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id v9sm24439488wib.0.2015.03.04.05.56.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 05:57:00 -0800 (PST) From: Thomas Monjalon To: Bruce Richardson Date: Wed, 04 Mar 2015 14:56:26 +0100 Message-ID: <2014621.ggSAPkkMEP@xps13> Organization: 6WIND User-Agent: KMail/4.14.4 (Linux/3.18.4-1-ARCH; KDE/4.14.4; x86_64; ; ) In-Reply-To: <20150304134911.GC544@bricha3-MOBL3> References: <54F70B9D.7040903@redhat.com> <20150304134911.GC544@bricha3-MOBL3> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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:57:01 -0000 2015-03-04 13:49, Bruce Richardson: > On Wed, Mar 04, 2015 at 03:41:49PM +0200, Panu Matilainen wrote: > > 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. > > Ah, yes, forgotten about that one! :-) off-topic: I think we should remove "#ifdef RTE_LIBRTE_IVSHMEM" in EAL and then remove defconfig_x86_64-ivshmem-linuxapp-*. > > >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. +1 for x86_64-generic-linuxapp-gcc