Vpp uses bounded-index extensible hashing to solve a variety of exact-match (key, value) lookup problems. Benefits of the current implementation:
Bounded-index extensible hashing has been widely used in databases for decades.
Bihash uses a two-level data structure:
+-----------------+
| bucket-0 |
| log2_size |
| backing store |
+-----------------+
| bucket-1 |
| log2_size | +--------------------------------+
| backing store | --------> | KVP_PER_PAGE * key-value-pairs |
+-----------------+ | page 0 |
... +--------------------------------+
+-----------------+ | KVP_PER_PAGE * key-value-pairs |
| bucket-2**N-1 | | page 1 |
| log2_size | +--------------------------------+
| backing store | ---
+-----------------+ +--------------------------------+
| KVP_PER_PAGE * key-value-pairs |
| page 2**(log2(size)) - 1 |
+--------------------------------+
This structure has a couple of major advantages. In practice, each bucket entry fits into a 64-bit integer. Coincidentally, vpp's target CPU architectures support 64-bit atomic operations. When modifying the contents of a specific bucket, we do the following:
So, no reader locking is required to search a bihash table.
At lookup time, the implementation computes a key hash code. We use the least-significant N bits of the hash to select the bucket.
With the bucket in hand, we learn log2 (nBackingPages) for the selected bucket. At this point, we use the next log2_size bits from the hash code to select the specific backing page in which the (key,value) page will be found.
Net result: we search one backing page, not 2**log2_size pages. This is a key property of the algorithm.
When sufficient collisions occur to fill the backing pages for a given bucket, we double the bucket size, rehash, and deal the bucket contents into a double-sized set of backing pages. In the future, we may represent the size as a linear combination of two powers-of-two, to increase space efficiency.
To solve the "jackpot case" where a set of records collide under hashing in a bad way, the implementation will fall back to linear search across 2**log2_size backing pages on a per-bucket basis.
To maintain space efficiency, we should configure the bucket array so that backing pages are effectively utilized. Lookup performance tends to change very little if the bucket array is too small or too large.
Bihash depends on selecting an effective hash function. If one were to use a truly broken hash function such as "return 1ULL." bihash would still work, but it would be equivalent to poorly-programmed linear search.
We often use cpu intrinsic functions - think crc32 - to rapidly compute a hash code which has decent statistics.
It's quite easy to use one of the template instance types. As of this writing, .../src/vppinfra provides pre-built templates for 8, 16, 20, 24, 40, and 48 byte keys, u8 * vector keys, and 8 byte values.
See .../src/vppinfra/{bihash__8}.h
To define the data types, #include a specific template instance, most often in a subsystem header file:
#include <vppinfra/bihash_8_8.h>
If you're building a standalone application, you'll need to define the various functions by #including the method implementation file in a C source file.
The core vpp engine currently uses most if not all of the known bihash types, so you probably won't need to #include the method implementation file.
#include <vppinfra/bihash_template.c>
Add an instance of the selected bihash data structure to e.g. a "main_t" structure:
typedef struct { ... BVT (clib_bihash) hash; or clib_bihash_8_8_t hash; ... } my_main_t;
The BV macro concatenate its argument with the value of the preprocessor symbol BIHASH_TYPE. The BVT macro concatenates its argument with the value of BIHASH_TYPE and the fixed-string "_t". So in the above example, BVT (clib_bihash) generates "clib_bihash_8_8_t".
If you're sure you won't decide to change the template / type name later, it's perfectly OK to code "clib_bihash_8_8_t" and so forth.
In fact, if you #include multiple template instances in a single source file, you must use fully-enumerated type names. The macros stand no chance of working.
Call the init function as shown. As a rough guide, pick a number of buckets which is approximately number_of_expected_records/BIHASH_KVP_PER_PAGE from the relevant template instance header-file. See previous discussion.
The amount of memory selected should easily contain all of the records, with a generous allowance for hash collisions. Bihash memory is allocated separately from the main heap, and won't cost anything except kernel PTE's until touched, so it's OK to be reasonably generous.
For example:
my_main_t *mm = &my_main; clib_bihash_8_8_t *h; h = &mm->hash_table; clib_bihash_init_8_8 (h, "test", (u32) number_of_buckets, (uword) memory_size);
Use BV(clib_bihash_add_del), or the explicit type variant:
clib_bihash_kv_8_8_t kv; clib_bihash_8_8_t * h; my_main_t *mm = &my_main; clib_bihash_8_8_t *h; h = &mm->hash_table; kv.key = key_to_add_or_delete; kv.value = value_to_add_or_delete; clib_bihash_add_del_8_8 (h, &kv, is_add /* 1=add, 0=delete */);
In the delete case, kv.value is irrelevant. To change the value associated with an existing (key,value) pair, simply re-add the [new] pair.
The simplest possible (key, value) search goes like so:
clib_bihash_kv_8_8_t search_kv, return_kv; clib_bihash_8_8_t * h; my_main_t *mm = &my_main; clib_bihash_8_8_t *h; h = &mm->hash_table; search_kv.key = key_to_add_or_delete; if (clib_bihash_search_8_8 (h, &search_kv, &return_kv) < 0) key_not_found(); else key_found();
Note that it's perfectly fine to collect the lookup result
if (clib_bihash_search_8_8 (h, &search_kv, &search_kv)) key_not_found(); etc.
When processing a vector of packets which need a certain lookup performed, it's worth the trouble to compute the key hash, and prefetch the correct bucket ahead of time.
Here's a sketch of one way to write the required code:
Dual-loop:
Programmer's choice whether to stash the hash code somewhere in vnet_buffer(b) metadata, or to use local variables.
Single-loop:
A fairly common scenario to build "show" commands involves walking a bihash table. It's simple enough:
my_main_t *mm = &my_main; clib_bihash_8_8_t *h; void callback_fn (clib_bihash_kv_8_8_t *, void *); h = &mm->hash_table; BV(clib_bihash_foreach_key_value_pair) (h, callback_fn, (void *) arg);
To nobody's great surprise: clib_bihash_foreach_key_value_pair iterates across the entire table, calling callback_fn with active entries.
The iterator template "clib_bihash_foreach_key_value_pair" must be used with a certain amount of care. For one thing, the iterator template does not take the bihash hash table writer lock. If your use-case requires it, lock the table.
For another, the iterator template is not safe under all conditions:
It's OK to delete bihash table entries during a table-walk. The iterator checks whether the current bucket has been freed after each callback_fn(...) invocation.
It is not OK to add entries during a table-walk.
The add-during-walk case involves a jackpot: while processing a key-value-pair in a particular bucket, add a certain number of entries. By luck, assume that one or more of the added entries causes the current bucket to split-and-rehash.
Since we rehash KVP's to different pages based on what amounts to a different hash function, either of these things can go wrong:
We may revisit previously-visited entries. Depending on how one coded the use-case, we could end up in a recursive-add situation.
We may skip entries that have not been visited
One could build an add-safe iterator, at a significant cost in performance: copy the entire bucket, and walk the copy.
It's hard to imagine a worthwhile add-during walk use-case in the first place; let alone one which couldn't be implemented by walking the table without modifying it, then adding a set of records.
Creating a new template is easy. Use one of the existing templates as a model, and make the obvious changes. The hash and key_compare methods are performance-critical in multiple senses.
If the key compare method is slow, every lookup will be slow. If the hash function is slow, same story. If the hash function has poor statistical properties, space efficiency will suffer. In the limit, a bad enough hash function will cause large portions of the table to revert to linear search.
Use of the best available vector unit is well worth the trouble in the hash and key_compare functions.