From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 984F37CE1 for ; Thu, 24 Aug 2017 15:53:09 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Aug 2017 06:53:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,421,1498546800"; d="scan'208";a="141567941" Received: from silpixa00382658.ir.intel.com ([10.237.223.29]) by orsmga005.jf.intel.com with ESMTP; 24 Aug 2017 06:53:07 -0700 From: Cristian Dumitrescu To: dev@dpdk.org Date: Thu, 24 Aug 2017 14:53:04 +0100 Message-Id: <1503582789-121358-1-git-send-email-cristian.dumitrescu@intel.com> X-Mailer: git-send-email 2.7.4 Subject: [dpdk-dev] [PATCH 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: Thu, 24 Aug 2017 13:53:10 -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 | 8 - .../pipeline/pipeline_flow_classification.c | 9 +- .../pipeline/pipeline_flow_classification_be.c | 54 +- .../ip_pipeline/pipeline/pipeline_passthrough_be.c | 18 +- .../ip_pipeline/pipeline/pipeline_routing_be.c | 18 +- lib/librte_table/rte_table_hash.h | 302 +-------- lib/librte_table/rte_table_hash_cuckoo.c | 200 +++--- lib/librte_table/rte_table_hash_ext.c | 407 ++++-------- lib/librte_table/rte_table_hash_key16.c | 691 +++++---------------- lib/librte_table/rte_table_hash_key32.c | 381 +++++++----- lib/librte_table/rte_table_hash_key8.c | 654 +++++-------------- lib/librte_table/rte_table_hash_lru.c | 506 ++++++--------- 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 ++--- 18 files changed, 1160 insertions(+), 2492 deletions(-) -- 2.7.4