Data query method and chip based on distributed lookup table and cache framework

Abstract

The application discloses a data query method and chip based on a distributed lookup table and cache framework, comprising: a lookup engine receiving a wide key to be queried; the lookup engine performing iterative hash calculation on the wide key to generate a digest key, and sending the digest key to a corresponding distributed storage node through a key-value network on chip; the distributed storage node locally querying a hash table item matched with the digest key; if the matching succeeds, a success response is returned to the lookup engine through a result network on chip, the response containing a wide table logical address index; if the matching fails, a failure response and iteration control information are returned to the lookup engine; the lookup engine updates the query parameters according to the iteration control information and initiates the matching query again; the lookup engine receives the wide table data segment returned through the key-value network on chip, and recombines and verifies the data segment to complete the query. The application effectively solves the technical problems of large-scale table item distribution and efficient table lookup in high-performance network switching.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, and in particular to a data query method and chip based on a distributed lookup table and caching framework. Background Technology

[0002] With the rapid development of ultra-large-scale cloud networks, storage networks, and high-performance computing, network data exchange volume is growing exponentially. Against this backdrop, the lookup performance of switch chips, as the core engine of data forwarding, has become a key bottleneck determining the overall system throughput and latency. The essence of a lookup operation is to convert complex routing calculations into memory address accesses to pre-stored forwarding table entries. However, due to limitations in chip physical design, the depth and bit width of the Static Random Access Memory (SRAM) occupied by a single stored table entry are strictly limited. While a larger bit width allows for more information to be obtained in a single access, it significantly increases chip area and power consumption. Therefore, the SRAM bit width is a trade-off between performance, cost, and functional requirements. This hardware constraint directly leads to the challenge of processing "wide-key, wide-table data" (i.e., table entries whose length far exceeds the SRAM bit width). How to efficiently store and retrieve such entries has become a core challenge restricting the performance of high-end switch chips.

[0003] To address these challenges, distributed table lookup has become the standard architecture for high-performance network switches, alleviating performance bottlenecks by distributing large-scale table entries across multiple processing units. However, existing distributed wide hash table processing schemes have significant inherent drawbacks:

[0004] The core problem lies in the low efficiency of network transmission. Due to the bit width limitations of SRAM and Network On Chip (NoC), a complete "wide key" must be split into multiple data fragments and sent multiple times through the NoC to one or more lookup destinations (distributed storage nodes). Similarly, the large "wide result" also needs to be returned multiple times. This processing method means that the data traffic generated on the NoC is amplified, consuming valuable network bandwidth and potentially causing network congestion in severe cases. In addition, when hash collisions occur, the entire lookup process may require multiple iterations, and the above data transmission process will be repeated, further amplifying network pressure, leading to decreased table lookup efficiency and increased packet forwarding latency. Summary of the Invention

[0005] In view of the technical defects and drawbacks existing in the prior art, embodiments of the present invention provide a data query method and chip based on a distributed table lookup and caching framework to overcome the above problems or at least partially solve the above problems. The specific solution is as follows:

[0006] As a first aspect of the present invention, a data query method based on a distributed table lookup and caching framework is provided, comprising the following steps:

[0007] S1. The search engine receives the wide key to be queried, wherein the bit width of the wide key is greater than the bit width of NoC;

[0008] S2. The search engine performs iterative hash calculation on the wide key to generate a fixed-length digest key, and sends the digest key to the corresponding distributed storage node for first-level matching query through Key-NoC network.

[0009] S3. The distributed storage node queries the local hash table for an entry that matches the digest key;

[0010] If a match is found, a success response is returned to the search engine via the Result-NoC network, which contains an index pointing to the logical address of the wide table.

[0011] If the match fails, a failure response and iteration control information are returned to the search engine. The search engine updates the query parameters according to the iteration control information and jumps to step S2.

[0012] S4. After receiving a successful response, the search engine initiates a wide table data request to one or more of the distributed storage nodes via Key-NoC based on the wide table logical address.

[0013] S5. The distributed storage node returns the wide table data segment corresponding to the logical address of the wide table. The search engine reassembles and verifies the received wide table data segment to complete the query.

[0014] Further, in step S2, the search engine performs iterative hash calculations on the wide key to generate the fixed-length digest key, specifically including:

[0015] S2.1 Data Fragmentation: Based on the bit width of the on-chip network NoC, the wide key is sequentially split into one or more fixed-length data units, wherein if the last data unit is not long enough, zero padding is performed to align the bit width;

[0016] S2.2 Iterative Summary: The fixed-length data units are sequentially input into a hash function for chained computation; wherein,

[0017] The hash calculation of the first fixed-length data unit takes its own data as input;

[0018] The hash calculation for each subsequent fixed-length data unit is based on the combination of the hash calculation result of the previous data unit and the current data unit as input.

[0019] S2.3, Summary generation: The hash value output after the last fixed-length data unit has been hashed is determined as the summary key used for the first-level matching query.

[0020] Further, in step S4, the lookup engine initiates a wide table data request based on the wide table logical address, specifically including:

[0021] S4.1 Request Key Generation: The search engine derives a set of consecutive request keys for the logical address of the wide table based on the total number of data segments in the wide table data result; wherein, each request key is calculated by adding a predetermined offset to the logical address of the wide table, and each offset corresponds to a data segment to be retrieved;

[0022] S4.2 Parallel Distribution: The lookup engine uses Key-NoC to concurrently route the set of request keys to one or more corresponding distributed storage nodes to trigger parallel read operations on multiple wide table data segments.

[0023] The wide table logical address serves as the base address, and different offsets are applied to locate different data segments under it, which is the core mechanism for achieving efficient parallel access.

[0024] Furthermore, in step S5, the search engine reassembles and verifies the received wide table data segments, specifically including:

[0025] S5.1 Data Reception and Reassembly: The search engine receives the data segments returned via Result-NoC; and reassembles the wide key data segments and wide table data segments belonging to the same query request into complete wide key and wide table data according to the sequence labels attached to the data segments.

[0026] S5.2 Final Verification: The search engine performs a full-width exact comparison between the recombined wide key and the original query wide key received in step S1, and executes a branch operation based on the comparison result:

[0027] Validation successful: If the restructured wide key is exactly the same as the original wide key to be queried, it is determined that the final match is successful, and then the search engine executes the pre-defined action associated with the restructured complete wide table data;

[0028] Verification failure: If the recombined wide key is inconsistent with the original wide key to be queried, it is determined that the summary query has matched the wrong table entry due to hash collision, that is, a false match has occurred; the search engine then updates the query parameters according to the predefined iteration control strategy and re-initiates the matching query (i.e., jumps to step S3) until the verification is successful or the maximum number of iterations is reached.

[0029] Furthermore, the method also includes a cache query process that runs in parallel with the summary query phase, used to accelerate the query response of hotkeys through local caching; before initiating a distributed summary query, the search engine prioritizes submitting the summary key to the cache module for matching query;

[0030] The caching module has a built-in hotkey entry management strategy, which performs corresponding operations according to the local cache hit status and resource status, following the logical decision tree:

[0031] First decision branch: If the digest key matches any hotkey entry in the local cache, proceed to the result check sub-branch:

[0032] If the wide table data associated with the hotkey entry has been fully cached, the caching module directly returns the wide table data to the search engine, thereby completely bypassing the subsequent distributed query process.

[0033] If the wide table data associated with the hotkey entry has not yet been cached, the caching module waits to receive the wide table data returned from Result-NoC, caches it, and then responds to subsequent queries with the same digest key by returning the wide table data to the search engine.

[0034] Second decision branch: If the summary key does not match any local hotkey entry, proceed to the learning eligibility determination sub-branch:

[0035] If the current learning conditions are met based on a comprehensive evaluation of popularity, network congestion, and cache idle resources, the caching module performs a formal learning operation: it assigns a new hotkey entry to the digest key and sends a learning tag signal to the search engine (the caching module instructs the search engine to capture and store the wide table data returned by the distributed query by sending the learning tag); simultaneously, it passes the digest key to Key-NoC to initiate a normal distributed query process; after the result is returned, the caching module captures and stores the wide table data according to the learning tag;

[0036] If the preset learning conditions are not met, the caching module will directly pass the digest key to Key-NoC without performing local learning.

[0037] Furthermore, the preset learning condition is that the following three conditions are met simultaneously:

[0038] (1) The real-time access frequency of the digest key exceeds a first preset threshold;

[0039] (2) The current congestion level of the on-chip network is lower than the second preset threshold;

[0040] (3) The number of free storage entries in the cache module is higher than the third preset threshold.

[0041] Furthermore, the caching module also performs periodic cache entry aging management operations to automatically evict less popular entries to free up resources, specifically including:

[0042] S7.1, Aging Trigger: A global timer periodically triggers the aging management operation of all cache entries;

[0043] S7.2, Heat decay: In each aging cycle, the heat counter value of each learned cached entry is decremented once;

[0044] S7.3 Resource reclamation: Continuously check the heat counter value of all cached entries. If the heat counter value of an entry falls below the preset aging threshold after decay, it is determined that the entry is no longer active. Then, the association between the digest key and the wide table data in the entry is released, and the storage resources it occupies are reclaimed. The entry status is marked as idle and available.

[0045] Furthermore, the data structure of the hash table entries in the distributed storage node is as follows: a hash table entry structure that determines the storage digest key based on the memory bit width, wherein each hash table entry includes an iteration control information field, a digest key field, and a wide table logical address index field.

[0046] The logical storage unit for a wide table entry consists of two SRAM storage entries:

[0047] The first entry is used to store the wide-key data segment;

[0048] The second entry is used to store the wide table data segment;

[0049] The address pointed to by the wide table address index field is the address of the first entry.

[0050] As a second aspect of the present invention, a chip is provided, comprising:

[0051] A lookup engine is used to receive the wide key to be queried, perform iterative hash calculation on the wide key to generate a fixed-length digest key, and send the digest key to the corresponding distributed storage node for first-level matching query through the key-value on-chip network. The bit width of the wide key is greater than the bit width of the on-chip network.

[0052] Distributed storage nodes are used to query entries in the local hash table that match the digest key. If a match is successful, a success response is returned to the search engine via the result on-chip network. This response contains an index pointing to the logical address of the wide table. If a match fails, a failure response and iteration control information are returned to the search engine. The search engine updates the query parameters according to the iteration control information and re-initiates the matching query until a match is successful or the maximum number of iterations is reached.

[0053] The search engine is also used to, upon receiving a successful response, initiate a wide table data request to one or more of the distributed storage nodes via a key-value on-chip network based on the wide table logical address; the distributed storage nodes are also used to return a wide table data segment corresponding to the wide table logical address, so that the search engine can reassemble and verify the received wide table data segment to complete the query.

[0054] Furthermore, the chip also includes a cache module;

[0055] The search engine is also used to send the summary key to the cache module before initiating the distributed summary query;

[0056] The caching module is used for:

[0057] If the digest key matches a locally stored hotkey entry and the associated wide table data is cached, then the wide table data is returned to the lookup engine;

[0058] If the summary key matches a hotkey entry but the associated wide table data is not cached, then wait to receive the associated wide table data, and after caching, return the wide table data to the search engine;

[0059] If the digest key does not match any hotkey entry and meets a preset learning condition, a new entry is assigned to the digest key, a learning tag is sent to the search engine, and the digest key is forwarded to the key-value on-chip network.

[0060] If the digest key does not match any hotkey entry and does not meet the preset learning conditions, then the digest key is forwarded to the key-value on-chip network.

[0061] The search engine is also used to forward the wide table data returned by the distributed storage node to the cache module for storage after receiving the learned tags.

[0062] The present invention has the following beneficial effects:

[0063] This invention employs a two-level distributed lookup table architecture, compressing the wide key into a fixed-length digest key for transmission. This reduces the number of data packets in the on-chip network, alleviating network congestion at the source, lowering packet forwarding latency, and improving system throughput. Simultaneously, a full-width verification mechanism is introduced, precisely comparing the returned data with the original wide key to eliminate the risk of false matches caused by hash collisions, ensuring the accuracy of query results. Furthermore, by integrating an intelligent caching module, it dynamically identifies hotkeys and decides on cache learning based on multi-dimensional indicators, enabling local responses to high-frequency queries and reducing query latency. Attached Figure Description

[0064] Figure 1 A flowchart illustrating a data query method based on a distributed table lookup and caching framework provided in an embodiment of the present invention;

[0065] Figure 2 This is a schematic diagram of a specific Wide Hash lookup process provided in an embodiment of the present invention;

[0066] Figure 3 This is a schematic diagram illustrating the data interaction process between the search engine and the cache module provided in an embodiment of the present invention. Detailed Implementation

[0067] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0068] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0069] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0070] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0071] To address at least one of the technical problems existing in the aforementioned related technologies, this invention provides a data query method based on a distributed lookup table and caching framework. Figure 1 A flowchart illustrating a data query method based on a distributed table lookup and caching framework, provided for an embodiment of the present invention, includes the following steps:

[0072] S1. The search engine receives the wide key to be queried, wherein the bit width of the wide key is greater than the bit width of the on-chip network NoC;

[0073] S2. The search engine performs iterative hash calculation on the wide key to generate a fixed-length digest key, and sends the digest key to the corresponding distributed storage node for first-level matching query via Key-NoC;

[0074] S3. The distributed storage node queries the local hash table for an entry that matches the digest key;

[0075] If a match is found, a success response is returned to the search engine via Result-NoC, which contains an index pointing to the logical address of the wide table;

[0076] If the match fails, a failure response and iteration control information are returned to the search engine. The search engine updates the query parameters according to the iteration control information and jumps to step S2.

[0077] S4. After receiving a successful response, the search engine initiates a wide table data request to one or more of the distributed storage nodes via Key-NoC based on the wide table logical address.

[0078] S5. The distributed storage node returns the wide table data segment corresponding to the logical address of the wide table. The search engine reassembles and verifies the received wide table data segment to complete the query.

[0079] This invention solves the problem of inefficient transmission and comparison of wide keys in NoC by using a fixed-length intermediate key called a "digest key". By decomposing a complex wide key query into two stages, fast digest matching and accurate wide table verification, the invention ensures the absolute accuracy of the final result (through full-width verification) while greatly reducing the amount of data transmitted on NoC, reducing network bandwidth pressure, and improving query response speed and system throughput.

[0080] In some embodiments, the lookup engine in step S2 performs iterative hash calculations on the wide key to generate the fixed-length digest key, specifically including:

[0081] S2.1 Data Fragmentation: Based on the bit width of the on-chip network NoC, the wide key is sequentially split into one or more fixed-length data units, wherein if the last data unit is not long enough, zero padding is performed to align the bit width;

[0082] S2.2 Iterative Summary: The fixed-length data units are sequentially input into a hash function for chained computation; wherein,

[0083] The hash calculation of the first fixed-length data unit takes its own data as input;

[0084] For each subsequent hash calculation of the fixed-length data unit, the hash calculation result of the previous data unit is concatenated with the current data unit, and the concatenated result is used as the input.

[0085] S2.3, Summary generation: The hash value output after the last fixed-length data unit has been hashed is determined as the summary key used for the first-level matching query.

[0086] The above implementation provides a specific and efficient iterative hashing method for generating fixed-length digest keys from keys of arbitrary width. Through data sharding and zero-padding operations, it can handle input keys of any bit width and has strong adaptability. By using chained hashing, the generation of the final digest key depends on all input data units. Any change in any bit will result in a completely different digest key, which improves the uniqueness and hash uniformity of the digest key and lays the foundation for the reliability of the first-level fast matching.

[0087] See Figure 2 The diagram illustrates the data interaction process between the search engine and the cache module provided in this embodiment of the invention. It specifically demonstrates the complete distributed lookup process of the search engine processing wide keys. After receiving the wide key, the search engine generates a fixed-length digest key (8 bytes) through iterative hash calculation. This digest key is sent to the distributed storage node via Key-NoC for the first-level matching query. If the match is successful, the distributed storage node returns the wide table address index + 0 and the corresponding index result. Based on the returned wide table address index + 0, the search engine derives a set of consecutive request keys (e.g., wide table address index + 0, wide table address index + 1, wide table address index + 2). A single wide table address index can serve as the base address, allowing multiple request keys to be derived concurrently, thus retrieving multiple data segments (e.g., returning results 0, 1, and 2). If a hash collision is detected, the query is re-initiated using iterative control information.

[0088] Both the widekey data segment and the widetable data are stored in the static random access memory (SRAM) of the distributed storage nodes. Since the physical bit width of the SRAM (e.g., 20 bytes in the example) is fixed, while the bit width of the widekey (e.g., 32 bytes) and the widetable data (e.g., 24 bytes) is typically much larger, a fragmented storage strategy must be employed. A complete widetable entry physically consists of multiple consecutive SRAM storage entries. The size of each entry is strictly aligned with the bit width of the SRAM. For example, the first entry (corresponding to request key 0A): is used to store the widekey data segment. For example, the first 16 bytes of a 32-byte widekey (the remaining bit width can be used to store control information or padding); the second entry (corresponding to request key 1A): is used to store the first part of the widetable data segment. For example, core information such as forwarding actions and next-hop addresses; the third entry (corresponding to request key 2A, if needed): is used to store the second part of the widetable data segment. For example, extended metadata such as statistics and timestamps.

[0089] The following example illustrates this.

[0090] In this example, we assume that the SRAM and NoC bit widths are both 20 bytes (160 bits), the wide key is 32 bytes (256 bits), covering typical high-dimensional network identifiers, such as the combination of IPv6 address and MAC address, the hash function uses CRC32 (output 4 bytes), and the hash table entry structure is: 10 bytes per entry (1B control + 6B digest + 3B index), and two entries are stored in a single SRAM entry (20B).

[0091] The query process is as follows:

[0092] 1. Hash Phase (Digest Key Generation and Matching)

[0093] Data fragmentation: The lookup engine receives a 32-byte wide key and splits it into two 16-byte (128-bit) data units, namely Unit1 and Unit2. Unit1 corresponds to bytes 0-15, and Unit2 corresponds to bytes 16-31, to match the 20-bit width of NoC (16-byte data + 4-byte header during transmission).

[0094] Iterative hash calculation:

[0095] Initial hash calculation: Calculate the hash of Unit1: Hash1 = CRC32(Unit1) → Generate a 4-byte digest.

[0096] Iterative hash calculation: Concatenate Hash1 (4B) and Unit2 (16B) into a 20-byte input (aligned with NoC bit width), calculate Hash2 = CRC32(Hash1∥Unit2), and use Hash2 as the final digest key (finally generating a 4-byte digest key) for the first-level matching query (even if only one bit of data changes in the wide key, this chain-like iterative hash calculation will result in a significantly different digest key, thereby reducing the probability of hash collisions in the first-level matching stage).

[0097] Digest transmission:

[0098] The lookup engine sends a 4-byte digest key via Key-NoC (20-bit width) (the remaining bandwidth is used for routing and control information).

[0099] Distributed matching:

[0100] The storage node extracts the lower 6 bits of the digest key (compatible with 4B digests and with reserved extension bits) from its local hash table for comparison:

[0101] If a match is successful: Returns a 3-byte wide table logical address index and a 1-byte iteration control information (4 bytes in total, utilizing Result-NoC bandwidth);

[0102] If a match fails: return a failure response and iteration control information, and trigger a retry.

[0103] 2. Table Phase (Wide Table Data Acquisition and Validation)

[0104] Wide table data request:

[0105] The lookup engine uses a 3-byte wide table address index to derive the request key (base address + offset). For example:

[0106] Offset 0: Request the wide key data segment (stored in the first entry of the wide table);

[0107] Offset 1: Request a wide table data segment (stored in the second entry of the wide table).

[0108] Concurrent requests via Key-NoC (each request packet is 20 bytes, including address and control information).

[0109] Data restructuring and verification:

[0110] The storage node returns data segments (each 20 bytes, including 16 bytes of data + 4 bytes of sequence tag), and the lookup engine reassembles them based on the tags:

[0111] A full-bit width comparison is performed between the recombined wide key (32B) and the original wide key:

[0112] If they match, the verification is successful, and the forwarding action is executed.

[0113] If there is a mismatch, it is determined to be a false match, triggering an iterative re-examination (updating parameters using 1B control information).

[0114] In some embodiments, in step S4, the lookup engine initiates a wide table data request based on the wide table logical address. Specifically, this is implemented to retrieve wide table data segments that may be stored in different physical locations in parallel. This process includes:

[0115] S4.1 Request Key Generation: The lookup engine derives a set of consecutive request keys for the logical address of the wide table based on the total number of data segments in the wide table data; wherein, each request key is calculated by adding a predetermined offset to the logical address of the wide table, and each offset corresponds to a data segment to be retrieved;

[0116] S4.2 Parallel Distribution: The lookup engine uses Key-NoC to concurrently route the set of request keys to one or more corresponding distributed storage nodes to trigger parallel read operations on multiple wide table data segments.

[0117] The wide table logical address serves as the base address, and different offsets are applied to locate different data segments under it, which is the core mechanism for achieving efficient parallel access.

[0118] In the above embodiments, by deriving a set of consecutive request keys for a single wide table logical address and distributing them in parallel, efficient and parallel reading of wide table data segments is achieved. By splitting a large-scale data read request into multiple small requests that can be processed in parallel, the parallel transmission capabilities of the distributed storage architecture and NoC are fully utilized, thereby accelerating the most critical data acquisition stage and improving the overall query performance.

[0119] In some embodiments, in step S5, the search engine reassembles and verifies the received wide table data segment. This step constitutes the final verification mechanism to ensure the absolute correctness of the query results, and is used to resolve the false matching problem caused by possible hash digest collisions. This process specifically includes:

[0120] S5.1 Data Reception and Reassembly: The search engine receives wide table data segments returned by Result-NoC; these data segments may contain wide key data segments and wide table data segments, and may arrive out of order due to parallel requests; the search engine reassembles the wide key data segments and wide table data segments belonging to the same query request into complete wide key and wide table data respectively, according to the sequence tags attached to the data segments.

[0121] S5.2 Final Verification: The search engine performs a full-width exact comparison between the recombined wide key and the original query wide key received in step S1, and executes a branch operation based on the comparison result:

[0122] Validation successful: If the restructured wide key is exactly the same as the original wide key to be queried, it is determined that the final match is successful, and then the search engine executes the pre-defined action associated with the restructured complete wide table data;

[0123] Verification failure: If the recombined wide key is inconsistent with the original wide key to be queried, it is determined that the summary query has matched the wrong table entry due to hash collision, that is, a false match has occurred; the search engine then updates the query parameters according to the predefined iteration control strategy and re-initiates the matching query (i.e., jumps to step S3) until the verification is successful or the maximum number of iterations is reached.

[0124] The iteration control information includes key fields for adjusting query parameters. The search engine changes the hash calculation path based on these parameters to try new storage nodes or hash functions. Specific adjustment methods include, but are not limited to:

[0125] Hash seed adjustment:

[0126] The iteration control information includes a dynamically updatable hash seed. During each iteration, the search engine XORs or concatenates the seed with the digest key to change the input value of the hash function.

[0127] For example: Initial hash calculation: Digest key = CRC32 (wide key);

[0128] If the first iteration fails: New digest key = CRC32(digest key / / iteration control information.hash seed)

[0129] The hash seed value is typically generated based on the number of iterations, node ID, or random number to ensure that the hash path is different each time.

[0130] Target storage node remapping:

[0131] The iteration control information includes a node offset or remapping table index, and the lookup engine modifies the address calculation rules of the target storage node based on this offset.

[0132] For example:

[0133] Initial node address: Node ID = Hash(digest key) % Total number of nodes;

[0134] Adjusted node address: New node ID = (Hash(digest key) + iteration control information.node offset) % total number of nodes;

[0135] By changing the offset of the modulo operation, queries are routed to different distributed storage nodes, avoiding repeated access to conflicting nodes.

[0136] Hash function switching:

[0137] The iterative control information specifies an alternative hash function identifier (such as CRC32, MurmurHash, etc.). The lookup engine switches hash algorithms after multiple failures, changing the way the digest key is generated.

[0138] For example:

[0139] First time using CRC32: Digest key = CRC32 (wide key);

[0140] If it fails, switch to MurmurHash: New digest key = MurmurHash(wide key);

[0141] Different hash functions have different hashing properties, which can reduce the probability of collisions.

[0142] Rehashing count control:

[0143] The iteration control information includes the current number of retries (Retry Count) and the maximum number of retries (MaxRetries). The search engine decides whether to terminate the query or further adjust the parameters based on the number of retries.

[0144] If the number of retries exceeds the threshold, the query will be terminated and an error will be returned.

[0145] Otherwise, adjust the parameters as described above and resubmit the query.

[0146] By adjusting the above parameters, the search engine can dynamically change the hash path, resolve false matches caused by hash collisions, and improve the query success rate.

[0147] In the above embodiments, the risk of "false matching" caused by hash collisions is eliminated by full-width precise comparison, ensuring that the query results are foolproof; when a verification failure occurs, a new round of query is automatically triggered (updating parameters to change the hash path), enabling the system to recover from hash collisions, ensuring the success rate of the query and improving the reliability of the system.

[0148] In some embodiments, the method further includes a cache query process running in parallel with the summary query phase, used to accelerate the query response of hotkeys through local caching; before initiating a distributed summary query, the search engine first submits the summary key to the cache module for matching query. If a hotkey entry is matched and the wide table data is already cached, the result is returned directly (bypassing the distributed query); if no match is found but the learning conditions are met, a learning flag is triggered, a distributed query is initiated through the Key-NoC network, and the wide table data is returned to the cache module for learning storage through the Result-NoC network; the following is in conjunction with the appendix Figure 3 Explain its working mechanism in detail.

[0149] 1. Deployment and core function of the caching module:

[0150] A first-level cache module (Cache) is added between the search engine and the key-value on-chip network (Key-Noc). Its core function is to locally cache frequently occurring query keys (hotkeys) and their corresponding wide table data results. When subsequent identical query requests arrive, the search engine can directly retrieve the results from the local cache, completely bypassing the subsequent distributed storage node query process, thereby significantly reducing query latency and accelerating table lookup.

[0151] 2. Processing flow of the caching module (see...) Figure 3 ):

[0152] The Cache module has a built-in hotkey entry management strategy, which performs corresponding operations according to the following logical decision tree based on the local cache hit status and system resource status:

[0153] First decision branch: Cache hit.

[0154] If the digest key submitted by the search engine matches any hotkey entry in the local cache, proceed to the result inspection subbranch:

[0155] If the wide table data associated with the hotkey entry has been fully cached, the Cache module will directly return the wide table data to the search engine, and the query will be completed.

[0156] If the wide table data associated with the hotkey entry is not yet cached, it indicates that the key entry has only learned the digest key, and the complete result is on its way from the distributed query. The Cache module waits to receive the wide table data finally returned from Result-Noc, learns and stores it, and then responds to subsequent queries with the same digest key.

[0157] Second decision branch: Cache Miss and learning decision

[0158] If the digest key does not match any local hotkey entry, the process proceeds to the preset learning condition determination sub-branch. The preset learning condition is a dynamic and adaptive determination strategy. Its determination process is not based on a single fixed threshold, but rather on a real-time comprehensive calculation and consideration of the following three system state factors by the Cache module:

[0159] (a) Key value hotness factor: refers to the real-time access frequency quantization value corresponding to the digest key. This value is implemented by an incrementing counter, which increases the count with each access, thereby characterizing the potential probability of the key becoming a hot key;

[0160] (b) Network load factor: refers to the current network transmission pressure assessed by real-time monitoring of data traffic and congestion status of Key-NoC and Result-NoC; the more congested the network, the more the learning operation may increase the burden on the control path, so the learning conditions tend not to be met, that is, the congestion level must be below a certain threshold before learning is allowed.

[0161] (c) Storage resource factor: refers to the number of currently available storage entries in the cache module; when resources are sufficient, it tends to learn actively, while when resources are scarce, it tends to be conservative and only learns the most popular keys.

[0162] The caching module uses built-in decision logic to uniformly evaluate the three factors mentioned above; only when the comprehensive evaluation result indicates that the positive system benefit of the learning behavior is higher than the preset threshold is it determined that the learning condition is met, thereby triggering the operation of assigning a new entry to the summary key.

[0163] If the preset learning conditions based on the comprehensive evaluation of the above factors are met, then the Cache module will perform the formal learning operation.

[0164] Assign a new hotkey entry to the summary key; send a learning tag signal to the search engine;

[0165] At the same time, the digest key is passed through to Key-Noc to initiate the normal distributed query process.

[0166] When the query results are returned to the search engine via Result-Noc, the search engine forwards the wide table data to the Cache module based on the received learning tags. The Cache module then stores it in the result storage area of ​​the allocated entries, completing the learning process.

[0167] If the preset learning conditions are not met, the Cache module will directly pass the digest key to Key-Noc without performing local learning, and the request will be completed by the distributed query process.

[0168] 3. Aging and eviction mechanism for cached entries:

[0169] The Cache module also performs periodic cache entry aging management operations to automatically evict less popular entries to free up resources:

[0170] The decay is periodically triggered by a global timer;

[0171] Decrement the heat counter value for each learned cached entry;

[0172] If the heat counter value of an entry decays below the preset aging threshold, the entry is determined to be no longer active. The association between its key value and data is then severed, storage resources are reclaimed, and the entry is marked as idle.

[0173] Through the above mechanism, the caching module can intelligently identify and accelerate hotkey queries, while avoiding cache pollution when system resources are scarce, and continuously optimizing overall query performance.

[0174] The learning tag is a control signal sent by the caching module to the lookup engine. Its core function is to indicate that the results returned by the wide table data in the current query need to be captured, learned, and stored by the caching module. Combined with... Figure 3 As shown, the specific workflow is as follows:

[0175] Conditions for generating learning tags:

[0176] When a digest key is not cached and the preset learning conditions (access frequency, network congestion, and comprehensive evaluation of cache resources) are met, the cache module allocates a new entry for the digest key during the learning operation and sends a learning tag signal to the lookup engine.

[0177] Transmission and association of learned tags:

[0178] The learned tokens are bound to the metadata of the query request (such as query ID and digest key) and transmitted to the search engine via a dedicated control channel or additional fields in the data packet header.

[0179] After receiving the learned tag, the search engine associates it with the current query context and stores it for recognition when returning subsequent results.

[0180] Learning tags trigger result capture:

[0181] When the query results (wide table data) from the distributed storage nodes are returned to the search engine via Result-NoC, the search engine checks whether the associated learned tags exist:

[0182] If it exists, the lookup engine will forward the wide table data to the cache module while performing pre-defined actions (such as message forwarding);

[0183] If it does not exist, the result will be processed normally without triggering cache learning.

[0184] After receiving the wide table data, the caching module stores it in the result storage area of ​​the allocated entries, thus completing the learning process.

[0185] By learning the tagging mechanism, the caching module can dynamically expand hotkey entries, and subsequent queries with the same digest key can directly retrieve results from the cache, improving the efficiency of hotkey queries.

[0186] The above embodiment introduces an intelligent caching mechanism that runs parallel to the main query process. For frequently accessed "hot keys," results can be directly retrieved from the local cache, completely bypassing time-consuming distributed queries and greatly reducing query latency. Through multi-factor decision-making (popularity, network, resources), it intelligently determines whether to cache new keys, avoiding blindly caching invalid data, ensuring efficient use of cache space, and preventing cache pollution. Through resource awareness, learning is paused when the system is under high load or resources are scarce, preventing caching operations from exacerbating system congestion and demonstrating good system synergy.

[0187] Optionally, the preset learning condition is to simultaneously satisfy the following three conditions:

[0188] (1) The real-time access frequency of the digest key exceeds a first preset threshold;

[0189] (2) The current congestion level of the on-chip network is lower than the second preset threshold;

[0190] (3) The number of free storage entries in the cache module is higher than the third preset threshold.

[0191] The caching module is configured to continuously monitor and evaluate the above three conditions in order to dynamically decide whether to perform a learning operation.

[0192] The above embodiments further refine and optimize the learning conditions for caching, achieving refined and adaptive control of cache learning. Specifically, by constructing a multi-factor collaborative decision-making model, it ensures that the creation of new entries only occurs when three conditions are simultaneously met: high access frequency, good network (transmission) conditions, and sufficient cache (resources). This maximizes the value of each new cached entry and ensures that caching operations do not negatively impact the current system performance, thus achieving an optimal balance between accelerating queries and system stability.

[0193] In some embodiments, the caching module also performs periodic cache entry aging management operations to automatically evict less popular entries to free up resources, specifically including:

[0194] S7.1, Aging Trigger: A global timer periodically triggers the aging management operation of all cache entries;

[0195] S7.2, Heat decay: In each aging cycle, the heat counter value of each learned cached entry is decremented once;

[0196] S7.3 Resource reclamation: Continuously check the heat counter value of all cached entries. If the heat counter value of an entry falls below the preset aging threshold after decay, it is determined that the entry is no longer active. Then, the association between the digest key and the wide table data in the entry is released, and the storage resources it occupies are reclaimed. The entry status is marked as idle and available.

[0197] The aging management operation and the learning condition determination together form a complete cache lifecycle management closed loop, dynamically maintaining the efficiency and effectiveness of cached content.

[0198] The above embodiments provide a complete cache lifecycle management mechanism to maintain the efficiency and effectiveness of the cache. Specifically, through periodic hot decay and resource reclamation, "cold" entries that are no longer frequently accessed are automatically eliminated, thereby freeing up valuable cache space for new hot key entries. This, combined with the intelligent learning mechanism, forms a dynamic and adaptive cache management closed loop, ensuring that the cached content always matches the current data access pattern and avoiding the waste of storage resources.

[0199] In some embodiments, the hash table entries in the distributed storage nodes employ a highly optimized data structure designed to make full use of the limited SRAM storage bandwidth to obtain the maximum query information while minimizing the cost of a single memory access.

[0200] The bit width of a single SRAM storage entry is configured to accommodate exactly two side-by-side hash table entries. Each hash table entry contains three functionally defined and fixed-length fields whose total length precisely matches the SRAM bit width:

[0201] Iteration control field: Occupies 1 byte and is used to store control information that guides the search engine on how to perform the next round of iterative search after a match fails;

[0202] Digest key field: Occupies 6 bytes and is used to store a fixed-length digest obtained from the wide key compression, which serves as the direct comparison object for the first-level matching;

[0203] Wide table address index field: Occupies 3 bytes and is used to store a pointer to the logical address of a wide table entry. After a successful digest match, this pointer provides the addressing basis for the search engine to subsequently obtain complete wide key and wide table data.

[0204] The three fields are physically adjacent and arranged in sequence to form a complete hash table entry. The digest key field is used for fast matching, the wide table address index field is used to locate the final data, and the iteration control field is used to manage the query process. The three work together to achieve an efficient and accurate two-level distributed table lookup mechanism.

[0205] The above embodiments optimize the data structure design of hash table entries, greatly improving storage and access efficiency. Specifically, by precisely packaging two entries within a single SRAM bit width, the following is achieved: 1) High storage density: fully utilizing the data obtained in each memory access, reducing the number of accesses. 2) Complete functionality: integrating all the information required for the three major functions of matching (digest key), addressing (wide table address index), and control (iteration control) within a limited bit width, enabling a single memory access to obtain all the information guiding all subsequent operations, reducing query latency.

[0206] In the above embodiments, the SRAM / NOC has a 20-bit width, balancing storage efficiency, network bandwidth, and chip area; a 32-bit wide key length, covering typical network identifier combinations; a 4-bit hash output; CRC32, balancing speed and collision rate; a 10-bit hash table entry (1-bit control + 6-bit digest + 3-bit index), adapting to a 20-bit width; and a 3-bit address index, supporting 16 million entries to meet the needs of large-scale networks.

[0207] In some embodiments, the wide table entries in the distributed storage node adopt a split storage data structure. This structure is designed to solve the problem that the wide key and wide table data bit width is too large and cannot be stored in a single SRAM entry, and to provide a data foundation for the final full bit width verification of the lookup engine.

[0208] The wide table entries in the distributed storage nodes employ a split-storage data structure. The logical storage unit of a single wide table entry consists of two physically contiguous or associated SRAM entries, which are used to independently store all data fragments of the wide key and wide table data, respectively.

[0209] First entry: Dedicated to storing all data fragments that make up a complete wide key;

[0210] Second item: Specifically used to store the complete wide table data fragments corresponding to the wide key;

[0211] like Figure 2 As shown, the logical address pointed to by the wide table address index field is the starting address of the first entry. The lookup engine can sequentially access the wide key data shard (corresponding to request key 0A (KEY0A)) and the wide table data shard (corresponding to request key 1A (KEY1A) etc.) stored in contiguous space through this address, thus providing a basis for parallel data acquisition and reorganization verification.

[0212] This design, which separates the wide key and wide table data and stores them in parallel in a contiguous space, fully utilizes the parallel access characteristics of the distributed storage architecture, enabling the Key shard and Result shard to be read independently and efficiently. On the other hand, it provides the necessary data support for the lookup engine to perform full-width accurate comparison of the wide key in the final verification stage, which is the core foundation for ensuring the accuracy of the entire two-level lookup mechanism.

[0213] In wide table design, a complete wide table entry typically contains a complete wide key. The core idea of ​​wide tables is to centrally store all dimension attributes, metrics, and descriptive information related to a business entity in a single table, reducing table join operations during queries. Each wide table entry corresponds to an independent business entity (such as an order or a user), and the wide key, used to uniquely identify that entity, is one of its most crucial components. Therefore, in physical storage, a complete wide key, along with its corresponding other data (such as result shards), forms a complete wide table entry. The capacity of a storage entry is typically equal to the physical bit width of the SRAM. The bit width of the SRAM determines the total amount of data that can be accessed in a single read / write operation.

[0214] SRAM, as a type of random access memory, has a fixed data bus width. For example, in an SRAM with a width of 20 bytes (20B), each address corresponds to a storage unit that can store or retrieve 20 bytes of data at a time. This smallest storage unit that can be accessed in one address constitutes a "storage entry". In this embodiment, the hash table entry is designed to be 10B, so that a single 20B SRAM entry can pack two hash table entries together. This is to maximize the utilization of the physical bit width of the SRAM and improve storage density and access efficiency. When the size of a wide key (e.g., 32B) exceeds the capacity of a single SRAM storage entry (20B), it cannot be stored in a single entry. In this case, the standard solution is to perform fragmented storage, and the storage method is as follows:

[0215] Wide table entry structure: As mentioned above, a complete wide table entry requires two consecutive SRAM entries (40 bytes in total).

[0216] Key-value sharding: A 32-byte wide key will be split and stored in two entries.

[0217] First entry (20B): Stores the first 16B fragments of the wide key; the remaining 4B space may be used to store control information or for padding.

[0218] The second entry (20B): stores the last 16B fragments of the wide key, along with the 8B wide result fragments.

[0219] Address association: The 3-byte result index in the hash table entry points to the starting address of that wide table entry (i.e., the address of the first entry). The lookup engine uses this base address, combined with offsets (e.g., offset 0 accesses the key fragment, offset 1 accesses the result fragment), to concurrently request all data fragments, and finally reassembles and verifies them locally.

[0220] This fragmented storage strategy effectively solves the problem of storing wide keys in memory with limited bit width, and ensures query efficiency through address mapping and parallel access.

[0221] The above embodiments optimize the storage structure of wide table entries, efficiently supporting the storage and verification of wide data. Specifically, the adoption of a split storage design (key-value separation and contiguous storage) brings two major advantages: 1) Parallel access capability: Data shards of keys and values ​​can be read independently and in parallel, fully utilizing the parallelism of distributed storage and accelerating the data retrieval process. 2) Verification support: It provides a complete data foundation for the search engine to perform full-key comparison in the final stage, which is a key technical support for ensuring the accuracy of two-level query results. At the same time, the contiguous storage layout also simplifies address management and is conducive to access locality.

[0222] The following is combined Figure 2 This invention describes the complete Wide Hash query process (Wide Hash: a hash key or hash function, in table lookup operations, refers to the original data input into the hash function, used to generate a fixed-length digest or index to quickly locate the target address in memory. In this invention, the wide key is used as the original hash key, which is compressed to generate a digest key):

[0223] Assuming that both SRAM and NOC have a bit width of 20 bytes (160 bits), this is a balance between storage density and network transmission efficiency in chip design; the wide key is 32 bytes (256 bits), representing a typical high-dimensional network identifier (such as the combination of IPv6 address and MAC address); the hash function uses CRC32 (output 4 bytes), balancing calculation speed and collision rate.

[0224] 1. Example of Hash Phase:

[0225] Wide key splitting: The search engine splits the 32-byte wide key into two 16-byte data units (Unit1 corresponds to bytes 0-15, Unit2 corresponds to bytes 16-31), padding with zeros where the width is insufficient.

[0226] Iterative hash calculation:

[0227] First Unit Hash: Hash1 = CRC32(Unit1) → Generates a 4-byte digest

[0228] Subunit hash: Concatenate Hash1 and Unit2 into a 20-byte input (4B Hash1 + 16B Unit2), calculate Hash2 = CRC32(Hash1 ∥ Unit2) → finally generate an 8-byte digest key (LKP Digest 8B).

[0229] Digest transmission: A 4-byte digest key is sent via a 20-bit wide Key-NOC (the remaining bandwidth is used for the routing header), which significantly reduces the amount of data transmitted (originally a 32-byte wide key was required, but now only a 4-byte digest is transmitted).

[0230] 2. Hash table entry design:

[0231] Single-entry dual-table structure: A single SRAM entry (20B) stores two hash table entries (10B each), containing:

[0232] Iteration control information (1B): includes parameters such as hash seed and retry count;

[0233] Digest key field (6B): Stores a 4B digest key (the lower 6B are used for matching, and 2B are reserved for redundancy).

[0234] Wide table address index (3B): can address 2^24 wide table entries, satisfying the needs of large-scale table entries.

[0235] Design considerations:

[0236] 10B entries + double-row packing: maximizes the use of 20B SRAM bandwidth and improves storage density;

[0237] 6B digest field: Compatible with 4B digest and reserves space for expansion, supporting stronger hash functions;

[0238] 3B address index: balance index range with storage overhead.

[0239] 3. Wide table column design:

[0240] A single-width table entry occupies 40 bytes: it consists of two 20-byte SRAM entries.

[0241] First entry: Stores the first 16 bytes of a 32-byte wide key (the remaining 4 bytes are filled with control information);

[0242] Second entry: Stores the last 16B fragments of the 32B wide key + 8B wide table data (such as forwarding actions).

[0243] Address association: The 3B index in the hash table entry points to the address of the first entry, realizing the logical connection between the hash and the wide table.

[0244] 4. Examples of use cases for iterative control information:

[0245] Scenario: Initial hash match fails (due to digest key conflict).

[0246] Usage: Find the 1B iteration control information in the engine's failed parsing response:

[0247] If the lower 4 bits indicate that the number of retries has not exceeded the threshold, and the higher 4 bits indicate that the hash seed is not zero, then the original wide key is XORed with the hash seed and the digest is recalculated.

[0248] Based on the "node offset" in the control information, the new digest is routed to different storage nodes.

[0249] By dynamically changing the hash path, duplicate collisions are avoided, thus improving the query success rate.

[0250] 5. Table Phase Validation Process:

[0251] The search engine derives the request key (base address + offset) based on the 3B index and concurrently requests the wide table data segment via Key-NOC.

[0252] The returned wide-key fragments are reassembled and compared with the original 32B wide-key full bits:

[0253] If the data matches, the action in the wide table (such as forwarding) will be executed.

[0254] If there is a discrepancy, iterative control will be triggered, and the process will jump to the Hash phase to retry.

[0255] Through the above examples, this invention achieves efficient and reliable distributed table lookup under limited hardware resources by using bit-width matching design (20B SRAM / NOC), precise field definition (1B+6B+3B), and iterative control mechanism.

[0256] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

[0257] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A data query method based on a distributed lookup and cache framework, characterized in that, The method comprises the following steps: The lookup engine receives a wide key to be queried, the bit width of the wide key being greater than the bit width of the network on chip; The lookup engine performs iterative hash calculation on the wide key to generate a fixed-length digest key, and sends the digest key to the corresponding distributed storage node through the key-value network on chip for first-level matching query; The distributed storage node queries the table entry matching the digest key in the local hash table; if the matching is successful, a successful response containing an index pointing to the wide table logical address is returned to the lookup engine through the result network on chip; if the matching fails, a failure response and iteration control information are returned to the lookup engine, and the lookup engine updates the query parameters according to the iteration control information and reinitiates the matching query until the matching is successful or the maximum number of iterations is reached; The lookup engine initiates a wide table data request to one or more distributed storage nodes through the key-value network on chip based on the wide table logical address after receiving the successful response; The distributed storage node returns the wide table data segment corresponding to the wide table logical address, and the lookup engine recombines and verifies the received wide table data segment to complete the query.

2. The method of claim 1, wherein, The iterative hash calculation comprises: Based on the bit width of the network on chip, the wide key is sequentially split into one or more fixed-length data units, and the last data unit is zero-padded to align the bit width if the length is insufficient; The fixed-length data units are sequentially input into the hash function for chain calculation; wherein, The hash calculation of the first fixed-length data unit takes its own data as input; The hash calculation of each subsequent fixed-length data unit takes the combination of the hash calculation result of the previous data unit and the current data unit as input; The hash value output after the hash calculation of the last fixed-length data unit is determined as the final digest key used for first-level matching query.

3. The method of claim 1, wherein, Initiating a wide table data request comprises: The lookup engine derives a set of consecutive request keys for the wide table logical address according to the total amount of data segments of the wide table data; wherein each request key is calculated by adding a predetermined offset to the wide table logical address, and each offset corresponds to a data segment to be obtained; The lookup engine routes the set of request keys to one or more corresponding distributed storage nodes through the key-value network on chip to trigger parallel reading operations on multiple wide table data segments.

4. The method of claim 1, wherein, Recombination and verification comprises: The lookup engine receives the data segment returned through the result network on chip, and recombines the wide key data segment and the wide table data segment belonging to the same query request into complete wide keys and wide table data according to the sequence tags attached to the data segments; The lookup engine compares the recombined wide key with the original wide key to be queried in full bit width: If the recombined wide key is completely consistent with the original wide key to be queried, it is determined that the final matching is successful, and then the lookup engine performs the predetermined action associated with the recombined complete wide table data. If the recombined wide key does not match the original wide key to be queried, it is determined that the summary query matches the wrong table entry due to hash collision, i.e. false positive matching occurs; the search engine updates the query parameters according to the pre-defined iteration control strategy, and re-initiates the matching query until the verification succeeds or the maximum number of iterations is reached.

5. The method of claim 1, wherein, The cache query process is also included: Before initiating the distributed summary query, the search engine sends the summary key to a cache module; The cache module performs one of the following operations: If the summary key matches a locally stored hot key entry and the associated wide table data is cached, the wide table data is returned to the search engine; If the summary key matches a hot key entry but the associated wide table data is not cached, the associated wide table data is received and returned to the search engine after being cached; If the summary key does not match any hot key entry and a pre-set learning condition is met, a new entry is assigned to the summary key, a learning flag is sent to the search engine, and the summary key is forwarded to the key-value network-on-chip; the search engine forwards the wide table data returned by the distributed storage node to the cache module for storage according to the learning flag; If the summary key does not match any hot key entry and the pre-set learning condition is not met, the summary key is forwarded to the key-value network-on-chip.

6. The method of claim 5, wherein, The pre-set learning condition is met when the following three conditions are met: The real-time access frequency of the summary key exceeds a first pre-set threshold; The congestion level of the current network-on-chip is lower than a second pre-set threshold; The number of free storage entries in the cache module is higher than a third pre-set threshold.

7. The method of claim 5, wherein, The cache module also performs periodic cache entry aging management operations to automatically eliminate unpopular entries to release resources, specifically including: A global timer periodically triggers the aging management operation of all cache entries; In each aging period, the hotness counter value of each learned cache entry is decremented once; The hotness counter values of all cache entries are continuously checked, and if the hotness counter value of an entry is lower than a pre-set aging threshold after decay, it is determined that the entry is no longer active, and the association between the summary key and the wide table data in the entry is released, and the storage resources occupied by the entry are recovered, and the entry state is marked as idle and available.

8. The method of claim 1, wherein, The data structure of the hash table entry in the distributed storage node is: the hash table entry structure for storing the summary key is determined based on the memory bit width, each hash table entry includes an iteration control information field, a summary key field, and a wide table logical address index field, The logical storage unit of the wide table entry is composed of two SRAM storage entries: The first entry is used to store the wide key data segment; The second entry is used to store the wide table data segment; The address pointed to by the wide table logical address index field is the address of the first entry.

9. A chip, characterized by It includes: The chip comprises a lookup engine and a plurality of distributed storage nodes. The lookup engine is configured to receive a wide key to be queried, perform an iterative hash calculation on the wide key to generate a fixed-length digest key, and send the digest key to a corresponding distributed storage node via a key-value network on chip (NoC) for a first-level matching query. The distributed storage node is configured to query a table entry matching the digest key in a local hash table.

10. The chip of claim 9, wherein, If the matching is successful, the distributed storage node returns a success response containing an index pointing to a wide table logical address to the lookup engine via a result NoC. If the matching is unsuccessful, the distributed storage node returns a failure response and iteration control information to the lookup engine. The lookup engine updates the query parameters according to the iteration control information and reinitiates the matching query until the matching is successful or the maximum number of iterations is reached. The lookup engine is further configured to initiate a wide table data request to one or more distributed storage nodes via the key-value NoC based on the wide table logical address after receiving the success response. The distributed storage node is further configured to return a wide table data segment corresponding to the wide table logical address to the lookup engine for recombination and verification of the received wide table data segment to complete the query. The chip further comprises a cache module. The lookup engine is further configured to send the digest key to the cache module before initiating the distributed digest query. The cache module is configured to: If the digest key matches a locally stored hot key entry and the associated wide table data is cached, return the wide table data to the lookup engine. If the digest key matches a hot key entry but the associated wide table data is not cached, wait to receive the associated wide table data and return the wide table data to the lookup engine after caching. If the digest key does not match any hot key entry and a preset learning condition is met, allocate a new entry for the digest key, send a learning flag to the lookup engine, and forward the digest key to the key-value NoC. If the digest key does not match any hot key entry and the preset learning condition is not met, forward the digest key to the key-value NoC. The lookup engine is further configured to forward the wide table data returned by the distributed storage node to the cache module for storage according to the learning flag.

Images