A distributed table lookup method and network device

Abstract

This application provides a distributed table lookup method and network device. Through the collaboration of a caching module and a table entry storage, it achieves efficient distributed table lookup processing. The caching module uses a hotkey dictionary to cache high-frequency and valid target data, and combines this with a time-to-live (TTL) mechanism to accurately determine whether data is aging. This allows high-frequency, valid data to be directly and quickly output by the caching module, significantly reducing query latency. For uncached or aging data, NOC routing forwards the data to the table entry storage for querying, ensuring the integrity of the data retrieval. This hierarchical table lookup mechanism not only improves the access efficiency of high-frequency data through caching but also ensures the lookupability of low-frequency data through the table entry storage, effectively balancing lookup speed and system resource consumption, and significantly improving the overall performance and reliability of distributed table lookup.

Description

Technical Field

[0001] This application relates to the field of chip technology, and in particular to a distributed table lookup method and network device. Background Technology

[0002] With the widespread application of multi-core processors and heterogeneous computing architectures in AI chips, data center SoCs, and other scenarios, Network on-Chip (NoC) has become a key interconnect infrastructure for data interaction in VLSI. In actual operation, NoC traffic transmission exhibits two typical characteristics: First, there are multiple "hotspot paths" with traffic pointing to the same destination. These paths have high data interaction frequency and require priority caching to improve transmission efficiency. Second, there are "unexpected congestion" on non-hotspot paths caused by sudden traffic surges. If the caching priority of the corresponding data is not increased in time, repeated congestion will occur due to the data not being cached promptly, severely impacting the overall transmission performance of the NoC.

[0003] In existing technologies, solutions for NoC congestion and caching optimization mostly rely on manually predefined rules to prioritize data packets and combine them with batch estimation theoretical models to assess path status, predict congestion risk, and then dynamically adjust the congestion window. However, this type of solution has significant drawbacks: on the one hand, priority setting depends on manual intervention and cannot learn autonomously based on historical path access frequency to identify high-frequency hotspot paths, resulting in poor adaptability; on the other hand, data diversion relies on static threshold triggering, and when sudden traffic occurs, it is easy to trigger erroneous switching because the threshold cannot dynamically match traffic changes, leading to delayed congestion response and forming a vicious cycle of "detection lag → response delay → congestion worsening," which is difficult to meet the requirements of high-throughput, low-latency computing scenarios. Summary of the Invention

[0004] This application provides a distributed table lookup method and network device to reduce query latency and improve query efficiency.

[0005] In a first aspect, embodiments of this application provide a distributed table lookup method, the method being applied to a network device, the network device including a query module, a cache module, a NOC routing module, and a table entry storage, the method comprising:

[0006] When the caching module receives the lookup flit sent by the query module, it searches for the corresponding target data in the hotkey dictionary based on the digest retrieval parameters contained in the lookup flit.

[0007] If the target data exists and the target data's lifespan meets the non-aging condition, then the caching module outputs the target data to the query module.

[0008] If the summary retrieval parameters do not exist; or, if the target data exists and the lifetime meets the aging condition, then the caching module forwards the lookup chip to the table entry storage via the NOC route to query the target data.

[0009] Optionally, after the step of searching for the corresponding target data in the hotkey dictionary based on the summary retrieval parameters contained in the lookup table micro-fragment sent by the query module when the caching module obtains the lookup table micro-fragment, the method further includes:

[0010] If the summary retrieval parameter exists in the hotkey dictionary and the target data does not exist, a retry instruction is sent to the query module so that the query module generates a new lookup table micro-piece for the target data.

[0011] Optionally, the network device further includes a result processing module; the step of the caching module outputting the target data to the query module includes:

[0012] The caching module outputs the target data to the query module through the result processing module.

[0013] Optionally, it also includes:

[0014] If the table entry storage retrieves the target data based on the lookup microchip, it sends the target data, the congestion status of the target data, and the time to life of the target data to the result processing module.

[0015] The result processing module determines whether the target data contains a learning label;

[0016] If it exists, the result processing module sends the target data, the congestion status of the target data, and the time to life of the target data to the cache module;

[0017] The caching module determines whether the target data meets the caching conditions based on the congestion status and the lifespan of the target data. If the conditions are met, the target data is cached.

[0018] Optionally, the step of the caching module forwarding the lookup chip to the table entry storage via the NOC route if the summary retrieval parameter does not exist; or if the target data exists and the lifetime meets the aging condition, includes:

[0019] If the summary retrieval parameters do not exist, the caching module will forward the lookup micro-chip with learning tags to the table entry storage via the NOC route;

[0020] If the target data exists and the lifetime meets the aging condition, the cache module confirms whether the lookup micro-piece corresponding to the target data has a learning tag.

[0021] If the learning tag exists, the caching module forwards the lookup chip with the added learning tag to the table entry memory via the NOC route;

[0022] If the learning tag does not exist, the caching module forwards the lookup chip to the table entry memory via the NOC route.

[0023] Optionally, it also includes:

[0024] When the cache module receives the lookup table fragment sent by the query module, the cache module counts using the counter of the lookup table fragment to obtain the count value of the lookup table fragment;

[0025] If the count value of the lookup table micro-pie is less than the first statistical threshold, then each time the cache module obtains the lookup table micro-pie, the cache module increments the corresponding count value by one using the counter, and determines the basic learning probability of the lookup table micro-pie based on the count value.

[0026] If the count value of the lookup micro-pie is equal to the first statistical threshold, the count value adjustment algorithm for medium and high frequency data is invoked to calculate the adjusted count value of the lookup micro-pie, and the basic learning probability of the lookup micro-pie is determined based on the adjusted count value.

[0027] If the adjusted count value is equal to or greater than the second statistical threshold, then the basic learning probability of the lookup micro-pie takes the maximum value.

[0028] Optionally, the step of the caching module determining whether the target data meets the caching conditions based on the congestion status and the lifespan of the target data, and caching the target data if it does, includes:

[0029] The caching module determines to add a learning tag to the lookup table micro-pie based on the basic learning probability of the lookup table micro-pie.

[0030] For target data with the learning tags, the caching module confirms whether the target data meets the caching conditions. If it does, the target data is cached.

[0031] Optionally, the step of the caching module determining whether the target data meets the caching conditions based on the congestion status and the lifespan of the target data, and caching the target data if it does, includes:

[0032] If the congestion status indicates congestion, the cache module determines the first additional learning probability corresponding to the lookup micro-piece;

[0033] Based on the lifetime of the target data, the caching module determines the second additional learning probability corresponding to the lookup micro-piece;

[0034] The caching module determines to add a learning tag to the lookup micro-pie based on the basic learning probability, the first additional learning probability, and the second additional learning probability.

[0035] For target data with the learning tags, the caching module confirms whether the target data meets the caching conditions. If it does, the target data is cached.

[0036] Optionally, it also includes:

[0037] When the cache module receives the lookup slice sent by the query module, the cache module extends and updates the lifetime of the target data.

[0038] If the target data is not accessed within a predetermined period, the caching module decrements the lifetime of the target data.

[0039] If the lifetime of the target data is zero, the caching module deletes the target data.

[0040] Optionally, the expression for the count value adjustment algorithm for the medium- and high-frequency data is as follows:

[0041] Cnt'= Cnt+2^(Cfg_num*(Cnt- threshold1))

[0042] Wherein, Cnt' is the adjusted count value, Cfg_num is the growth factor, Cnt is the count value of the lookup micro-piece, and threshold1 is the first statistical threshold.

[0043] Secondly, embodiments of this application provide a network device that performs the method as described in any of the first aspects.

[0044] The technical solutions provided in the embodiments of this specification may include the following beneficial effects:

[0045] This specification provides a distributed table lookup method and network device that achieves efficient distributed table lookup through the collaboration of a caching module and a table entry storage. The caching module uses a hotkey dictionary to cache high-frequency and valid target data, and combines this with a time-to-live (TTL) mechanism to accurately determine whether data is aging. This allows high-frequency, valid data to be directly and quickly output from the caching module, significantly reducing query latency. For uncached or aging data, NOC routing forwards the data to the table entry storage for querying, ensuring the integrity of the data retrieval. This hierarchical table lookup mechanism improves the access efficiency of high-frequency data through caching while ensuring the availability of low-frequency data through the table entry storage, effectively balancing lookup speed and system resource consumption, and significantly improving the overall performance and reliability of distributed table lookup.

[0046] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0047] Figure 1 A schematic diagram of the architecture of a network device provided in an embodiment of the present invention;

[0048] Figure 2 This is a flowchart illustrating a distributed table lookup method provided in an embodiment of the present invention.

[0049] Figure 3 A flowchart illustrating another distributed table lookup method provided in an embodiment of the present invention;

[0050] Figure 4 A schematic diagram of the architecture of a network device provided in an embodiment of the present invention;

[0051] Figure 5 A flowchart illustrating another distributed table lookup method provided in an embodiment of the present invention;

[0052] Figure 6 A flowchart illustrating another distributed table lookup method provided in an embodiment of the present invention;

[0053] Figure 7 A flowchart illustrating another distributed table lookup method provided in an embodiment of the present invention;

[0054] Figure 8 A flowchart illustrating another distributed table lookup method provided in an embodiment of the present invention;

[0055] Figure 9 A flowchart illustrating a method for determining learning probability provided in an embodiment of the present invention;

[0056] Figure 10 A schematic diagram of the architecture of a network device provided in an embodiment of the present invention;

[0057] Figure 11 A schematic diagram of a congestion state provided in an embodiment of the present invention;

[0058] Figure 12 This is a schematic diagram of a sliding window counting mechanism provided in an embodiment of the present invention. Detailed Implementation

[0059] The exemplary embodiments will now be described in detail. When the description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification; they are merely exemplary embodiments of apparatuses and methods consistent with some aspects of this specification.

[0060] The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of this specification. The singular forms “a,” “described,” and “the” as used herein are also intended to include the plural forms unless the context clearly indicates otherwise.

[0061] It should be understood that the terms "first," "second," "third," etc., may be used in this specification to describe various information or structural modules for the purpose of more clearly describing the solution. These terms should not be construed as indicating or implying relative importance or implicitly specifying the number, order, or position of the indicated technical features. Therefore, a feature defined with "first," "second," "third," etc., may explicitly or implicitly include one or more of that feature. In the description of this specification, unless otherwise stated, "a plurality of" means two or more; "if" can be interpreted as "when," "when," or "in response to determination."

[0062] In this specification, unless otherwise expressly specified and limited, the term "connection" should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral part; it can be a direct connection or an indirect connection through an intermediate medium. Furthermore, the term "coupled connection" can be a direct electrical connection or an indirect electrical connection through an intermediate medium. The term "contact" can be direct contact or indirect contact through an intermediate medium.

[0063] In this specification, "and / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following associated objects are in an "or" relationship.

[0064] To solve the above technical problems, please provide a distributed data storage and table lookup mechanism. Optionally, Figure 1 This is a schematic diagram of the architecture of a network device provided in an embodiment of the present invention. See also: Figure 1 The network device 10 includes: a query module 11, a cache module 12, an NOC router 13, and an entry storage 14.

[0065] Among them, the query module 11 is used to receive query requests from the upper layer and complete the conversion between query commands and table lookup micro-slices.

[0066] The caching module 12 is used to cache valid data for high-frequency data paths. It dynamically updates the cached data by dynamically maintaining the learning probability and lifetime of each high-frequency data path. When there is a query requirement for cached data, i.e., a table flit lookup, the cached target data is returned to the query module 11.

[0067] NOC route 13 is used to forward the corresponding lookup chip to the table entry storage 14 for non-high-frequency data.

[0068] The table entry memory 14, based on the received lookup micro-chip, queries the corresponding non-high-frequency target data and feeds it back to the query module 11.

[0069] Based on the aforementioned network devices, the following provides a possible implementation of the distributed table lookup method, which is optional. Figure 2 This is a flowchart illustrating a distributed table lookup method provided in an embodiment of the present invention. See also... Figure 2 The method includes:

[0070] Step 200: When the cache module receives the lookup table micro-fragment sent by the query module, it searches for the corresponding target data in the hotkey dictionary based on the digest retrieval parameters (digest parameters) contained in the lookup table micro-fragment.

[0071] Optionally, the summary retrieval parameter is used to indicate whether the target data has been learned, i.e., whether it has been cached in the hotkey dictionary. This summary retrieval parameter uniquely identifies the corresponding data path.

[0072] Step 201: If the target data exists and the lifespan of the target data meets the non-aging condition, the cache module outputs the target data to the query module.

[0073] Optionally, each target data can maintain a Time to Live (TTL) value to indicate whether the target data is aging. This determines whether the target data's lifespan meets the non-aging or aging condition. For the target data described in step 201, i.e., it is cached in the cache module and meets the non-aging condition, it means that the target data is high-frequency and valid data.

[0074] Step 202: If the abstract retrieval parameters do not exist; or, if the target data exists and the lifespan meets the aging conditions, the cache module will forward the lookup chip to the table entry storage via NOC routing to retrieve the target data.

[0075] Optionally, in step 202, the summary retrieval parameters may not exist, meaning the data path is not maintained. Alternatively, the target data may exist but be outdated. In both cases, the target data needs to be retrieved again through the table entry storage, so the lookup chip will be forwarded to the table entry storage via NOC routing. Thus, high-frequency, valid data is provided by the caching module, while low-frequency data is provided by the table entry storage.

[0076] The distributed table lookup method provided in this invention achieves efficient distributed table lookup through the collaboration of a caching module and a table entry storage. The caching module uses a hotkey dictionary to cache high-frequency and valid target data, and combines this with a time-to-live (TTL) mechanism to accurately determine whether data is aging. This allows high-frequency, valid data to be directly and quickly output by the caching module, significantly reducing query latency. For uncached or aging data, NOC routing forwards the data to the table entry storage for querying, ensuring the integrity of the data retrieval. This hierarchical table lookup mechanism improves the access efficiency of high-frequency data through caching while ensuring the availability of low-frequency data through the table entry storage, effectively balancing lookup speed and system resource consumption, and significantly improving the overall performance and reliability of distributed table lookup.

[0077] Optionally, there are also some scenarios where the hotkey dictionary contains summary retrieval parameters, meaning the corresponding data path has been learned by the caching module, but the target data has not been received (i.e., the caching module has not stored the target data, and the table entry storage has not returned the target data). In such cases, a mechanism for re-querying is provided below. Specifically, in... Figure 2 On this basis, Figure 3 A flowchart illustrating another distributed table lookup method provided in an embodiment of the present invention is shown below. Figure 3 After step 200, the following is also included:

[0078] Step 203: If the summary retrieval parameters exist in the hotkey dictionary and the target data does not exist, a retry instruction (retry information) is sent to the query module so that the query module can generate a new lookup table micro-piece for the target data.

[0079] exist Figure 1 On this basis, Figure 4 This is a schematic diagram of the architecture of a network device provided in an embodiment of the present invention. See also: Figure 4 The network device 10 also includes a result processing module 15.

[0080] The result processing module 15 is used for distributing the target data. That is, whether the target data is returned by the cache module or the target data returned by the table entry storage, it is sent to the query module 11 via the target data.

[0081] Furthermore, target data with learning tags is sent to the caching module to complete the caching of the corresponding target data.

[0082] Below, we will explain the possible implementation methods of this result processing module. Specifically, in... Figure 2 On this basis, Figure 5 A flowchart illustrating another distributed table lookup method provided in an embodiment of the present invention is shown below. Figure 5 In step 201, the following is included:

[0083] Step 201-1: If the target data exists and the lifespan of the target data meets the non-aging condition, the caching module outputs the target data to the query module through the result processing module.

[0084] To better illustrate the various judgments involved in the above steps, the following provides an implementation method for process branching. Figure 6 A flowchart illustrating another distributed table lookup method provided in this embodiment of the invention is shown below. Figure 6 ,include:

[0085] Step 1: Search for the corresponding target data in the hotkey dictionary based on the summary retrieval parameters contained in the lookup table micro-image.

[0086] Step 2: Determine if the summary retrieval parameter exists in the hotkey dictionary.

[0087] If the condition exists, proceed to step 3; otherwise, proceed to step 5.

[0088] Step 3: Determine if the target data exists.

[0089] That is, whether the caching module caches the target data. If it exists, proceed to step 4; otherwise, proceed to step 7.

[0090] Step 4: Determine if the target data is outdated.

[0091] If the product is aged, proceed to step 5; if it is not aged, proceed to step 6.

[0092] Step 5: The cache module forwards the lookup chip to the table entry storage via NOC routing to retrieve the target data.

[0093] Step 6: The caching module outputs the target data to the query module through the result processing module.

[0094] Step 7: The caching module sends a retry instruction to the query module, so that the query module generates a new lookup table fragment for the target data.

[0095] Optionally, for the result processing module, the following provides possible implementation methods for its participation in target data distribution. Specifically, in Figure 2 On this basis, Figure 7 A flowchart illustrating another distributed table lookup method provided in an embodiment of the present invention is shown below. Figure 7 It also includes:

[0096] Step 204: Once the table entry storage retrieves the target data based on the lookup microchip, it sends the target data, the congestion status of the target data, and the lifetime of the target data to the result processing module.

[0097] Step 205: The result processing module determines whether the target data contains a learning label.

[0098] If the condition does not exist, proceed to step 206; if the condition does exist, proceed to step 207.

[0099] Step 206: The result processing module sends the target data to the query module.

[0100] Step 207: The result processing module sends the target data, the congestion status of the target data, and the time to life of the target data to the cache module; at the same time, the result processing module sends the target data to the query module.

[0101] Step 208: The caching module determines whether the target data meets the caching conditions based on the congestion status and lifespan of the target data. If it does, the target data is cached.

[0102] Optionally, to dynamically adjust the data cached by the cache module, one possible implementation is to use a learning tag approach. This involves acquiring data with learned tags and then determining whether that data needs to be stored in the cache module. Therefore, a mechanism for synchronizing learned tags between the cache module and the table entry storage is provided below. Specifically, in... Figure 2 On this basis, Figure 8 A flowchart illustrating another distributed table lookup method provided in an embodiment of the present invention is shown below. Figure 8 Step 202 includes:

[0103] Step 202-1: If the abstract retrieval parameters do not exist, the caching module will forward the lookup micro-chip with the learning tag to the table entry storage via NOC routing.

[0104] Step 202-2: If the target data exists and the lifespan meets the aging conditions, the cache module confirms whether the lookup micro-piece corresponding to the target data has a learning tag.

[0105] If the target data exists, it means that although the target data is currently cached in the cache module, it has aged. If necessary, the table entry storage should feed the target data back to the cache module to confirm whether the lifespan needs to be extended. Therefore, step 202-3 is executed. If the target data does not exist, step 202-4 is executed.

[0106] Step 202-3: The cache module forwards the lookup micro-pieces with added learning tags to the table entry storage via NOC routing.

[0107] Step 202-4: The cache module forwards the lookup micro-chip to the table entry storage via NOC routing.

[0108] Optionally, regarding how to add learning tags, the following is one possible implementation based on learning probability. Specifically, Figure 9 This is a flowchart illustrating a method for determining learning probability according to an embodiment of the present invention. (See attached diagram.) Figure 9 Step 202 includes:

[0109] Step 209: When the cache module receives the lookup micro-fragment sent by the query module, the cache module counts the lookup micro-fragment using its counter to obtain the count value.

[0110] Specifically, for each lookup micro-pie containing summary retrieval parameters, the caching module can maintain a counter and configure an exponential counter mechanism.

[0111] Step 210: If the count value of the lookup table micro-pie is less than the first statistical threshold, then each time the cache module obtains a lookup table micro-pie, the cache module increments the corresponding count value by one using a counter, and determines the basic learning probability of the lookup table micro-pie based on the count value.

[0112] Specifically, each time a lookup slice with the same summary retrieval parameters is encountered, the counter increments by one. This continues until the count reaches the threshold for exponential counting, i.e., the first statistical threshold.

[0113] Step 211: If the count value of the lookup micro-pie is equal to the first statistical threshold, call the count value adjustment algorithm for medium and high frequency data, calculate the adjusted count value of the lookup micro-pie, and determine the basic learning probability of the lookup micro-pie based on the adjusted count value.

[0114] When the count value equals the first statistical threshold, it means that exponential counting needs to be triggered. At this time, the count value of medium- and high-frequency data can be used to adjust the algorithm's subsequent count value calculation. The caching module then recognizes the data path represented by this summary retrieval parameter as a popular data path, which can also be understood as the target data being medium- and high-frequency data.

[0115] The expression for the count value adjustment algorithm for medium- and high-frequency data is as follows:

[0116] Cnt'= Cnt+2^(Cfg_num*(Cnt- threshold1))

[0117] Where Cnt' is the adjustment count value, Cfg_num is the growth factor, Cnt is the count value of the lookup table micro-piece, and threshold1 is the first statistical threshold. The growth factor characterizes the learning rate and can be customized. A larger value can be configured for fast learning, while a smaller value can be configured if a faster learning speed is not required.

[0118] Step 212: If the adjusted count value is equal to or greater than the second statistical threshold, then the base learning probability of the micro-pie in the lookup table is taken as the maximum value.

[0119] Specifically, when the adjusted count value is equal to or greater than the second statistical threshold, the learning probability may no longer increase.

[0120] The above calculation method facilitates the caching module's identification of popular and less popular data paths. The hotkey dictionary uses counter values ​​as a reference for caching configuration. For example, the learning probability corresponding to the counter value is as follows: counter value cnt=[0:5] corresponds to a learning probability of 10%; counter value cnt=(5:10] corresponds to a learning probability of 20%; counter value cnt=(10:15] corresponds to a learning probability of 30%. And so on. When the counter value reaches its maximum value, it indicates that the summary retrieval parameter has the highest learning probability, which means that the corresponding data path is very popular. The caching module can analyze all the counter values, determine the resource allocation pattern, and then cache the values ​​of popular paths.

[0121] In one possible implementation, the basic learning probability can be used directly to determine whether to add a learning label. The possible implementation methods are as follows:

[0122] The caching module determines which lookup micro-pieces to add learning tags to based on their basic learning probabilities.

[0123] For target data with learning labels, the caching module checks whether the target data meets the caching conditions. If it does, the target data is cached.

[0124] Optionally, the following provides a possible implementation of how the caching module caches target data for popular data paths based on the counter's count value and the basic learning probability. Specifically, the caching module can maintain a learning label attainment threshold (e.g., 50%), and then determine whether the target data meets the caching conditions by comparing the basic learning probability with the learning label attainment threshold.

[0125] Optionally, the following is an example table 1: Count value range - learning probability - whether to add learning tags:

[0126]

[0127] Based on the example in Table 1 above, the caching module can scan the hotkey dictionary according to the "caching evaluation cycle" (e.g., every 100 clock cycles). The core action is to "determine the corresponding learning probability based on each count value and determine whether it meets the standard", and only cache the target data of the "qualified" ones to the caching module.

[0128] In another possible implementation, to better ensure the timeliness of cached data in the caching module, the basic learning probability, congestion state, and lifetime can be used to determine whether to add learning tags. The corresponding possible implementations are as follows:

[0129] If the congestion status indicates congestion, the cache module determines the first additional learning probability corresponding to the lookup slice.

[0130] Based on the lifetime of the target data, the caching module determines the second additional learning probability corresponding to the lookup micro-piece.

[0131] The caching module determines which micro-chips to add learning tags to based on the basic learning probability, the first additional learning probability, and the second additional learning probability.

[0132] For target data with learning labels, the caching module checks whether the target data meets the caching conditions. If it does, the target data is cached.

[0133] Optionally, the following provides a possible implementation for the basic learning probability, the first additional learning probability, and the second additional learning probability.

[0134] The congestion state can be implemented based on congestion flags. For example, congestion flag = 0 indicates that the data path of the target data is not congested; congestion flag = 1 indicates that the data path of the target data is congested. See Table 2 for the correspondence between congestion states and the first additional learning probability:

[0135]

[0136] The core design of the second additional learning probability is to increase the learning probability for target data with high time-to-live (TTL) values ​​to improve the likelihood of caching; and to decrease the learning probability for target data with low TTL values ​​to reduce the likelihood of caching. See Table 3 for a diagram illustrating the correspondence between TTL values ​​and the second additional learning probability.

[0137]

[0138] Furthermore, regarding the scenario where "the caching module determines the lookup micro-pieces to be added with learning tags based on the basic learning probability, the first additional learning probability, and the second additional learning probability," the possible implementation methods are as follows:

[0139] Step 1: Obtain the values ​​of the three main parameters

[0140] Read the count values ​​of the current summary retrieval parameters from the hotkey dictionary and match them to obtain the basic learning probability P_base;

[0141] Read the congestion label from the congestion status and match it to obtain the first additional learning probability P_congest;

[0142] Read the TTL value from the table entry memory or cache module and match it to obtain the second additional learning probability P_ttl.

[0143] Step 2: Calculate the final learning probability, the expression of which is as follows:

[0144] P_final=max(0%,min(P_base+P_congest+P_ttl,100%))

[0145] Formula constraints: If the summation exceeds 100%, it is counted as 100% (to avoid excessive summation); if it is less than 0%, it is counted as 0% (to avoid negative probabilities).

[0146] Step 3: Learning the Tag Judgment Criteria

[0147] The default threshold for adding learning tags (i.e., qualifying for caching) is P_final ≥ 50%.

[0148] If a learning tag is added, the target data for that data path will be cached in the cache module.

[0149] If no learning tags are added, and no caching is performed, then the cache module resources will be used in an unnecessary manner.

[0150] Based on the above scheme of determining whether to add a learning label using the basic learning probability, the first additional learning probability, and the second additional learning probability, the following example is provided for illustration.

[0151] Example 1: Comparison of "congested" and "non-congested" paths with the same TTL value.

[0152] Scenario: A business query path (TTL value = 12, medium lifecycle) has a count value cnt = 18 (medium popularity) and is in the "no congestion" and "congestion" states respectively.

[0153] Target data 1 - No congestion (congestion label = 0):

[0154] P_base: cnt=18∈(15,20]→40%;

[0155] P_congest: 0 → +5%;

[0156] P_ttl: TTL=12∈(5,15]→+8%;

[0157] Final probability: ≥50% → Add learning marker.

[0158] Target data 2 - Congestion (Congestion label = 1):

[0159] P_base: 40% (unchanged);

[0160] P_congest: 1 → +15% (10% higher than no congestion);

[0161] P_ttl: +8% (unchanged);

[0162] Final probability: ≥50% → Add learning tags, and the probability is 10% higher than when there is no congestion, which fully meets the requirement of "increased congestion level → increased learning probability";

[0163] Example 2: Low base learning probability and congestion, achieved by adding learning probability.

[0164] Scenario: A data path of an edge device (TTL=8, medium lifecycle), count value cnt=12 (low to medium heat, P_base=30%), congestion label=1 (congestion);

[0165] calculate:

[0166] P_base=30%, P_congest=+15%, P_ttl=+8%;

[0167] Final learning probability: ≥50% → Add learning marker;

[0168] Key conclusions: If there is no congestion (P_congest=+5%), the final probability = 30%+5%+8%=43%<50% → no marking is added; under congested conditions, a higher additional probability is used to make originally non-compliant paths compliant, achieving the goal of "prioritizing caching when congested".

[0169] Example 3: With a high probability of basic learning and congestion, the probability of learning is further increased.

[0170] Scenario: A core routing path (TTL=20, long lifespan), count value cnt=35 (extremely high popularity, P_base=70%), congestion label=1 (congestion);

[0171] Alternatively, the expression can be evaluated as follows:

[0172] P_base=70%, P_congest=+15%, P_ttl=+12%;

[0173] Final learning probability: (≤100%) → Add learning marker;

[0174] It is evident that the learning probability of popular paths approaches 100% during congestion, ensuring that they receive cached resources first, reducing repeated forwarding to congested links, and indirectly alleviating congestion pressure.

[0175] For successfully learned data, i.e., data cached in the cache module, a mechanism can be provided to determine which high-value data should be retained long-term, while low-value data should be quickly evicted. Optionally, an aging mechanism based on lifespan can be provided below:

[0176] When the caching module receives the table lookup fragment sent by the query module, the caching module extends and updates the lifetime of the target data.

[0177] If the target data is not accessed within a predetermined period, the caching module will decrease the lifetime of the target data.

[0178] If the lifetime of the target data is zero, the caching module deletes the target data.

[0179] Specifically, the TTL (Time To Live) configured for all data packets along a data path is usually consistent. If a data packet has a different TTL, it will be updated to the TTL value of the later packet. For example, the expression for updating the TTL value to extend the lifespan of the target data is as follows:

[0180] TTL_NEW = A * Current_cnt + (1-A) * TTL_OLD

[0181] Where TTL_NEW is the updated Time-to-Live (TTL) value, TTL_OLD is the original TTL value, and A is the decay factor. A higher A value indicates a greater expected impact of current data on priority, while a lower A value indicates more historical data is retained. Current_cnt represents the count value corresponding to the query accesses of this data observed in the current window. The advantage of this method is that if the current count value is used directly, the TTL will fluctuate drastically due to sudden traffic bursts, leading to misjudgments by identifying short-lived bursts of traffic as popular data paths, thus configuring a high learning probability. As packets in the traffic continue to be accessed, the TTL value will gradually converge to a reasonable value. The value of A can be configured according to the actual situation. In scenarios with drastic traffic fluctuations, a larger A value can be selected, such as 0.5~0.8, for rapid response to changes, and vice versa.

[0182] Optionally, to provide a detailed explanation of each step in the above example, the following provides a possible implementation of a network device. Specifically, in Figure 4 On this basis, Figure 10 This is a schematic diagram of the architecture of a network device provided in an embodiment of the present invention. See also: Figure 10 The query module 11 includes: an instruction generator 110, an instruction cache module 111, a group key module 112, and a key processing module 113.

[0183] The caching module 12 is used to maintain the hotkey dictionary 120, learning probabilities, and table entry cache.

[0184] NOC route 13 uses digital differentiator 16 and sliding window counter 17 to statistically analyze and predict the congestion status of the data path, thereby updating the congestion status described in the example above.

[0185] Specifically, for the query module 11, its instruction generator 110 is used to generate table lookup instructions for business requirements. These table lookup instructions are used to indicate which type of data to query.

[0186] After receiving a lookup instruction from the instruction generator 110, the instruction cache module 111 sends the lookup instruction to the group key module 112 and temporarily stores the lookup instruction for subsequent module processing and scheduling. Additionally, upon receiving a retry instruction from the result processing module 15, it retrieves the corresponding lookup instruction from the cache and sends it to the group key module 112.

[0187] The group key module 112 is used to extract or generate a "basic identifier" pointing to the target data - that is, the original key, to ensure that the original key uniquely matches the target data corresponding to the table lookup command (e.g., if the command is "get the model parameters of user A", then generate the original key pointing to the parameter).

[0188] The key processing module 113 is used to receive the original key sent by the group key module 112, perform corresponding hash calculations based on the original key to form a lookup table micro-slice, and send the lookup table micro-slice to the cache module 12.

[0189] The caching module 12 maintains a hotkey dictionary 120. The hotkey dictionary 120 is used to maintain the summary retrieval parameters, the counter value corresponding to each summary retrieval parameter, the corresponding target data, the TTL value of the target data, the learning tag (present / absent), and the congestion status.

[0190] Each time the caching module 12 receives a lookup micro-chip, it searches the hotkey dictionary 120 based on the summary retrieval parameters it contains. If the target data corresponding to the summary retrieval parameters exists, it feeds back to the query module 11 through the result processing module 15. If it does not exist, it determines whether to add a learning tag based on its learning probability, and then forwards the lookup micro-chip to the table entry storage 14 via the NOC router 13 to retrieve the target data.

[0191] Then, the caching module 12 determines the learning probability corresponding to each lookup micro-slice through the above example, confirms whether the target data corresponding to it should be learned, and then adds a learning label.

[0192] The table entry cache of the caching module 12 is used to store and return maintenance information for the hotkey dictionary 120, and at the same time, combined with the above-mentioned aging mechanism, deletes the aging data.

[0193] For NOC route 13, it is used to forward lookup table slice value entries to the memory. Simultaneously, a digital differentiator 16 is used to predict future congestion trends; and a sliding window counter 17 is used to identify path congestion status.

[0194] Specifically, the digital differentiator 16 is used to predict the rate of change of congestion and to adaptively optimize the critical path. Through the digital differentiator 16, not only can the instantaneous rate of change be calculated, but the acceleration of change can also be monitored through second-order differential calculations. Therefore, Figure 11 A congestion state diagram provided for an embodiment of the present invention, see [link / reference]. Figure 11The digital differentiator 16 can use the number of packets traversed on NOC route 13 in the current time slice (current queue depth) and the historical number of packets to make predictions (predicting subsequent queue depths), and use this information to pre-allocate the processing of subsequent traffic. For example... Figure 11 If the predicted value is greater than the preset maximum value, the predicted congestion status is confirmed as severe congestion; if it is less than the preset maximum value but greater than the preset normal value, the predicted congestion status is confirmed as moderate congestion; if it is less than or equal to the preset normal value, the predicted congestion status is confirmed as mild congestion.

[0195] The algorithm of digital differentiator 16 can be understood as a change in acceleration. If the packet statistics of traffic on NOC route 13 show almost no change in quantity within the same time interval, it can be understood that its acceleration is very stable.

[0196] a(t) = [r(t) – r(t - 1)] / △t

[0197] Where a(t) represents the rate of change, r(t) represents the number of packets in the current time slice, r(t-1) represents the number of packets in the previous time slice, and Δt represents the time slice length, the changing trend of a(t) can be observed in this way. If the number of packets in a certain time block suddenly increases, it can be quickly detected, thereby increasing the learning probability of this packet and caching the target data of the packet to the cache module 12 to alleviate the pressure on NOC route 13. At the same time, if there is no sudden traffic, the subsequent congestion status of NOC route 13 can also be predicted based on the changing pattern of a(t), and the congestion status can be reported to the CPU, so that the CPU can plan the subsequent traffic allocation method. The formula for predicting future NOC route 13 traffic information is briefly described as follows:

[0198] x(t+c) = x(t) + a(t) * c

[0199] x(t+c) represents the number of packets in the corresponding time block of the NOC at time c in the future, x(t) represents the number of packets in the current time block, and a(t) represents the current rate of change.

[0200] The digital differentiator 16 can be deployed on the NOC route 13 to detect potential congestion on the NOC route 13 at an early stage, thereby affecting the traffic allocation strategy and causing traffic to be sent to the NOC route 13 with mild or moderate congestion, instead of waiting to be sent on the heavily congested NOC route 13.

[0201] Specifically, the sliding window counter 17 is used to count the traffic density of data paths in real time, identify the congestion status of each data path, and provide "real-time congestion evidence" for the NOC route 13 and the caching module 12.

[0202] Optionally, the sliding window counter 17 can perform sliding window counting for NOC data traffic passing through NOC route 13. By recording the number of lookup fragments corresponding to the same packet passing through NOC route 13 within a fixed time slice, the number of lookup fragments in these fixed windows is statistically counted. To avoid false congestion reports caused by sudden traffic spikes within a short period, the concept of a minimum congestion period can be introduced. When the number of lookup fragments within a window triggers the congestion reporting logic, the number of lookup fragments in consecutive windows of that period needs to be counted to see if congestion still exists. If congestion is no longer an issue, the reported information is aged out to avoid false alarms. The congestion information generated here is reported to the CPU, including: packet ID, reporting reason, timestamp, and actual number of lookup fragments. The CPU adjusts the traffic transmission rate.

[0203] Specifically, Figure 12 A schematic diagram of a sliding window counting mechanism provided in an embodiment of the present invention is shown below. Figure 12 Each black numbered square represents a time unit (such as 1 second or 100 milliseconds), and multiple consecutive time units form a "time window" (i.e., the time range for counting).

[0204] For example, the time window corresponding to time t1 is time unit 1-time unit 5, and the time window corresponding to time t2 is time unit 2-time unit 6.

[0205] As time progresses, the time window slides to the right along the time axis ("sliding direction →"), sliding one time unit at a time.

[0206] The initial window is "1-5", then it changes to "2-6" after sliding, and so on.

[0207] The core of sliding is to continuously cover the latest time unit, ensuring that the count always reflects "the request / traffic situation within the most recent N time units".

[0208] Within each time window, the number of "initiations" (such as the number of requests and data packets) will be counted. When the number reaches a preset threshold, a threshold report will be triggered. If the number of initiations in the window meets the standard (as shown in the window where "Unit 2-6" is located), a "threshold report" (upward arrow) will be triggered for alarm or policy adjustment.

[0209] Optionally, this threshold reporting can trigger an update of the congestion status for the corresponding lookup slice, such as updating the congestion flag from 0 to 1, so that the learning probability can be updated based on the congestion flag in the example above.

[0210] Optional, see Figure 10The sliding window counter 17 can be deployed on the NOC router 13, which is the core hub for packet transmission within the chip, responsible for routing data from source to destination. Monitoring traffic on these nodes can accurately capture local congestion, quickly detect congestion, and trigger timely response mechanisms.

[0211] NOC routing's sliding window congestion reporting can also generate broadcasts. Broadcasting is a communication mechanism used to send messages to multiple nodes or the entire network simultaneously. The relationship between them is mainly reflected in the congestion response phase: threshold reporting triggers broadcast operations to quickly propagate congestion information and coordinate a global response. In NOC, broadcast messages are sent to all nodes or a specific set of nodes (such as all ingress ports or routing nodes). For example, if multiple congestion signals occur consecutively, NOC routing might broadcast a message to slow down traffic to all ingress ports, requesting them to immediately reduce their transmission rate to prevent congestion from spreading.

[0212] Optionally, besides using congestion marking to directly influence the learning probability of target data, a counter corresponding to the congestion marking can be maintained for each target data. Each time NOC route 13 returns target data with a congestion marking, the corresponding counter in cache module 12 is incremented by 1, indicating an increase in congestion level and a higher learning probability. If the corresponding target data is successfully learned by the cache module, the lookup slice corresponding to that flow does not need to be sent to the table entry storage 14; instead, the cache module 12 directly returns the target data, reducing the pressure on NOC route 13. Simultaneously, if the congestion count of the counter does not increase within a certain period, it can be interpreted as a decrease in the popularity of the flow. At this time, a decay timer is started, and after a specific time is reached, the congestion marking count is decremented by 1, preventing less popular flows from occupying the learning resources of the cache module.

[0213] Optionally, this application also provides a network device that can be based on the above examples. Figure 1 , Figure 4 as well as Figure 10 Implement any of the architectures shown and execute the corresponding functions of the example to achieve the corresponding technical effect.

[0214] The network device embodiments shown in this specification can be applied to computer devices, such as servers or terminal devices. The device embodiments can be implemented through software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by the processor in which it is located reading the corresponding computer program instructions from non-volatile memory into memory and executing them. From a hardware perspective, this is a hardware structure diagram of a computer device where the file processing device of the embodiments of this specification is located. In addition to the processor, memory, network interface, and non-volatile memory, the server or electronic device where the network device is located in the embodiments may also include other hardware depending on the actual function of the computer device, which will not be described in detail here.

[0215] The implementation process of the functions and roles of each module in the above network device is detailed in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0216] For network device embodiments, since they basically correspond to method embodiments, relevant details can be found in the descriptions of the method embodiments. The network device embodiments described above are merely illustrative; the modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, meaning they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the solution described in this specification, depending on actual needs. Those skilled in the art can understand and implement this without any inventive effort.

[0217] The foregoing has described exemplary embodiments of this specification. It should be understood that in some cases, the modules described in this specification may be divided in a manner different from that in the embodiments, and the described actions or steps may be performed in a different order than that in the embodiments, while still achieving the desired result. Furthermore, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0218] Other embodiments of this specification will readily occur to those skilled in the art upon consideration of the specification and practice of the invention claimed herein. This specification is intended to cover any variations, uses, or adaptations that follow the general principles of this specification and include common knowledge or customary techniques in the art not illustrated herein.

[0219] The above are merely preferred embodiments of this specification and are not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification shall be included within the scope of protection of this specification.

Claims

1. A distributed table lookup method, characterized by, The method is applied to a network device, and the network device comprises a query module, a cache module, a NOC route and a table entry storage. When the cache module obtains the table lookup flit sent by the query module, the cache module searches for corresponding target data in a hot key dictionary according to the summary search parameter contained in the table lookup flit. If the target data exists and the survival time of the target data meets the unaging condition, the cache module outputs the target data to the query module. If the summary search parameter does not exist, the cache module forwards the table lookup flit with a learning mark added to the table entry storage through the NOC route. If the target data exists and the survival time meets the aging condition, the cache module determines whether the table lookup flit corresponding to the target data has a learning mark. If the learning mark exists, the cache module forwards the table lookup flit with the learning mark added to the table entry storage through the NOC route. If the learning mark does not exist, the cache module forwards the table lookup flit to the table entry storage through the NOC route.

2. The method of claim 1, wherein, After the step of searching for corresponding target data in a hot key dictionary according to the summary search parameter contained in the table lookup flit when the cache module obtains the table lookup flit sent by the query module, the method further comprises the following steps: If the summary search parameter exists in the hot key dictionary and the target data does not exist, a retry instruction is sent to the query module, so that the query module generates a new table lookup flit for the target data.

3. The method of claim 1, wherein, The network device further comprises a result processing module; the step of outputting the target data to the query module by the cache module comprises the following steps: The cache module outputs the target data to the query module through the result processing module.

4. The method of claim 3, wherein, Further comprising: If the target data is queried by the table entry storage according to the table lookup flit, the target data, the congestion state of the target data and the survival time of the target data are sent to the result processing module; The result processing module determines whether the target data has a learning mark; If the learning mark exists, the result processing module sends the target data, the congestion state of the target data and the survival time of the target data to the cache module; The cache module determines whether the target data meets the cache condition according to the congestion state of the target data and the survival time of the target data, and if the target data meets the cache condition, the target data is cached.

5. The method of claim 4, wherein, Further comprising: When the cache module obtains the table lookup flit sent by the query module, the cache module counts the counter of the table lookup flit to obtain the count value of the table lookup flit; If the count value of the table lookup flit is less than a first statistical threshold, each time the cache module obtains the table lookup flit, the cache module adds one to the corresponding count value through the counter, and determines the basic learning probability of the table lookup flit according to the count value. If the count value of the lookup microchip is equal to a first statistical threshold, a count value adjustment algorithm of medium-high frequency data is invoked, an adjusted count value of the lookup microchip is calculated, and a basic learning probability of the lookup microchip is determined according to the adjusted count value; If the adjusted count value is equal to or greater than a second statistical threshold, the basic learning probability of the lookup microchip takes a maximum value.

6. The method of claim 5, wherein, The cache module determines whether the target data satisfies a cache condition according to the congestion state of the target data and the survival time of the target data, and if yes, caches the target data. The cache module determines to add a learning mark for the lookup microchip according to the basic learning probability of the lookup microchip. For the target data with the learning mark, the cache module determines whether the target data satisfies a cache condition, and if yes, caches the target data.

7. The method of claim 5, wherein, The cache module determines whether the target data satisfies a cache condition according to the congestion state of the target data and the survival time of the target data, and if yes, caches the target data. If the congestion state indicates congestion, the cache module determines a first additional learning probability corresponding to the lookup microchip; According to the survival time of the target data, the cache module determines a second additional learning probability corresponding to the lookup microchip; The cache module determines to add a learning mark for the lookup microchip according to the basic learning probability, the first additional learning probability and the second additional learning probability. For the target data with the learning mark, the cache module determines whether the target data satisfies a cache condition, and if yes, caches the target data.

8. The method of claim 1, wherein, Further comprising: When the cache module obtains the lookup microchip sent by the query module, the cache module prolongs and updates the survival time of the target data; If the target data is not accessed within a predetermined period, the cache module decrements the survival time of the target data; If the survival time of the target data is zero, the cache module deletes the target data.

9. A network device, comprising: The network device performs the method of any one of claims 1 to 8.

Images