DPDK patches and discussions
 help / color / mirror / Atom feed
From: Yipeng Wang <yipeng1.wang@intel.com>
To: pablo.de.lara.guarch@intel.com, john.mcnamara@intel.com,
	marko.kovacevic@intel.com
Cc: dev@dpdk.org, yipeng1.wang@intel.com, bruce.richardson@intel.com
Subject: [dpdk-dev] [PATCH 1/2] doc: add multithread description to hash library
Date: Thu, 26 Jul 2018 10:56:00 -0700	[thread overview]
Message-ID: <1532627761-256100-1-git-send-email-yipeng1.wang@intel.com> (raw)

Added multithreading related description into programmer
guide of hash library.

Signed-off-by: Yipeng Wang <yipeng1.wang@intel.com>
---
 doc/guides/prog_guide/hash_lib.rst | 29 ++++++++++++++++++++++++++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/doc/guides/prog_guide/hash_lib.rst b/doc/guides/prog_guide/hash_lib.rst
index 180c776..76a1f32 100644
--- a/doc/guides/prog_guide/hash_lib.rst
+++ b/doc/guides/prog_guide/hash_lib.rst
@@ -19,6 +19,8 @@ The main configuration parameters for the hash are:
 
 *   Size of the key in bytes
 
+*   An extra flag used to describe additional settings, for example the multithreading mode of operation (as will be described later)
+
 The hash also allows the configuration of some low-level implementation related parameters such as:
 
 *   Hash function to translate the key into a bucket index
@@ -49,8 +51,7 @@ Apart from these method explained above, the API allows the user three more opti
 Also, the API contains a method to allow the user to look up entries in bursts, achieving higher performance
 than looking up individual entries, as the function prefetches next entries at the time it is operating
 with the first ones, which reduces significantly the impact of the necessary memory accesses.
-Notice that this method uses a pipeline of 8 entries (4 stages of 2 entries), so it is highly recommended
-to use at least 8 entries per burst.
+
 
 The actual data associated with each key can be either managed by the user using a separate table that
 mirrors the hash in terms of number of entries and position of each entry,
@@ -63,11 +64,33 @@ However, this table could also be used for more sophisticated features and provi
 Multi-process support
 ---------------------
 
-The hash library can be used in a multi-process environment, minding that only lookups are thread-safe.
+The hash library can be used in a multi-process environment.
 The only function that can only be used in single-process mode is rte_hash_set_cmp_func(), which sets up
 a custom compare function, which is assigned to a function pointer (therefore, it is not supported in
 multi-process mode).
 
+
+Multi-thread support
+---------------------
+
+The hash library supports multithreading, and the user specifies the needed mode of operation at the creation time of the hash table
+by appropriately setting the flag. In all modes of operation lookups are thread-safe meaning lookups can be called from multiple
+threads concurrently.
+
+For concurrent writes, and concurrent reads and writes the following flag values define the corresponding modes of operation:
+
+*  If the multi-writer flag (RTE_HASH_EXTRA_FLAGS_MULTI_WRITER_ADD) is set, multiple threads writing to the table is allowed.
+   Key add, delete, and table reset are protected from other writer threads. With only this flag set, readers are not protected from ongoing writes.
+
+*  If the read/write concurrency (RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY) is set, multithread read/write operation is safe
+   (i.e., no need to stop the readers from accessing the hash table until writers finish their updates. Reads and writes can operate table concurrently).
+
+*  In addition to these two flag values, if the transactional memory flag (RTE_HASH_EXTRA_FLAGS_TRANS_MEM_SUPPORT) is also set,
+   hardware transactional memory will be used to guarantee the thread safety as long as it is supported by the hardware (for example the Intel® TSX support).
+
+If the platform supports Intel® TSX, it is advised to set the transactional memory flag, as this will speed up concurrent table operations.
+Otherwise concurrent operations will be slower because of the overhead associated with the software locking mechanisms.
+
 Implementation Details
 ----------------------
 
-- 
2.7.4

             reply	other threads:[~2018-07-27  0:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-26 17:56 Yipeng Wang [this message]
2018-07-26 17:56 ` [dpdk-dev] [PATCH 2/2] hash: add more accurate thread-safety comments Yipeng Wang
2018-08-09 13:00   ` De Lara Guarch, Pablo
2018-08-05 20:29 ` [dpdk-dev] [PATCH 1/2] doc: add multithread description to hash library Thomas Monjalon
2018-08-09 13:00   ` De Lara Guarch, Pablo
2018-08-09 20:00     ` 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=1532627761-256100-1-git-send-email-yipeng1.wang@intel.com \
    --to=yipeng1.wang@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=john.mcnamara@intel.com \
    --cc=marko.kovacevic@intel.com \
    --cc=pablo.de.lara.guarch@intel.com \
    /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).