From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 8ED231B3A5 for ; Sat, 13 Oct 2018 03:02:14 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Oct 2018 18:02:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,374,1534834800"; d="scan'208";a="87987182" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by FMSMGA003.fm.intel.com with ESMTP; 12 Oct 2018 18:02:13 -0700 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 12 Oct 2018 18:02:13 -0700 Received: from fmsmsx151.amr.corp.intel.com ([169.254.7.87]) by FMSMSX110.amr.corp.intel.com ([169.254.14.229]) with mapi id 14.03.0319.002; Fri, 12 Oct 2018 18:02:12 -0700 From: "Wang, Yipeng1" To: Honnappa Nagarahalli , "Richardson, Bruce" , "De Lara Guarch, Pablo" CC: "dev@dpdk.org" , "dharmik.thakkar@arm.com" , "gavin.hu@arm.com" , "nd@arm.com" , "Gobriel, Sameh" Thread-Topic: [PATCH v3 1/7] hash: separate multi-writer from rw-concurrency Thread-Index: AQHUYfVZDSV5+6g5JUelBh5TJP2IcqUcWAaQ Date: Sat, 13 Oct 2018 01:02:11 +0000 Message-ID: References: <1539325918-125438-1-git-send-email-honnappa.nagarahalli@arm.com> <1539325918-125438-2-git-send-email-honnappa.nagarahalli@arm.com> In-Reply-To: <1539325918-125438-2-git-send-email-honnappa.nagarahalli@arm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMWI3MzI1ODctYTVkNi00NTc1LWJkNTctNmM3MDczYzdhMTk1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiNFh6Q0FuY1NvQ0lTdmlyQW5yMU53U3F1dmVcL0V3M0V1ZytFWjFaeW9ZT3BGTzlld3ZRZW9penVpU2hBMmNSMVMifQ== x-originating-ip: [10.1.200.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v3 1/7] hash: separate multi-writer from rw-concurrency 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: Sat, 13 Oct 2018 01:02:15 -0000 >-----Original Message----- >From: Honnappa Nagarahalli [mailto:honnappa.nagarahalli@arm.com] >Sent: Thursday, October 11, 2018 11:32 PM >To: Richardson, Bruce ; De Lara Guarch, Pablo = >Cc: dev@dpdk.org; Wang, Yipeng1 ; honnappa.nagarah= alli@arm.com; dharmik.thakkar@arm.com; >gavin.hu@arm.com; nd@arm.com >Subject: [PATCH v3 1/7] hash: separate multi-writer from rw-concurrency > >RW concurrency is required with single writer and multiple reader >usecase as well. Hence, multi-writer should not be enabled by default when >RW concurrency is enabled. > >Fixes: f2e3001b53ec ("hash: support read/write concurrency") >Cc: yipeng1.wang@intel.com > >Signed-off-by: Honnappa Nagarahalli >Reviewed-by: Gavin Hu >--- > lib/librte_hash/rte_cuckoo_hash.c | 27 ++++++++++++++++----------- > lib/librte_hash/rte_cuckoo_hash.h | 2 ++ > test/test/test_hash_readwrite.c | 6 ++++-- > 3 files changed, 22 insertions(+), 13 deletions(-) > >+ uint8_t writer_takes_lock; >+ /**< Indicates if the writer threads need to take lock */ [Wang, Yipeng]=20 Our understanding is that the difference between writer_takes_lock and mult= i_writer_support flag now is that for the multi-writer case we still have the local cache for key-data pair slot. Please correct me if = I am wrong. But the name is confusing because writer_takes_lock implies multi-writer su= pport. Especially the comment here says that writer needs a lock, which means multi-writer is supported. So concept= ually it does not have different meaning than the multi_writer_support by just reading the name. If you want to distinguish these two implementation (with vs. without cache= ), maybe change the name of multi-writer flag to use_local_cache flag? And the previous locking mechanism need to enable this flag for performance= reasons, while the LF does not. Or just keep the cache for both cases, and I don't think the local cache wi= ll add too much overhead. > rte_hash_function hash_func; /**< Function used to calculate hash. */ > uint32_t hash_func_init_val; /**< Init value used by hash_func. */ > rte_hash_cmp_eq_t rte_hash_custom_cmp_eq; >diff --git a/test/test/test_hash_readwrite.c b/test/test/test_hash_readwri= te.c >index 2a4f7b9..a8fadd0 100644 >--- a/test/test/test_hash_readwrite.c >+++ b/test/test/test_hash_readwrite.c >@@ -122,10 +122,12 @@ init_params(int use_htm, int use_jhash) > if (use_htm) > hash_params.extra_flag =3D > RTE_HASH_EXTRA_FLAGS_TRANS_MEM_SUPPORT | >- RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY; >+ RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY | >+ RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD; [Wang, Yipeng]=20 Could you double check that if current applications do not change their cod= e, there is no functional issue will be introduced by this change, otherwise this would= be an API change. I believe it will have performance implication though. Otherwise I am OK with this patch.