From: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Date: Wed, 18 Oct 2017 15:03:51 +0000 (+0100)
Subject: table: apply cosmetic enhancements to API
X-Git-Tag: spdx-start~1250
X-Git-Url: http://git.droids-corp.org/?a=commitdiff_plain;h=9285f423031cc5e9d7dea71938db8aeea6a39642;p=dpdk.git

table: apply cosmetic enhancements to API

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

Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
---

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