From: "Shen, Wei1" <wei1.shen@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
"Maciocco, Christian" <christian.maciocco@intel.com>,
"Gobriel, Sameh" <sameh.gobriel@intel.com>
Subject: Re: [dpdk-dev] [PATCH v1] hash: add tsx support for cuckoo hash
Date: Mon, 9 May 2016 16:51:56 +0000 [thread overview]
Message-ID: <D794DC50-5243-4D56-8706-7F92DE9AB825@intel.com> (raw)
In-Reply-To: <20160506215632.2bacfcdf@xeon-e3>
Hi Stephen,
Greetings. Thanks for your great feedback. Let’s me address your concern here.
1) It changes ABI, so it breaks old programs
The patch uses the extra_flag field in the rte_hash_parameters struct to set the default insertion behavior. Today there is only one bit used by this flag (RTE_HASH_EXTRA_FLAGS_TRANS_MEM_SUPPORT 0x1) and we used the next unused bit (RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD 0x2) in this patch. So ABI are maintained.
2) What about older processors, need to detect and handle them at runtime.
Correct. This patch is based on the previous Transactional Memory patch. Since these previous patches already assume the user to check the presence of TSX so we build on top this assumption. But I personally agree with you that handling TSX check should be made easier.
http://dpdk.org/ml/archives/dev/2015-June/018571.html
http://dpdk.org/ml/archives/dev/2015-June/018566.html
3) Why can't this just be the default behavior with correct fallback to locking on older processors.
This is an excellent point. We discussed this before. Our thought at that time is, since TSX insertion is a bit slower than without anything (TSX or other locks), it would benefit apps that is designed to have a single writer to the hash table (for instance in some master-slave model). We might need more feedback from user about whether making it default is more desirable if most the app is designed with multi-writer manner.
Thanks,
--
Best,
Wei Shen.
On 5/6/16, 9:56 PM, "Stephen Hemminger" <stephen@networkplumber.org> wrote:
>On Fri, 6 May 2016 21:05:02 +0100
>Shen Wei <wei1.shen@intel.com> wrote:
>
>> --- a/lib/librte_hash/rte_cuckoo_hash.c
>> +++ b/lib/librte_hash/rte_cuckoo_hash.c
>> @@ -1,7 +1,7 @@
>> /*-
>> * BSD LICENSE
>> *
>> - * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
>> + * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
>> * All rights reserved.
>> *
>> * Redistribution and use in source and binary forms, with or without
>> @@ -100,7 +100,9 @@ EAL_REGISTER_TAILQ(rte_hash_tailq)
>>
>> #define KEY_ALIGNMENT 16
>>
>> -#define LCORE_CACHE_SIZE 8
>> +#define LCORE_CACHE_SIZE 64
>> +
>> +#define RTE_HASH_BFS_QUEUEs_MAX_LEN 5000
>>
>> #if defined(RTE_ARCH_X86) || defined(RTE_ARCH_ARM64)
>> /*
>> @@ -190,6 +192,7 @@ struct rte_hash {
>> memory support */
>> struct lcore_cache *local_free_slots;
>> /**< Local cache per lcore, storing some indexes of the free slots */
>> + uint8_t multiwrite_add; /**< Multi-write safe hash add behavior */
>> } __rte_cache_aligned;
>>
>
>I like the idea of using TSX to allow multi-writer safety, but there are
>several problems with this patch.
>
>1) It changes ABI, so it breaks old programs
>2) What about older processors, need to detect and handle them at runtime.
>3) Why can't this just be the default behavior with correct
> fallback to locking on older processors.
>
>Actually lock ellision in DPDK is an interesting topic in general that
>needs to be addressed.
next prev parent reply other threads:[~2016-05-09 16:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-06 20:05 Shen Wei
2016-05-07 4:56 ` Stephen Hemminger
2016-05-09 16:51 ` Shen, Wei1 [this message]
2016-06-10 11:09 ` De Lara Guarch, Pablo
2016-06-15 23:45 ` De Lara Guarch, Pablo
2016-06-16 4:58 ` Shen, Wei1
2016-06-16 4:52 ` [dpdk-dev] [PATCH v2] rte_hash: add scalable multi-writer insertion w/ Intel TSX Wei Shen
2016-06-16 12:14 ` Ananyev, Konstantin
2016-06-16 22:14 ` [dpdk-dev] [PATCH v3] " Wei Shen
2016-06-16 22:14 ` Wei Shen
2016-06-16 22:22 ` De Lara Guarch, Pablo
2016-06-24 14:09 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D794DC50-5243-4D56-8706-7F92DE9AB825@intel.com \
--to=wei1.shen@intel.com \
--cc=christian.maciocco@intel.com \
--cc=dev@dpdk.org \
--cc=pablo.de.lara.guarch@intel.com \
--cc=sameh.gobriel@intel.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).