From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 5998CB369 for ; Thu, 31 Jul 2014 22:08:27 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1XCwg7-0000WN-KL; Thu, 31 Jul 2014 16:10:25 -0400 Date: Thu, 31 Jul 2014 16:10:18 -0400 From: Neil Horman To: Bruce Richardson Message-ID: <20140731201018.GE20718@hmsreliant.think-freely.org> References: <1406665466-29654-1-git-send-email-nhorman@tuxdriver.com> <20140730210920.GB6420@localhost.localdomain> <20140731131351.GA20718@hmsreliant.think-freely.org> <5766264.li3nkTmgY6@xps13> <20140731143228.GB20718@hmsreliant.think-freely.org> <20140731181032.GC20718@hmsreliant.think-freely.org> <20140731183631.GC6420@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140731183631.GC6420@localhost.localdomain> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/2] dpdk: Allow for dynamic enablement of some isolated features 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: Thu, 31 Jul 2014 20:08:27 -0000 On Thu, Jul 31, 2014 at 11:36:32AM -0700, Bruce Richardson wrote: > Thu, Jul 31, 2014 at 02:10:32PM -0400, Neil Horman wrote: > > On Thu, Jul 31, 2014 at 10:32:28AM -0400, Neil Horman wrote: > > > On Thu, Jul 31, 2014 at 03:26:45PM +0200, Thomas Monjalon wrote: > > > > 2014-07-31 09:13, Neil Horman: > > > > > On Wed, Jul 30, 2014 at 02:09:20PM -0700, Bruce Richardson wrote: > > > > > > On Wed, Jul 30, 2014 at 03:28:44PM -0400, Neil Horman wrote: > > > > > > > On Wed, Jul 30, 2014 at 11:59:03AM -0700, Bruce Richardson wrote: > > > > > > > > On Tue, Jul 29, 2014 at 04:24:24PM -0400, Neil Horman wrote: > > > > > > > > > Hey all- > > With regards to the general approach for runtime detection of software > functions, I wonder if something like this can be handled by the > packaging system? Is it possible to ship out a set of shared libs > compiled up for different instruction sets, and then at rpm install > time, symlink the appropriate library? This would push the whole issue > of detection of code paths outside of code, work across all our > libraries and ensure each user got the best performance they could get > form a binary? > Has something like this been done before? The building of all the > libraries could be scripted easy enough, just do multiple builds using > different EXTRA_CFLAGS each time, and move and rename the .so's after > each run. > Sorry, I missed this in my last reply. In answer to your question, the short version is that such a thing is roughly possible from a packaging standpoint, but completely unworkable from a distribution standpoint. We could certainly build the dpdk multiple times and rename all the shared objects to some variant name representative of the optimzations we build in for certain cpu flags, but then we woudl be shipping X versions of the dpdk, and any appilcation (say OVS that made use of the dpdk would need to provide a version linked against each variant to be useful when making a product, and each end user would need to manually select (or run a script to select) which variant is most optimized for the system at hand. Its just not a reasonable way to package a library. When pacaging software, the only consideration given to code variance at pacakge time is architecture (x86/x86_64/ppc/s390/etc). If you install a package for your a given architecture, its expected to run on that architecture. Optional code paths are just that, optional, and executed based on run time tests. Its a requirement that we build for the lowest common demoniator system that is supported, and enable accelerative code paths optionally at run time when the cpu indicates support for them. Neil