[dpdk-dev] [PATCH v3 15/18] librte_table: cosmetic enhancements in api file

[Cristian Dumitrescu <cristian.dumitrescu@intel.com>]

Consolidated hash tables into functional groups.
Minor changes in comments.

Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
---
 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 3c53d6a..081464c 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.7.4