From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 071C01B246 for ; Tue, 10 Oct 2017 13:19:03 +0200 (CEST) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Oct 2017 04:19:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,504,1500966000"; d="scan'208";a="161404143" Received: from silpixa00382658.ir.intel.com ([10.237.223.29]) by fmsmga006.fm.intel.com with ESMTP; 10 Oct 2017 04:19:01 -0700 From: Cristian Dumitrescu To: dev@dpdk.org Date: Tue, 10 Oct 2017 12:18:56 +0100 Message-Id: <1507634341-72277-1-git-send-email-cristian.dumitrescu@intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1503582789-121358-2-git-send-email-cristian.dumitrescu@intel.com> References: <1503582789-121358-2-git-send-email-cristian.dumitrescu@intel.com> Subject: [dpdk-dev] [PATCH V2 0/5] table: add key mask for hash tables 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: , X-List-Received-Date: Tue, 10 Oct 2017 11:19:04 -0000 Main changes: 1. The key_mask parameter is added to all the hash tables that were previously missing it, as well to the hash compute function. This was first started in DPDK 2.0, but was only implemented for a couple of hash tables. The benefit of this approach is that it allows for better performance for large keys (bigger than 16 bytes), while it preserves the same performance for small keys [Q&A1]. 2. The precomputed key signature (i.e. non-"do-sig") versions have been removed for all the hash tables, so now the key signature is always computed on every lookup. Note that this approach also allows for the precomputed key signature scheme [Q&A2]. 3. API cleanup: single parameter structure common for all hash tables. Q&A: Q1: How is better lookup performance achieved by using key mask approach for hash tables? A1: This approach eliminates the need to consolidate the lookup key in a single contiguous buffer where the relevant packet fields are written one by one, which is a very costly operation that also hash strong data dependencies. Q2: How can the pre-computed key signature scheme be implemented with current approach? A2: The application can implement a straightforward custom hash function that simply reads the pre-computed key signature from a given offset in the input key buffer where it has been stored prior to the lookup operation. Cristian Dumitrescu (5): table: add key mask for hash tables test: update due to api changes in librte_table test-pipeline: update due to api changes in librte_table ip_pipeline: update due to api changes in librte_table deprecation: removed the librte_table notice doc/guides/rel_notes/deprecation.rst | 6 - examples/ip_pipeline/pipeline/hash_func.h | 178 +++-- .../pipeline/pipeline_flow_classification.c | 12 +- .../pipeline/pipeline_flow_classification_be.c | 51 +- .../ip_pipeline/pipeline/pipeline_passthrough_be.c | 18 +- .../ip_pipeline/pipeline/pipeline_routing_be.c | 18 +- lib/librte_table/rte_table_hash.h | 306 +-------- lib/librte_table/rte_table_hash_cuckoo.c | 205 +++--- lib/librte_table/rte_table_hash_ext.c | 417 ++++-------- lib/librte_table/rte_table_hash_key16.c | 749 ++++++--------------- lib/librte_table/rte_table_hash_key32.c | 435 +++++++----- lib/librte_table/rte_table_hash_key8.c | 715 ++++++-------------- lib/librte_table/rte_table_hash_lru.c | 513 ++++++-------- lib/librte_table/rte_table_version.map | 23 +- test/test-pipeline/main.h | 5 +- test/test-pipeline/pipeline_hash.c | 107 +-- test/test/test_table.c | 1 + test/test/test_table.h | 3 +- test/test/test_table_combined.c | 140 ++-- test/test/test_table_tables.c | 148 ++-- 20 files changed, 1444 insertions(+), 2606 deletions(-) -- 2.7.4