From patchwork Tue Jul 2 21:16:32 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Honnappa Nagarahalli X-Patchwork-Id: 168379 Delivered-To: patch@linaro.org Received: by 2002:a92:4782:0:0:0:0:0 with SMTP id e2csp4740837ilk; Tue, 2 Jul 2019 14:16:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqyaJLGXqiunNgrjnasXaQgEHtTmJeLj6BNHg1aoSc0vglghLBceFccQqnA29YFG8YU9L11/ X-Received: by 2002:a1c:e715:: with SMTP id e21mr4838216wmh.16.1562102210617; Tue, 02 Jul 2019 14:16:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562102210; cv=none; d=google.com; s=arc-20160816; b=KuZCApNrtLouQ3YppSWloMWmicJ27IiUAiEK4J+0qOmgOrPNqK+qjQDpdwTW5aCr0k RK/Yx3kXqPUsPwRwmIod2iDJkdiHEmYiPbBSaui6SnIB0QVzg5IE1l2KAMXC56cwAn2H NLLOu+ujgpRA/kZmD/yrxhfJc3JnRDVuRD+FJhbtQsHH0pyWg5NfWcWi37us+fU3r8i6 ZBAW7ws6p/rcOyyT2r5uTRwO+ywIF54M3tXoRfseNii7yr+nRmiYlKWStn1NcDIFqD5P ttAOPy0OP3srlLPOSTRTWQFGHuRGAu2Cx3ujvDimBKAfhYE9dXP0M9r+LHkL8HZ4LBiY stgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:subject:references:in-reply-to :message-id:date:cc:to:from; bh=vKQhU1ley2fgqk0DR4EO1iuK1hOpL7zAPYNEO6hHnZs=; b=MM+V2Xex4+YvC2J/U7Bs/z2UlgIveEg2kiyk+Vt6OF4xms50XM8p+pbMZTbDHbxKdF I2H2y5jvZEu4ebSY7/zWEjlBeTz4HjTxgx+pdshpkl8b1KOeosgt9DK7JrV6MmzyGCzJ qZI4PqG20ZFRpwfKwYON8Sg+gs7un7RSy9pdKCC0hvwKmfF5I2uwZZDrLqxBhekBbnb/ 3aVah497nz/y5KfyrtSFiYE/W6jMQ8aMC516H4foCor4Sb6sgfa9GasvIt10eGAKLo4Y RmQm0UvQgFhZ9SX+lRl5kJa5aIVgZ8BCzo/RaNKv4k7oOwVj2pfTQYIJG1L7lPAnL7Rs 1f6Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of dev-bounces@dpdk.org designates 92.243.14.124 as permitted sender) smtp.mailfrom=dev-bounces@dpdk.org Return-Path: Received: from dpdk.org (dpdk.org. [92.243.14.124]) by mx.google.com with ESMTP id r187si83619wma.34.2019.07.02.14.16.50; Tue, 02 Jul 2019 14:16:50 -0700 (PDT) Received-SPF: pass (google.com: domain of dev-bounces@dpdk.org designates 92.243.14.124 as permitted sender) client-ip=92.243.14.124; Authentication-Results: mx.google.com; spf=pass (google.com: domain of dev-bounces@dpdk.org designates 92.243.14.124 as permitted sender) smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D63331BDE6; Tue, 2 Jul 2019 23:16:48 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by dpdk.org (Postfix) with ESMTP id 294281BDE4 for ; Tue, 2 Jul 2019 23:16:48 +0200 (CEST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 62EDF344; Tue, 2 Jul 2019 14:16:47 -0700 (PDT) Received: from qc2400f-1.austin.arm.com (qc2400f-1.austin.arm.com [10.118.12.65]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4C2CB3F703; Tue, 2 Jul 2019 14:16:47 -0700 (PDT) From: Honnappa Nagarahalli To: yipeng1.wang@intel.com, sameh.gobriel@intel.com, bruce.richardson@intel.com, pablo.de.lara.guarch@intel.com, honnappa.nagarahalli@arm.com Cc: gavin.hu@arm.com, ruifeng.wang@arm.com, dev@dpdk.org, nd@arm.com Date: Tue, 2 Jul 2019 16:16:32 -0500 Message-Id: <20190702211634.37940-1-honnappa.nagarahalli@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20190625211520.43181-1-honnappa.nagarahalli@arm.com> References: <20190625211520.43181-1-honnappa.nagarahalli@arm.com> Subject: [dpdk-dev] [PATCH v2 0/2] lib/hash: perf improvements for lock-free 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" While using the rte_hash library, there are 2 sets of stores that happen. 1) The application writes its data to memory (whose address is provided in rte_hash_add_key_with_hash_data API (or NULL)) 2) The rte_hash library writes to its own internal data structures; key store entry and the hash table. The data from both of these stores is available to the readers only after the index of the key store entry (key_index) is written in the hash buckets by the library. So, key_index can act as the guard variable for both of these writes. When rte_hash_add_key_with_hash_data is called to update an existing entry, the key_index is not written. But, the store to the application data must complete before the address of the application data (pData) is updated in the key store entry. So, pData alone acts as the guard variable for this case. However, it should be noted that there are no ordering requirements between 1) and 2), except for one requirement - the store to the application data must complete before the store to key_index. In other words, there are no ordering requirements between the stores to the key store entry/signature and store to application data. So, the synchronization point for application data can be any point between the 'store to application data' and 'store to the key_index'. The first patch in this series moves the signature comparison before the load-acquire of the key_index. This does not result in any issues because of the full key comparison which is done after the load-acquire of the key_index. Performance improvements: Lookup Hit: 6.16% Lookup Miss: 8.54% The second patch in this series, moves the store-release of pData before the store to any hash internal data structures. This is not necessary, but just helps to show the non-dependency between application data and hash table data. On the reader side, the pData is loaded only if the keys match, this provides performance benefits. Performance improvements (with patch 1): Lookup Hit: 6.25% Lookup Miss: 13.97% v2 - Dropped moving the tbl_chng_cnt to the beginning of the cache line commit - Changed the commit log for patch 1 to indicate that it improves performance (Yipeng) - Changed the comment in the search_one_bucket_lf function (Yipeng) - Changed the commit log for patch2 to indicate that changes to store-release of 'pdata' is cosmetic (Yipeng) Honnappa Nagarahalli (2): lib/hash: use ordered loads only if signature matches lib/hash: load pData after full key compare lib/librte_hash/rte_cuckoo_hash.c | 98 ++++++++++++++++--------------- 1 file changed, 52 insertions(+), 46 deletions(-) -- 2.17.1