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 43A0FA0597; Wed, 8 Apr 2020 20:20:05 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6D2D21C1D3; Wed, 8 Apr 2020 20:20:04 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id CC68A1C1C7 for ; Wed, 8 Apr 2020 20:20:02 +0200 (CEST) IronPort-SDR: DQ88mRausk4FcVg5KNFILU5n6U9Rgr4KGSTa93Xfx7+SsFNZ9YDiBhq1KvxcUu2ZgtleV3ExbF InU9NQaRhOtQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2020 11:20:01 -0700 IronPort-SDR: gfnbkNztkHk8gHQ/wS9AT+AnlnYNS6xafReCcezR3j0QQYzdlSSmQjUCowmMmnJOOzXMisiL0y M6vxTI+ltohg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,359,1580803200"; d="scan'208";a="254878041" Received: from silpixa00400072.ir.intel.com ([10.237.222.213]) by orsmga006.jf.intel.com with ESMTP; 08 Apr 2020 11:19:59 -0700 From: Vladimir Medvedkin To: dev@dpdk.org Cc: konstantin.ananyev@intel.com, yipeng1.wang@intel.com, sameh.gobriel@intel.com, bruce.richardson@intel.com Date: Wed, 8 Apr 2020 19:19:53 +0100 Message-Id: X-Mailer: git-send-email 2.7.4 In-Reply-To: References: Subject: [dpdk-dev] [PATCH v2 0/4] add new k32v64 hash table 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" Currently DPDK has a special implementation of a hash table for 4 byte keys which is called FBK hash. Unfortunately its main drawback is that it only supports 2 byte values. The new implementation called K32V64 hash supports 4 byte keys and 8 byte associated values, which is enough to store a pointer. It would also be nice to get feedback on whether to leave the old FBK and new k32v64 implementations or deprecate the old one? v2: - renamed from rte_dwk to rte_k32v64 as was suggested - reworked lookup function, added inlined subroutines - added avx512 key comparizon routine - added documentation - added statistic counters for total entries and extended entries(linked list) Vladimir Medvedkin (4): hash: add k32v64 hash library hash: add documentation for k32v64 hash library test: add k32v64 hash autotests test: add k32v64 perf tests app/test/Makefile | 1 + app/test/autotest_data.py | 12 ++ app/test/meson.build | 3 + app/test/test_hash_perf.c | 83 +++++++++ app/test/test_k32v64_hash.c | 229 ++++++++++++++++++++++++ doc/api/doxy-api-index.md | 1 + doc/guides/prog_guide/index.rst | 1 + doc/guides/prog_guide/k32v64_hash_lib.rst | 66 +++++++ lib/Makefile | 2 +- lib/librte_hash/Makefile | 4 +- lib/librte_hash/meson.build | 5 +- lib/librte_hash/rte_hash_version.map | 6 +- lib/librte_hash/rte_k32v64_hash.c | 279 ++++++++++++++++++++++++++++++ lib/librte_hash/rte_k32v64_hash.h | 214 +++++++++++++++++++++++ 14 files changed, 901 insertions(+), 5 deletions(-) create mode 100644 app/test/test_k32v64_hash.c create mode 100644 doc/guides/prog_guide/k32v64_hash_lib.rst create mode 100644 lib/librte_hash/rte_k32v64_hash.c create mode 100644 lib/librte_hash/rte_k32v64_hash.h -- 2.7.4