Wide Key Hash Table Lookup via Fragment Segmentation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Fixed-hardware implementations of hash tables in networking applications do not allow for changes to key compositions, key sizes, memory locations, or table sizes after manufacturing, limiting programmability and flexibility.
Innovation Solution
A programmable system with wide key support that iterates over the fixed-width structure of a hash table, combines hash calculations of key fragments, issues multiple memory accesses, and merges partial key fragment comparison results to remove the fixed maximum key size restriction.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If fixed-hardware implementations of hash tables are used, then performance is improved, but programmability and flexibility are limited
Solution Approach 1:
The patent segments the key into multiple key fragments (e.g., first key fragment, second key fragment, third key fragment) that can be processed independently. Each fragment is compared separately against corresponding data lines in the hash table, allowing the system to handle keys wider than the data path size while maintaining hardware performance. This segmentation enables programmable control over key composition and table structure.
2Device complexity
If fixed-hardware implementations are used, then device complexity is reduced, but key size adaptability is restricted
Solution Approach 1:
The patent transitions from a single-wide-key comparison approach to a multi-fragment parallel comparison approach. By organizing the hash table with multiple data lines (first data line, second data line, third data line) corresponding to different key fragments, the system effectively adds a dimensional aspect to the key matching process, enabling support for arbitrary large key widths without proportionally increasing hardware complexity.
3Adaptability or versatility
If programmable solutions with configurable logic are implemented, then adaptability is improved, but maximum key size remains fixed due to hardware constraints
Solution Approach 1:
The patent divides the wide key into multiple smaller key fragments that can be processed through the fixed-width data path independently. Each fragment is extracted and compared against corresponding portions of the table entry, allowing the system to support keys larger than the hardware data path width while maintaining fixed hardware structure.
Solution Approach 2:
The patent employs a structured sequence of operations for processing wide keys: extracting key fragments in a specific order, comparing them against corresponding data lines, and combining results. This periodic action pattern (extract-first fragment, compare, extract-second fragment, compare, etc.) enables systematic handling of arbitrarily wide keys through fixed-width hardware.
4Adaptability or versatility
If multiple memory accesses are issued for wide key lookups, then key width support is improved, but access time increases
Solution Approach 1:
The patent performs preliminary hash calculation on the wide key to generate a hash value before the memory access phase. This preliminary action allows the system to determine the target table entry location in advance, enabling parallel or pipelined processing of key fragment comparisons while minimizing sequential access delays.
Data Source
AI summary
Described are input output (IO) device configured to perform operations for performing a table lookup with a single wide key larger than a width of a system bus. These operations comprise: receiving the lookup key; performing a plurality of extraction cycles to determine a plurality of key fragments; calculating a final hash value for the lookup key by sequentially calculating, via a hash chain, an interim hash value for each of the key fragments; determine a read access address for a table entry of a logic table based on the final hash value for the lookup key; determine a plurality of read requests based on the read access address; determine a hit on the table entry with the lookup key by issuing each of the read requests to the memory subsystem; and provide the hit on the table entry to the requesting entity or a next processing entity.