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 D4B5BA0471 for ; Thu, 18 Jul 2019 16:00:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E42B11041; Thu, 18 Jul 2019 16:00:06 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 72179DE3 for ; Thu, 18 Jul 2019 16:00:04 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2019 07:00:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,278,1559545200"; d="scan'208,217";a="170579978" Received: from vmedvedk-mobl.ger.corp.intel.com (HELO [10.237.220.94]) ([10.237.220.94]) by orsmga003.jf.intel.com with ESMTP; 18 Jul 2019 07:00:01 -0700 To: Ruifeng Wang , bruce.richardson@intel.com Cc: dev@dpdk.org, honnappa.nagarahalli@arm.com, gavin.hu@arm.com, nd@arm.com References: <20190605055451.30473-1-ruifeng.wang@arm.com> <20190718062230.16027-1-ruifeng.wang@arm.com> From: "Medvedkin, Vladimir" Message-ID: <4a6d5fdc-a79e-5129-daed-c14ff8dfe8ce@intel.com> Date: Thu, 18 Jul 2019 15:00:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190718062230.16027-1-ruifeng.wang@arm.com> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v6 0/4] LPM4 memory ordering changes 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 Wang, On 18/07/2019 07:22, Ruifeng Wang wrote: > LPM4 uses DIR24-8 method of routing info data organization. > Routing rule with prefix longer than 24 bits will be stored > in a tbl24 entry together with an associated tbl8 group. > > When a tbl8 group is getting attached to a tbl24 entry, lookup > might fail even though the entry is configured in the table. > > For ex: consider a LPM table configured with 10.10.10.1/24. > When a new entry 10.10.10.32/28 is being added, a new tbl8 > group is allocated and tbl24 entry is changed to point to > the tbl8 group. If the tbl24 entry is written without the tbl8 > group entries updated, a lookup on 10.10.10.9 will return > failure. > > Correct memory orderings are required to ensure that the > store to tbl24 does not happen before the stores to tbl8 group > entries complete. > > When memory orderings are imposed, API performance could drop. > However, a patch to de-inline unnecessary functions is added, > and this helps to keep API performance. > > On Arm A72 platform, the whole patch series in general have no > notable performance impact. > > On x86 E5-2640 platform, the whole patch series showed 2.6% > performance improvement on add, and no impact on lookup or > delete. > > > v6: > Merge multiple relaxed atomic store patches into one. > v5: > Fix typo in commit message. > Remove all other inlines. > Change to use atomic_store in tbl8_alloc / tbl8_free. > Merge multiple sigle field updates into one atomic store. > v4: > Change alignment attribute parameter. > Use atomic store to avoid partial update. > v3: > Use __rte_noinline to force no inline. > v2: > Fix clang building issue by supplying alignment attribute. > > Ruifeng Wang (4): > lib/lpm: not inline unnecessary functions > lib/lpm: memory orderings to avoid race conditions for v1604 > lib/lpm: memory orderings to avoid race conditions for v20 > lib/lpm: use atomic store to avoid partial update > > lib/librte_lpm/rte_lpm.c | 248 ++++++++++++++++++++++++++++----------- > lib/librte_lpm/rte_lpm.h | 8 +- > 2 files changed, 183 insertions(+), 73 deletions(-) Looks ok to me, thanks! Series-acked-by: Vladimir Medvedkin -- Regards, Vladimir