From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [RFC PATCH] replace DPDK config and build system Date: Thu, 8 Jun 2017 09:26:58 -0700 Message-ID: <20170608092658.6a4bfc5c@xeon-e3> References: <20170607104743.275149-1-bruce.richardson@intel.com> <20170607162617.00d009ff@xeon-e3> <20170608085901.GC58216@bricha3-MOBL3.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org To: Bruce Richardson Return-path: Received: from mail-pg0-f43.google.com (mail-pg0-f43.google.com [74.125.83.43]) by dpdk.org (Postfix) with ESMTP id 0BD2E11C5 for ; Thu, 8 Jun 2017 18:27:06 +0200 (CEST) Received: by mail-pg0-f43.google.com with SMTP id v18so17656179pgb.1 for ; Thu, 08 Jun 2017 09:27:06 -0700 (PDT) In-Reply-To: <20170608085901.GC58216@bricha3-MOBL3.ger.corp.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, 8 Jun 2017 09:59:01 +0100 Bruce Richardson wrote: > On Wed, Jun 07, 2017 at 04:26:17PM -0700, Stephen Hemminger wrote: > > On Wed, 7 Jun 2017 11:47:42 +0100 > > Bruce Richardson wrote: > > > > > The prototype is incomplete, but it does build a reasonable number of our > > > libraries, some unit tests, the i40e PMD and the testpmd binary, and I have > > > successfully passed traffic using testpmd from the build. Some things are > > > not fully correct, e.g. static builds aren't working right now, as I haven't > > > correctly done all the dependency tracking, I think, and the cpu flag > > > detection has issues. It also has only been tried on x86_64 linux, on a > > > couple of systems, so YMMV. However, I feel it's a reasonable enough start > > > point to show what we might be able to achieve. > > > > Remember that in many cases the build system and the target system are different. > > One of the problems with previous DPDK builds where build system was on bare metal > > but deployment target was on a more limited VM environment. I sweated through > > lots of pain on that. > > Yep, and I'm not going to claim that this is going to solve world hunger > here :-) or that switching is going to be easy. However, talking of > building and deploying on different targets, meson is designed to allow > cross-compilation, see for example the built-in objects for > "build_machine", "host_machine" and "target_machine": > http://mesonbuild.com/Reference-manual.html#build_machine-object > > Also, one thing I did add into this prototype was some build argument > support to test how that would work. By default, when you run meson, it > will set up the cflags to pass in -march=native, much as is done by our > default targets now. However, this is easily changed when doing your own > builds, for example, to do two different builds in different directories: > > $ meson native_build > ... > Checking for value of define "__PCLMUL__": 1 > Checking for value of define "__AVX__": 1 > Checking for value of define "__AVX2__": 1 > ... > > $ meson -Dmachine=ivybridge ivybridge_build > ... > Checking for value of define "__PCLMUL__": 1 > Checking for value of define "__AVX__": 1 > Checking for value of define "__AVX2__": > ... > > This way you can easily set up different builds for different machine > targets, with different instruction set levels, as seen from where the > second case above did not report AVX2 support. The project-specific > options are given in meson_options.txt. See also relevant section in > meson docs: http://mesonbuild.com/Build-options.html > > Regards, > /Bruce On a side note, it would be good to use the GCC extensions that allow building different versions of the same routine into one binary.