From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=3.0 tests=DATE_IN_PAST_06_12, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34DE1C43219 for ; Mon, 29 Apr 2019 18:03:27 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id E00042087B for ; Mon, 29 Apr 2019 18:03:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E00042087B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AE2C98E76; Mon, 29 Apr 2019 20:03:24 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id DE3B17D52 for ; Mon, 29 Apr 2019 20:03:22 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2019 11:03:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,410,1549958400"; d="scan'208";a="138476074" Received: from skx-blue.jf.intel.com ([10.54.80.170]) by orsmga008.jf.intel.com with ESMTP; 29 Apr 2019 11:03:21 -0700 From: Yipeng Wang To: yipeng1.wang@intel.com, pablo.de.lara.guarch@intel.com, gentoorion@gmail.com, anatoly.burakov@intel.com Cc: dev@dpdk.org Date: Mon, 29 Apr 2019 02:40:16 -0700 Message-Id: <1556530816-423522-1-git-send-email-yipeng1.wang@intel.com> X-Mailer: git-send-email 2.7.4 Subject: [dpdk-dev] [PATCH] doc: fix rte_hash_hash comment for ambiguity 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" rte_hash_hash is multi-thread safe but not multi-process safe because of the use of function pointers. Previous document and comment says the other way around. This commit fixes the issue. Fixes: fc1f2750a3ec ("doc: programmers guide") Fixes: 48a399119619 ("hash: replace with cuckoo hash implementation") Cc: stable@dpdk.org Signed-off-by: Yipeng Wang Suggested-by: Pablo de Lara Reported-by: Andrey Nikolaev --- doc/guides/prog_guide/multi_proc_support.rst | 2 +- lib/librte_hash/rte_hash.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/guides/prog_guide/multi_proc_support.rst b/doc/guides/prog_guide/multi_proc_support.rst index 1384fe3..761fca9 100644 --- a/doc/guides/prog_guide/multi_proc_support.rst +++ b/doc/guides/prog_guide/multi_proc_support.rst @@ -176,7 +176,7 @@ Some of these are documented below: * The use of function pointers between multiple processes running based of different compiled binaries is not supported, since the location of a given function in one process may be different to its location in a second. - This prevents the librte_hash library from behaving properly as in a multi-threaded instance, + This prevents the librte_hash library from behaving properly as in a multi-process instance, since it uses a pointer to the hash function internally. To work around this issue, it is recommended that multi-process applications perform the hash calculations by directly calling diff --git a/lib/librte_hash/rte_hash.h b/lib/librte_hash/rte_hash.h index c93d1a1..abba8d7 100644 --- a/lib/librte_hash/rte_hash.h +++ b/lib/librte_hash/rte_hash.h @@ -463,7 +463,7 @@ rte_hash_lookup_with_hash(const struct rte_hash *h, /** * Calc a hash value by key. - * This operation is not multi-thread safe. + * This operation is not multi-process safe. * * @param h * Hash table to look in. -- 2.7.4