From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 4AB436CC3 for ; Fri, 31 Aug 2018 15:39:38 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2018 06:39:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,311,1531810800"; d="scan'208";a="86108054" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.107]) by fmsmga001.fm.intel.com with SMTP; 31 Aug 2018 06:39:28 -0700 Received: by (sSMTP sendmail emulation); Fri, 31 Aug 2018 14:39:27 +0100 Date: Fri, 31 Aug 2018 14:39:27 +0100 From: Bruce Richardson To: Ilya Maximets Cc: dev@dpdk.org, Jingjing Wu , Konstantin Ananyev , Wenzhuo Lu , Beilei Xing , Qi Zhang , Xiao Wang Message-ID: <20180831133926.GB17496@bricha3-MOBL.ger.corp.intel.com> References: <20180831124358eucas1p22a0f8a7d0ae34dfad73b3b9e819366ec~P_LFZr9ro1664316643eucas1p2m@eucas1p2.samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180831124358eucas1p22a0f8a7d0ae34dfad73b3b9e819366ec~P_LFZr9ro1664316643eucas1p2m@eucas1p2.samsung.com> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [RFC 0/2] CPU non-blocking delay X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 13:39:38 -0000 On Fri, Aug 31, 2018 at 03:45:15PM +0300, Ilya Maximets wrote: > Sending as RFC because I failed to force meson to > build without deprecation warnings. I tried a lot > of different combinations of 'allow_experimental_apis' > and '-DALLOW_EXPERIMENTAL_APIS' without success. > Any help appreciated. > See patch: http://patches.dpdk.org/patch/44129/ Basically, the experimental_apis setting was not getting passed through and used by the base code libraries when set at the higher level, since they were being built individually by the respective base/meson.build files, rather than by the main driver build loop. Putting in an explicit check for the value in the base code files should make your life easier here. You just need to ensure that the "allow_experimental_apis" setting is set *before* the call to "subdir(base)" e.g. in ixgbe, it's currently after and needs to be moved by your patchset. Regards, /Bruce PS: I also notice that i40e is using the experimental APIs cflags directly, rather than the variable, I'll have to fix that in a later patch.