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 84884A0487 for ; Fri, 5 Jul 2019 12:41:05 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7A20E1BE4E; Fri, 5 Jul 2019 12:41:04 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id C524D1BE4B for ; Fri, 5 Jul 2019 12:41:02 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2019 03:41:01 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,454,1557212400"; d="scan'208";a="363566623" Received: from vmedvedk-mobl.ger.corp.intel.com (HELO [10.237.220.98]) ([10.237.220.98]) by fmsmga006.fm.intel.com with ESMTP; 05 Jul 2019 03:40:59 -0700 To: "Ruifeng Wang (Arm Technology China)" Cc: Honnappa Nagarahalli , Stephen Hemminger , "bruce.richardson@intel.com" , "dev@dpdk.org" , "Gavin Hu (Arm Technology China)" , nd References: <20190627093751.7746-1-ruifeng.wang@arm.com> <20190627082451.56719392@hermes.lan> <20190627213450.30082af6@hermes.lan> <185e012d-6f8a-66be-dc8c-a420065660fb@intel.com> <20190628083507.31eca1db@hermes.lan> From: "Medvedkin, Vladimir" Message-ID: Date: Fri, 5 Jul 2019 11:40:58 +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: 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" On 01/07/2019 07:44, Ruifeng Wang (Arm Technology China) wrote: > Hi Medvedkin, > >> -----Original Message----- >> From: Stephen Hemminger >> Sent: Friday, June 28, 2019 23:35 >> To: Medvedkin, Vladimir >> Cc: Honnappa Nagarahalli ; Ruifeng Wang >> (Arm Technology China) ; >> bruce.richardson@intel.com; dev@dpdk.org; Gavin Hu (Arm Technology >> China) ; nd >> Subject: Re: [dpdk-dev] [PATCH v3 1/3] lib/lpm: not inline unnecessary >> functions >> >> On Fri, 28 Jun 2019 15:16:30 +0100 >> "Medvedkin, Vladimir" wrote: >> >>> Hi Honnappa, >>> >>> On 28/06/2019 14:57, Honnappa Nagarahalli wrote: >>>>> Hi all, >>>>> >>>>> On 28/06/2019 05:34, Stephen Hemminger wrote: >>>>>> On Fri, 28 Jun 2019 02:44:54 +0000 "Ruifeng Wang (Arm Technology >>>>>> China)" 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. >>>>>>> The force noinline is an optimization for x86 platforms to keep >>>>>>> rte_lpm_add() API performance with memory ordering applied. >>>>>> I don't think you answered my question. What does a recent version >>>>>> of GCC do if you drop the inline. >>>>>> >>>>>> Actually all the functions in rte_lpm should drop inline. >>>>> I'm agree with Stephen. If it is not a fastpath and size of >>>>> function is not minimal it is good to remove inline qualifier for >>>>> other control plane functions such as rule_add/delete/find/etc and >>>>> let the compiler decide to inline it (unless it affects performance). >>>> IMO, the rule needs to be simple. If it is control plane function, we should >> leave it to the compiler to decide. I do not think we need to worry too much >> about performance for control plane functions. >>> Control plane is not as important as data plane speed but it is still >>> important. For lpm we are talking not about initialization, but >>> runtime routes add/del related functions. If it is very slow the >>> library will be totally unusable because after it receives a route >>> update it will be blocked for a long time and route update queue would >> overflow. >> >> Control plane performance is more impacted by algorithmic choice. >> The original LPM had terrible (n^2?) control path. Current code is better. >> I had a patch using RB tree, but it was rejected because it used the >> /usr/include/bsd/sys/tree.h which added a dependency. > Based on current discussion, I'd like to drop this single patch from the patch set. > Since it is not directly related to memory ordering changes in this library. > We can remove inlines in a follow up patch. I think this patch is indirectly related to changes. I can't accept a memory ordering patch series _before_ this patch because a repository state will appear in which the performance of LPM add/delete has dropped. So if it could be avoided it have to be avoided. -- Regards, Vladimir