From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 9280CA0096 for ; Tue, 4 Jun 2019 18:25:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B2C3E1BB82; Tue, 4 Jun 2019 18:25:38 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 3FBED1BB3B for ; Tue, 4 Jun 2019 18:25:37 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jun 2019 09:25:36 -0700 X-ExtLoop1: 1 Received: from bricha3-mobl.ger.corp.intel.com ([10.251.95.106]) by fmsmga006.fm.intel.com with SMTP; 04 Jun 2019 09:25:33 -0700 Received: by (sSMTP sendmail emulation); Tue, 04 Jun 2019 17:25:33 +0100 Date: Tue, 4 Jun 2019 17:25:32 +0100 From: Bruce Richardson To: Ferruh Yigit Cc: David Harton , dev@dpdk.org, beilei.xing@intel.com, qi.z.zhang@intel.com Message-ID: <20190604162532.GA1339@bricha3-MOBL.ger.corp.intel.com> References: <20190515130512.6366-1-dharton@cisco.com> <20190515161346.33080-1-dharton@cisco.com> <20190516140849.GA625@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH v2] net/i40e: Eliminate weak symbols in i40e_rxtx.c 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Jun 04, 2019 at 04:59:47PM +0100, Ferruh Yigit wrote: > On 5/16/2019 3:08 PM, Bruce Richardson wrote: > > On Wed, May 15, 2019 at 12:13:46PM -0400, David Harton wrote: > >> Use of weak symbols can hide makefile errors especially when > >> custom makefiles are used. Removing the use of weak symbols > >> to avoid a stub function being linked in production code. > >> > >> Signed-off-by: David Harton > >> --- > >> > >> v2 - added CC_AVX2_SUPPORT check to code enabling avx2 vectors > >> > > Testing a few compiles here, this breaks when vector mode is disabled, > > because it's possible that CC_AVX2_SUPPORT=1 when VECTOR=n. I'd suggest > > adding "ifeq ($(CONFIG_RTE_LIBRTE_I40E_INC_VECTOR),y) ... endif" around the > > block in the makefile checking for AVX2 support, so that we never set AVX2 > > unless we have vector support. > > Concern is this is pushing vectorization support more to compile time > configuration. Do we really have to select if to use vector PMD or not in > compile time? > > Can't we get rid of the 'CONFIG_RTE_LIBRTE_I40E_INC_VECTOR' config option > completely? As done in the ICE driver now. > > Isn't it better to compile vectorization support in as much as possible and do > the vector or scalar path selection in runtime, this patch may prevent us to do > that, weak functions enables us being more dynamic. > Weak functions are not needed to do the runtime selection - they are needed for compilation only. They have the downside of potentially causing runtime problems due to a mis-configured compile, which is only seen later by the end user. By using real functions rather than weak functions it means that any mischosen compile paths will flag a compile error rather than silently succeeding and then accidentally using an incorrect function at runtime.