rte_member_parameters(3)

💖 rte_member_parameters(3) 💖

okay bestie, welcome to the Library Functions Manual page for rte_member_parameters — yes it's a whole struct and yes it's lowkey the blueprint for building your set summary table 🎀

---

🦋 NAME 🦋

rte_member_parameters — the lil bag of settings you hand over when you're creating a set summary table, no cap

---

✨ SYNOPSIS ✨

#include <rte_member.h>

🌸 Data Fields 🌸

const char * name
enum rte_member_setsum_type type
uint8_t is_cache
uint32_t num_keys
uint32_t key_len
uint32_t num_set
float false_positive_rate
uint32_t prim_hash_seed
uint32_t sec_hash_seed
float error_rate
float sample_rate
uint32_t top_k
uint32_t extra_flag
int socket_id

---

💅 Detailed Description 💅

these are the parameters used when you create the set summary table, periodt. rn the user can specify two types of setsummary: HT based and vBF. and for HT based, you can specify cache or non-cache mode 💖

Here is a table to describe some differences

Definition at line 186 of file rte_member.h.

---

🎀 Field Documentation 🎀

🌈 const char* name

Name of the hash.

Definition at line 187 of file rte_member.h.

🌈 enum rte_member_setsum_type type

You get to specify the type of the setsummary from one of rte_member_setsum_type. it's giving choose-your-own-adventure 🦋

HT based setsummary is implemented like a hash table. You should use this type when there are many sets.

vBF setsummary is a vector of bloom filters. It's used when the number of sets is not big (less than 32 for the current implementation).

Definition at line 199 of file rte_member.h.

🌈 uint8_t is_cache

is_cache is only used for HT based setsummary, okay? don't come for me 🙈

If it's an HT based setsummary, you get to specify the subtype or mode of the setsummary. It could be cache mode, or non-cache mode. Set is_cache to be 1 if you want to use it as cache mode.

For cache mode: keys can be evicted out of the HT setsummary. Keys with the same signature that map to the same bucket will overwrite each other in the setsummary table. This mode is useful for the case that the setsummary only needs to keep record of the recently inserted keys. Both false-negative and false-positive could happen. 💀

For non-cache mode: keys cannot be evicted out of the cache. So for this mode the setsummary will become full eventually. Keys with the same signature but mapping to the same bucket will still occupy multiple entries. This mode does not give false-negative result. ate ✨

Definition at line 220 of file rte_member.h.

🌈 uint32_t num_keys

For HT setsummary: num_keys equals the number of entries of the table. When the number of keys inserted in the HT setsummary approaches this number, eviction could happen. For cache mode, keys could be evicted out of the table. For non-cache mode, keys will be evicted to other buckets like cuckoo hash. The table will also likely become full before the number of inserted keys equals the total number of entries.

For vBF: num_keys equals the expected number of keys that will be inserted into the vBF. The implementation assumes the keys are evenly distributed to each BF in the vBF. This is used to calculate the number of bits we need for each BF. You do not specify the size of each BF directly, because the optimal size depends on the num_keys and the false positive rate. iykyk 🧚

Definition at line 238 of file rte_member.h.

🌈 uint32_t key_len

The length of the key is used for hash calculation. Since the key is not stored in set-summary, a large key does not require more memory space. slay, free real estate 💅

Definition at line 244 of file rte_member.h.

🌈 uint32_t num_set

num_set is only used for vBF, but not used for HT setsummary.

num_set equals the number of BFs in the vBF. For the current implementation, it only supports 1,2,4,8,16,32 BFs in one vBF set summary. If another number of sets is needed — for example 5 — you should allocate the minimum available value that's larger than 5, which is 8. (yes bestie, round up, that's the vibe 😌)

Definition at line 255 of file rte_member.h.

🌈 float false_positive_rate

false_positive_rate is only used for vBF, not for HT setsummary.

For vBF: false_positive_rate is the user-defined false positive rate given the expected number of inserted keys (num_keys). It's used to calculate the total number of bits for each BF, and the number of hash values used during lookup and insertion. For details, please refer to the vBF implementation and the membership library documentation.

For HT: this parameter is not directly set by users. HT setsummary's false positive rate is in the order of: false_pos = (1/bucket_count)*(1/2^16), since we use a 16-bit signature. That's because two keys need to map to the same bucket and the same signature to have a collision (a false positive). bucket_count is equal to the number of entries (num_keys) divided by the entry count per bucket (RTE_MEMBER_BUCKET_ENTRIES). Thus, the false_positive_rate is not directly set by users for HT mode. it's giving math homework but make it iconic 🍓

Definition at line 276 of file rte_member.h.

🌈 uint32_t prim_hash_seed

We use two seeds to calculate two independent hashes for each key. two of them. a duo. main character energy 🔥

For HT type, one hash is used as the signature, and the other is used for bucket location. For vBF type, these two hashes and their combinations are used as hash locations to index the bit array. For Sketch type, these seeds are not used.

Definition at line 287 of file rte_member.h.

🌈 uint32_t sec_hash_seed

The secondary seed should be a different value from the primary seed. (please, bestie, do not set them the same 🙈)

Definition at line 292 of file rte_member.h.

🌈 float error_rate

For the count(min) sketch data structure, error_rate defines the accuracy required by the user. Higher accuracy leads to more memory usage, but the flow size is estimated more accurately. trade-offs, we love to see it 💜

Definition at line 299 of file rte_member.h.

🌈 float sample_rate

Sampling rate means the internal sample rate of the rows of the count min sketches. A lower sampling rate can reduce CPU overhead, but the data structure will require more time to converge statistically.

Definition at line 306 of file rte_member.h.

🌈 uint32_t top_k

How many top heavy hitters to be reported. The library will internally keep the keys of heavy hitters for the final report. crown them 👑

Definition at line 312 of file rte_member.h.

🌈 uint32_t extra_flag

Extra flags that may be passed in by user.

Definition at line 317 of file rte_member.h.

🌈 int socket_id

NUMA Socket ID for memory.

Definition at line 319 of file rte_member.h.

---

🌟 Author 🌟

Generated automatically by Doxygen for DPDK from the source code. (not a human, just a robot doing its lil thing 🤖✨)

---

and that's the whole page bestie, you ate 💅 ok so this was rte_member_parameters(3) from DPDK Version 25.11.3 — mwah, go build something iconic 🫶💖🌈