From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 120D1A046B for ; Fri, 28 Jun 2019 15:38:27 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E43A237B0; Fri, 28 Jun 2019 15:38:25 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 8DA5E2AB for ; Fri, 28 Jun 2019 15:38:24 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jun 2019 06:38:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,427,1557212400"; d="scan'208";a="183687221" Received: from vmedvedk-mobl.ger.corp.intel.com (HELO [10.237.220.98]) ([10.237.220.98]) by fmsmga001.fm.intel.com with ESMTP; 28 Jun 2019 06:38:21 -0700 To: Stephen Hemminger , Ruifeng Wang Cc: bruce.richardson@intel.com, dev@dpdk.org, honnappa.nagarahalli@arm.com, gavin.hu@arm.com, nd@arm.com References: <20190627093751.7746-1-ruifeng.wang@arm.com> <20190627082451.56719392@hermes.lan> From: "Medvedkin, Vladimir" Message-ID: <94ab5030-f138-1ea4-8dbd-d67dc24a72a8@intel.com> Date: Fri, 28 Jun 2019 14:38:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190627082451.56719392@hermes.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH v3 1/3] lib/lpm: not inline unnecessary functions 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" Hi Stephen, On 27/06/2019 16:24, Stephen Hemminger wrote: > On Thu, 27 Jun 2019 17:37:49 +0800 > Ruifeng Wang wrote: > >> Tests showed that the function inlining caused performance drop >> on some x86 platforms with the memory ordering patches applied. >> By force no-inline functions, the performance was better than >> before on x86 and no impact to arm64 platforms. >> >> Suggested-by: Medvedkin Vladimir >> Signed-off-by: Ruifeng Wang >> Reviewed-by: Gavin Hu > { > > Do you actually need to force noinline or is just taking of inline enough? > In general, letting compiler decide is often best practice. In some cases compiler inlines this functions even if they don't have an inline qualifier. On some processors it leads to performance drop (maybe because of icache trashing). -- Regards, Vladimir