Updates hash library documentation, reflecting
the new implementation changes.
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch at intel.com>
---
doc/guides/prog_guide/hash_lib.rst | 77 +++++++++++++++++++++++++++++++-------
1 file changed, 64 insertions(+), 13 deletions(-)
diff --git a/doc/guides/prog_guide/hash_lib.rst
b/doc/guides/prog_guide/hash_lib.rst
index 9b83835..be64a74 100644
--- a/doc/guides/prog_guide/hash_lib.rst
+++ b/doc/guides/prog_guide/hash_lib.rst
@@ -1,5 +1,5 @@
.. BSD LICENSE
- Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
All rights reserved.
Redistribution and use in source and binary forms, with or without
@@ -50,8 +50,6 @@ The hash also allows the configuration of some low-level
implementation related
* Hash function to translate the key into a bucket index
-* Number of entries per bucket
-
The main methods exported by the hash are:
* Add entry with key: The key is provided as input. If a new entry is
successfully added to the hash for the specified key,
@@ -65,10 +63,27 @@ The main methods exported by the hash are:
* Lookup for entry with key: The key is provided as input. If an entry with
the specified key is found in the hash (lookup hit),
then the position of the entry is returned, otherwise (lookup miss) a
negative value is returned.
-The current hash implementation handles the key management only.
-The actual data associated with each key has to be managed by the user using a
separate table that
+Apart from these method explained above, the API allows the user three more
options:
+
+* Add / lookup / delete with key and precomputed hash: Both the key and its
precomputed hash are provided as input. This allows
+ the user to perform these operations faster, as hash is already computed.
+
+* Add / lookup / delete with key and data: A pair of key-value is provided
as input. This allows the user to store
+ not only the key, but also either an integer or a pointer in the table
itself, which should perform better
+ than storing the data in an external table
+
+* Combination of the two options above: User can provide key, precomputed
hash and data.
+
+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,
-as shown in the Flow Classification use case describes in the following
sections.
+as shown in the Flow Classification use case describes in the following
sections,
+or store the data in the hash table.
The example hash tables in the L2/L3 Forwarding sample applications defines
which port to forward a packet to based on a packet flow identified by the
five-tuple lookup.
However, this table could also be used for more sophisticated features and
provide many other functions and actions that could be performed on the packets
and flows.
@@ -76,17 +91,26 @@ However, this table could also be used for more
sophisticated features and provi
Implementation Details
----------------------
-The hash table is implemented as an array of entries which is further divided
into buckets,
-with the same number of consecutive array entries in each bucket.
-For any input key, there is always a single bucket where that key can be
stored in the hash,
-therefore only the entries within that bucket need to be examined when the key
is looked up.
+The hash table has two main tables:
+
+* First table is an array of entries which is further divided into buckets,
+ with the same number of consecutive array entries in each bucket. Each entry
contains the computed primary
+ and secondary hashes of a given key (explained below), and an index to the
second table.
+
+* The second table is an array of all the keys stored in the hash table and
its data associated to each key.
+
+The hash library uses the cuckoo hash method to resolve collisions.
+For any input key, there are two possible buckets (primary and
secondary/alternative location)
+where that key can be stored in the hash, therefore only the entries within
those bucket need to be examined
+when the key is looked up.
The lookup speed is achieved by reducing the number of entries to be scanned
from the total
-number of hash entries down to the number of entries in a hash bucket,
+number of hash entries down to the number of entries in the two hash buckets,
as opposed to the basic method of linearly scanning all the entries in the
array.
The hash uses a hash function (configurable) to translate the input key into a
4-byte key signature.
The bucket index is the key signature modulo the number of hash buckets.
-Once the bucket is identified, the scope of the hash add,
-delete and lookup operations is reduced to the entries in that bucket.
+
+Once the buckets are identified, the scope of the hash add,
+delete and lookup operations is reduced to the entries in those buckets (it is
very likely that entries are in the primary bucket).
To speed up the search logic within the bucket, each hash entry stores the
4-byte key signature together with the full key for each hash entry.
For large key sizes, comparing the input key against a key from the bucket can
take significantly more time than
@@ -95,6 +119,33 @@ Therefore, the signature comparison is done first and the
full key comparison do
The full key comparison is still necessary, as two input keys from the same
bucket can still potentially have the same 4-byte hash signature,
although this event is relatively rare for hash functions providing good
uniform distributions for the set of input keys.
+Example of lookup:
+
+First of all, the primary bucket is identified and entry is likely to be
stored there.
+If signature was stored there, we compare its key against the one provided and
return the position
+where it was stored and/or the data associated to that key if there is a match.
+If signature is not in the primary bucket, the secondary bucket is looked up,
where same procedure
+is carried out. If there is no match there either, key is considered not to be
in the table.
+
+Example of addition:
+
+Like lookup, the primary and secondary buckets are indentified. If there is an
empty slot in
+the primary bucket, primary and secondary signatures are stored in that slot,
key and data (if any) are added to
+the second table and an index to the position in the second table is stored in
the slot of the first table.
+If there is no space in the primary bucket, one of the entries on that bucket
is pushed to its alternative location,
+and the key to be added is inserted in its position.
+To know where the alternative bucket of the evicted entry is, the secondary
signature is looked up and alternative bucket index
+is calculated from doing the modulo, as seen above. If there is room in the
alternative bucket, the evicted entry
+is stored in it. If not, same process is repeated (one of the entries gets
pushed) until a non full bucket is found.
+Notice that despite all the entry movement in the first table, the second
table is not touched, which would impact
+greatly in performance.
+
+In the very unlikely event that table enters in a loop where same entries are
being evicted indefinitely,
+key is considered not able to be stored.
+With random keys, this method allows the user to get around 90% of the table
utilization, without
+having to drop any stored entry (LRU) or allocate more memory (extended
buckets).
+
+
Use Case: Flow Classification
-----------------------------
--
2.4.2
