From 9285f423031cc5e9d7dea71938db8aeea6a39642 Mon Sep 17 00:00:00 2001 From: Cristian Dumitrescu Date: Wed, 18 Oct 2017 16:03:51 +0100 Subject: [PATCH] table: apply cosmetic enhancements to API Consolidated hash tables into functional groups. Minor changes in comments. Signed-off-by: Cristian Dumitrescu --- lib/librte_table/rte_table_hash.h | 34 ++++++++----------------------- 1 file changed, 9 insertions(+), 25 deletions(-) diff --git a/lib/librte_table/rte_table_hash.h b/lib/librte_table/rte_table_hash.h index 3c53d6ada5..081464c101 100644 --- a/lib/librte_table/rte_table_hash.h +++ b/lib/librte_table/rte_table_hash.h @@ -45,8 +45,6 @@ extern "C" { * These tables use the exact match criterion to uniquely associate data to * lookup keys. * - * Use-cases: Flow classification table, Address Resolution Protocol (ARP) table - * * Hash table types: * 1. Entry add strategy on bucket full: * a. Least Recently Used (LRU): One of the existing keys in the bucket is @@ -59,7 +57,7 @@ extern "C" { * 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. + * specific data structures per each bucket. Use-cases: flow cache, etc. * b. Extendible 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 @@ -73,20 +71,8 @@ extern "C" { * 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 * extendible bucket logic requires maintaining specific data structures - * per table and per each bucket. - * 2. Key signature computation: - * a. Pre-computed key signature: The key lookup operation is split between - * two CPU cores. The first CPU core (typically the CPU core performing - * packet RX) extracts the key from the input packet, computes the key - * signature and saves both the key and the key signature in the packet - * buffer as packet meta-data. The second CPU core reads both the key and - * the key signature from the packet meta-data and performs the bucket - * search step of the key lookup operation. - * b. Key signature computed on lookup (do-sig): The same CPU core reads - * the key from the packet meta-data, uses it to compute the key - * signature and also performs the bucket search step of the key lookup - * operation. - * 3. Key size: + * 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) * @@ -129,22 +115,20 @@ struct rte_table_hash_params { uint64_t seed; }; +/** Extendible bucket hash table operations */ extern struct rte_table_ops rte_table_hash_ext_ops; +extern struct rte_table_ops rte_table_hash_key8_ext_ops; +extern struct rte_table_ops rte_table_hash_key16_ext_ops; +extern struct rte_table_ops rte_table_hash_key32_ext_ops; +/** LRU hash table operations */ extern struct rte_table_ops rte_table_hash_lru_ops; extern struct rte_table_ops rte_table_hash_key8_lru_ops; - -extern struct rte_table_ops rte_table_hash_key8_ext_ops; - extern struct rte_table_ops rte_table_hash_key16_lru_ops; - -extern struct rte_table_ops rte_table_hash_key16_ext_ops; - extern struct rte_table_ops rte_table_hash_key32_lru_ops; -extern struct rte_table_ops rte_table_hash_key32_ext_ops; - +/** Cuckoo hash table operations */ extern struct rte_table_ops rte_table_hash_cuckoo_ops; #ifdef __cplusplus -- 2.20.1