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 4A3D0A046B for ; Fri, 28 Jun 2019 17:35:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7ED79F04; Fri, 28 Jun 2019 17:35:17 +0200 (CEST) Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by dpdk.org (Postfix) with ESMTP id 052222AB for ; Fri, 28 Jun 2019 17:35:15 +0200 (CEST) Received: by mail-pf1-f196.google.com with SMTP id t16so3157347pfe.11 for ; Fri, 28 Jun 2019 08:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=2LgiK438u5lOYs+jldN3C916GoHrQjUK7KCcjqEEqqE=; b=up5G3Cl1MLWPUeDgYHCARvBVU2eeVzBdtM/I2utj3DG0+/+pfr3ODlNilsvy4gFdhp tTQqJ/DURbHIQG+TVQSmRVFmb5Jyl4Wv5PeLNzJS3xcePGn+7nPFbUxJJHwKBBaBXwRG Rf3bQQykW7REvvKnGCwoSlU2de0qPIjJowKct5OwsyyAnmKNClK1mSDkRJoL8JeB2lcZ UUi3/0IpAZML02PfpLxZ0Xj04zjuy/f3dGH52VwMU+XXqn8O9dZ7bmt9t9yyt9+npq2W PA0gI4FFty8QY3RmwvqdPp8xL63PmeskqAo+Gpe24n2nV7ozbvxL8uTd075j0dR6Dr6c JnEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=2LgiK438u5lOYs+jldN3C916GoHrQjUK7KCcjqEEqqE=; b=j9LGXmAOn3JtHMQFMNEpQ0yfkowvcxHRiVH7eOdXURwPpqSbnPfMC1G6pP6txFaX/q j701dI7Coop++R+ryfsBRWA3qXkatD2E8NAuDPx5IoVWaO8CcGiXY64HN14mv/oNCF93 6y+PQ40BG/do6XskkX13/Gv5gMNR5LDL/4ExUkKxOI+0Gw/ussarfFK5h0d2Zc+vof9C 0syP58lxgvM1JgVX6oSmsfto38q32DMfEEcy7iEHExY9fTjCXfoh+KSnsl/bV8AL1DyO KOiAy3dYYkNK/nNnkXssjC5lUH5O+qtVGljoDLdvrZGC/qrffvi19lEEg2N9+XKnCjQh TNpw== X-Gm-Message-State: APjAAAV6JpbLRa4q07/WYvx9BU9OW2mJq0cdyKd3tt59JwXoVPGTfZXN 3WdALMB0k4sJoUs3TgSIetXzMA== X-Google-Smtp-Source: APXvYqymBU8gAF9gb17hOuh+zXGMVk3NmwBVWUjK0D+9vb3bld/Nn0C2xoLI2Y6b9JRpyq9gnrhHfA== X-Received: by 2002:a17:90a:c504:: with SMTP id k4mr13843993pjt.104.1561736114864; Fri, 28 Jun 2019 08:35:14 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id 196sm3761817pfy.167.2019.06.28.08.35.14 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 28 Jun 2019 08:35:14 -0700 (PDT) Date: Fri, 28 Jun 2019 08:35:07 -0700 From: Stephen Hemminger To: "Medvedkin, Vladimir" Cc: Honnappa Nagarahalli , "Ruifeng Wang (Arm Technology China)" , "bruce.richardson@intel.com" , "dev@dpdk.org" , "Gavin Hu (Arm Technology China)" , nd Message-ID: <20190628083507.31eca1db@hermes.lan> In-Reply-To: <185e012d-6f8a-66be-dc8c-a420065660fb@intel.com> References: <20190627093751.7746-1-ruifeng.wang@arm.com> <20190627082451.56719392@hermes.lan> <20190627213450.30082af6@hermes.lan> <185e012d-6f8a-66be-dc8c-a420065660fb@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 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.