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 0DA80A00E6 for ; Thu, 16 May 2019 16:08:57 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EB38F5F0D; Thu, 16 May 2019 16:08:55 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id 9C9862BCE for ; Thu, 16 May 2019 16:08:54 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 May 2019 07:08:53 -0700 X-ExtLoop1: 1 Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.96]) by orsmga003.jf.intel.com with SMTP; 16 May 2019 07:08:51 -0700 Received: by (sSMTP sendmail emulation); Thu, 16 May 2019 15:08:50 +0100 Date: Thu, 16 May 2019 15:08:49 +0100 From: Bruce Richardson To: David Harton Cc: dev@dpdk.org, beilei.xing@intel.com, qi.z.zhang@intel.com Message-ID: <20190516140849.GA625@bricha3-MOBL.ger.corp.intel.com> References: <20190515130512.6366-1-dharton@cisco.com> <20190515161346.33080-1-dharton@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190515161346.33080-1-dharton@cisco.com> 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 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. With this change, you can include my ack in v3. /Bruce Acked-by: Bruce Richardson