rte_table_hash.h(3)

💖 rte_table_hash.h — bestie's guide to the hash tables 💖

okay so this is the manual page for rte_table_hash.h, from the Library Functions Manual, and honestly? she's iconic. sit down, grab a strawberry 🍓, and let's get into it.

---

✨ NAME ✨

rte_table_hash.h — the header that gives you RTE hash tables, no cap.

---

🦋 SYNOPSIS 🦋

#include <stdint.h>
#include 'rte_table.h'

🎀 Data Structures

• struct rte_table_hash_params

🧚 Typedefs

• typedef uint64_t(* rte_table_hash_op_hash) (void *key, void *key_mask, uint32_t key_size, uint64_t seed)

🌸 Variables

• struct rte_table_ops rte_table_hash_ext_ops
• struct rte_table_ops rte_table_hash_lru_ops

---

👑 Detailed Description 👑

RTE Table Hash

These tables use the exact match criterion to uniquely associate data to lookup keys. like, no fuzzy matching, no "close enough" — exact. periodt.

Hash table types:

1. Entry add strategy on bucket full:

a. Least Recently Used (LRU): One of the existing keys in the bucket is deleted and the new key is added in its place. The number of keys in each bucket never grows bigger than 4. The logic to pick the key to be dropped from the bucket is LRU. The hash table lookup operation maintains the order in which the keys in the same bucket are hit, so every time a key is hit, it becomes the new Most Recently Used (MRU) key, i.e. the most unlikely candidate for drop. When a key is added to the bucket, it also becomes the new MRU key. When a key needs to be picked and dropped, the most likely candidate for drop, i.e. the current LRU key, is always picked. The LRU logic requires maintaining specific data structures per each bucket. Use-cases: flow cache, etc.

b. Extendable bucket (ext): The bucket is extended with space for 4 more keys. This is done by allocating additional memory at table init time, which is used to create a pool of free keys (the size of this pool is configurable and always a multiple of 4). On key add operation, the allocation of a group of 4 keys only happens successfully within the limit of free keys, otherwise the key add operation fails. On key delete operation, a group of 4 keys is freed back to the pool of free keys when the key to be deleted is the only key that was used within its group of 4 keys at that time. On key lookup operation, if the current bucket is in extended state and a match is not found in the first group of 4 keys, the search continues beyond the first group of 4 keys, potentially until all keys in this bucket are examined. The extendable bucket logic requires maintaining specific data structures per table and per each bucket. Use-cases: flow table, etc.

2. Key size:

a. Configurable key size

b. Single key size (8-byte, 16-byte or 32-byte key size)

Definition in file rte_table_hash.h.

---

💅 Typedef Documentation 💅

typedef uint64_t(* rte_table_hash_op_hash) (void *key, void *key_mask, uint32_t key_size, uint64_t seed)

Hash function 💖

Definition at line 56 of file rte_table_hash.h.

---

🌈 Variable Documentation 🌈

struct rte_table_ops rte_table_hash_ext_ops [extern]

Extendable bucket hash table operations ✨

struct rte_table_ops rte_table_hash_lru_ops [extern]

LRU hash table operations ✨

---

🫶 Author 🫶

Generated automatically by Doxygen for DPDK from the source code.

---

that's the whole page bestie, we ate and left no crumbs 💅

and a lil sign-off for u: this one's from DPDK, Version 25.11.3, dated with the rte_table_hash.h(3) footer energy — slay, go build something cute with it 🦋💜