Age | Commit message (Collapse) | Author | Files | Lines |
|
A simple memcmp won't work when comparing pointer-keys, such as those
used by the bihash_vec8_8.h template.
Change-Id: I77e59f3fd7f7740ef42908ace90ed4843e1c9ac7
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: Icc9bef32d1bb2b8f277598c50c69343c81f22cd2
Signed-off-by: Tom Seidenberg <tseidenb@cisco.com>
|
|
Change-Id: Id4f37f5d4a03160572954a416efa1ef9b3d79ad1
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Call the BV (value_free) when we have performed the rehash
and thus no longer need the memory that old value for the
bucket refers to.
Change-Id: Ibb82174fc8002aeb3e1a6c8d1f90293d73bc45d8
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
|
|
ffb14b9554afa1e58c3657e0c91dda3135008274 has changed the semantics
of alloc_arena_next to become an offset off alloc_arena, but
in the available memory check in BV (alloc_aligned) it still treats
it as a virtual address, resulting in the check always succeeding,
thus over a prolonged period bihash arena allocator
potentially overwriting whatever is following the arena.
Change-Id: I18882c5f340ca767a389e15cca2696a0a97ef015
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
|
|
This patch makes 32/64 bit interoperable shared memory bihash tables
work regardless of where they're mapped.
Change-Id: If5b4a37ccdaa75410eba755c7d7195633de1b30b
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Move the binary api segment above 4gb
Change-Id: I40e8aa7a97722a32397f5a538b5ff8344c50d408
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I1f0aae16e4ace850d7d79b9c2c644a3e0d002636
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Applications such as NAT that dynamically create entries require these entries to expire after some time.
Bihash user can now lazily delete expired entries. When inserting and bucket is full, expired entry is overwritten.
Change-Id: I6852305df399b546159407f1729c856afde5a634
Signed-off-by: Matus Fabian <matfabia@cisco.com>
|
|
When the user deletes the last entry in a bihash bucket, the bihash
infra frees the bucket's backing storage. If this happens under
clib_bihash_foreach_key_value_pair - and the freed bucket happens to
be the bucket being traversed - the resulting dangling reference can
easily make the wheels fall off.
Simple fix: if (bucket-is-now-empty) double-break.
Change-Id: Idc44247a82ed5d0ba548507b4a53d4c8503ba8bb
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I78c0a6da5d8fc63c1ced43589c42abc15ab12b16
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Add a bucket-level lock bit. Use a spinlock only when actually
allocating, freeing, or splitting a bucket. Should improve
multi-thread add/del performance.
Change-Id: I3e40e2a8371685457f340d6584dea14e3207f2b0
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: Ic636297df4c03303fdcb176669f0268d80e22123
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Directly allocate and carve cache-line-aligned chunks of virtual
memory. To a first approximation, bihash wasn't using
clib_mem_free(...).
We eliminate mheap object header/trailers, which improves space
efficiency. We also eliminate the 4gb bihash table size limit. An 8_8
bihash w/ 100 million random entries uses 3.8 Gbytes.
Change-Id: Icf925fdf99bce7d6ac407ac4edd30560b8f04808
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Reference-count the number of entries in each bucket. If the reference
count goes to zero, free the backing store.
Add long-term churn-testing to test_bihash_template.c, thanks to
Andrew Yourtchenko for the initial implementation.
Change-Id: I4fbd9229cacfaba8027a85cbf87b74afdead6e39
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
when verbose option is used
Change-Id: Ib63ead4525332f897b8a1d8a4cf5a0eb1da1e7f3
Signed-off-by: Vijayabhaskar Katamreddy <vkatamre@cisco.com>
|
|
writer_lock must be inited before used.
Change-Id: Ib258aa09b3bccc4de6edba0eb75a7eec20f1a61f
Signed-off-by: JingLiuZTE <liu.jing5@zte.com.cn>
|
|
Change-Id: I4b1f27b95d67d48b7a13750ff8754c344ed7afa7
Signed-off-by: Chris Luke <chrisy@flirble.org>
|
|
Setting the bucket-level LRU cache size to zero removes the
bucket-level LRU cache code.
Change-Id: Idf2e63d0d508675e957366515863766f79a3479c
Signed-off-by: Dave Barach <dbarach@cisco.com>
|
|
Change-Id: I84908b9ad30d7555024e98b69ed37b111f31c27a
Signed-off-by: Dave Barach <dbarach@cisco.com>
|
|
According to Maciek, the easiest way to leverage the csit "performance
trend" job is to actually merge the patch once verified. Manual
testing indicates that the patch improves l2 path performance. Other
use-cases are TBD. It's possible that we'll need to back out the patch
depending on what happens.
Change-Id: Ic0a0363de35ef9be953ad7709c57c3936b73fd5a
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
The Wmaybe-uninitialized is the new error included with Wall.
This patch addresses the warning and fixes it.
Change-Id: I8fdf9ff2d236c46b717024a14874fbbbad8af303
Signed-off-by: Marco Varlese <marco.varlese@suse.com>
|
|
VPP crash is observed when MAC aging is enabled with multi-threaded mode.
If a thread other-than-zero expands the working_copies vector,
working_copy_lengths should be initialized with vec_validate_init_empty(..., -1)
to fill -1 across lower-numbered working_copy_lengths vector element.
Change-Id: I60959fc6511306b33acae323df9c6898fc6c50ce
Signed-off-by: Steve Shin <jonshin@cisco.com>
|
|
Particularly in the DCLIB_VEC64=1 case, using vectors vs. raw
clib_mem_alloc'ed memory causes abysmal memory allocator performance.
Change-Id: I07a4dec0cd69ca357445385e2671cdf23c59b95d
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I82c663bc0866c6c68ba354104b0bb059387f4b9d
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Ib0144ba3a9a09971d3946c932e8fed6d5c1ad278
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I55dad7b5cfb3d38c22b1105f7d2d61e7449410ea
Signed-off-by: Dave Barach <dave@barachs.net>
|
|
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23
Signed-off-by: Damjan Marion <damarion@cisco.com>
|