An off-chip storage structure setting method of an accurate matching flow table, a chip and a network card

Abstract

This invention provides a method, chip, and network interface card for accurately matching flow tables in off-chip storage structure configuration, relating to the field of off-chip storage technology. The method includes: obtaining flow table size parameters; calculating the average load λ within each storage row of the off-chip hash table; calculating the probability P(k) of exactly k entries falling within a single storage row; selecting the smallest k value that makes the cumulative probability reach a preset coverage threshold Pth, based on the calculated probability values ​​P(k), as the fixed slot number η of the base area of ​​the off-chip hash table; dividing the off-chip storage space into a base area and a linked list area; when a flow table entry is mapped to a target storage row through hash operation, and all η fixed slots in the base area of ​​the target storage row are occupied, allocating a linked list node from the linked list area to store the overflow entry, and linking the linked list node to the overflow linked list of the target storage row; this invention significantly improves the utilization and cost-effectiveness of off-chip storage.

Description

Technical Field

[0001] This invention relates to the field of off-chip storage technology, and in particular to an off-chip storage structure configuration method, chip, and network interface card for accurately matching flow tables. Background Technology

[0002] The precise matching flow table is a key component in network chips for achieving line-rate packet forwarding. It is used to quickly retrieve the corresponding forwarding strategy based on the lookup key extracted from the packet header. Limited by the capacity of the chip's on-chip static random access memory (SRAM), large-scale flow tables typically store the main body in off-chip dynamic random access memory (DRAM), with only a limited-capacity cache on-chip to buffer hot entries. The design of the off-chip storage structure directly determines the overall capacity, access latency, and storage overhead of the flow table. Existing off-chip storage often uses a fixed-way array-associative structure, where each row pre-allocates a fixed number of slots to store entries that have hash collisions. However, to cover extreme collision situations, the fixed number of slots often needs to be set to a large value, resulting in many slots remaining idle for extended periods, leading to low storage utilization and significant waste of area and cost. If a smaller number of slots is used to save storage, many entries cannot be stored when hash collisions are severe, leading to lookup failures or frequent entry replacements, seriously affecting forwarding correctness. Some solutions use pure linked lists to handle collisions, which offer flexible storage, but the latency introduced by linked list traversal is uncertain and cannot meet the line-rate lookup requirements of network chips. Furthermore, when the overall off-chip storage space is insufficient, the existing solution lacks an effective elastic fallback mechanism, and overflow entries are directly discarded or cause flow table oscillations, resulting in poor system robustness. Summary of the Invention

[0003] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows:

[0004] According to the off-chip storage structure setting method for precise matching flow tables provided in this application, the method includes the following steps:

[0005] R100, obtain the flow table size parameters; the flow table size parameters include: the total number of flow table entries M to be stored, and the number of storage rows N corresponding to the preset index bit width of the off-chip hash table;

[0006] R200, based on the total number of flow table entries M and the number of storage rows N, calculate the average load λ=M / N within each storage row of the off-chip hash table;

[0007] R300, based on λ, using the probability distribution model, calculate the probability value P(k) for different non-negative integers k, respectively, that exactly k entries fall within a single storage line;

[0008] R400, based on the calculated probability values ​​P(k), select the minimum k value that makes the cumulative probability reach the preset coverage threshold Pth, and use it as the fixed number of slots η in the base area of ​​the off-chip hash table.

[0009] R500 divides the off-chip storage space into a base area and a linked list area. The base area contains N storage rows, each row has η fixed slots, which are used to store the corresponding hash map flow table entries. The linked list area is used to dynamically store overflow entries that exceed the number of fixed slots in the base area.

[0010] R600: When a first-order table entry is mapped to a target storage row via hash operation, and all η fixed slots in the base area of ​​the target storage row are occupied, a linked list node is allocated from the linked list area to store the overflow entry, and the linked list node is linked to the overflow linked list of the target storage row; wherein, the off-chip hash table works in conjunction with the on-chip cache, and the on-chip cache caches a subset of hot entries in the off-chip hash table.

[0011] The present invention has at least the following beneficial effects:

[0012] The off-chip storage structure configuration method for precisely matching flow tables in this invention calculates the average load based on flow table size parameters and uses a probability distribution model to calculate the probability that a single row falls exactly into k entries for different k values. Then, the minimum k value that makes the cumulative probability reach a preset threshold is selected as the fixed number of slots in the base area. This transforms the determination of the number of slots in the base area from an empirical decision to a precise mathematical model-driven approach, minimizing base area storage overhead while ensuring high coverage, significantly improving the utilization and cost-effectiveness of off-chip storage. Furthermore, by dividing the off-chip storage space into a base area and a linked list area, the base area uses fixed slots to ensure deterministic low latency for main path lookups, while the linked list area is dynamically allocated on demand to accommodate long-tail overflow entries. This achieves a significant reduction in the number of slots in the base area with a smaller increase in linked list space, thus optimizing the balance between storage overhead and lookup performance. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 A flowchart illustrating the off-chip storage structure setting method for precisely matching flow tables provided in this embodiment of the invention. Detailed Implementation

[0015] 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 some embodiments of the present invention, and not all 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.

[0016] It should be noted that, based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Furthermore, this device and / or practice the method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0017] Example 1:

[0018] The following will refer to Figure 1 The flowchart shown illustrates a method for setting up the off-chip storage structure of a precisely matching flow table, introducing such a method.

[0019] The method for setting up the off-chip storage structure for precisely matching flow tables may include the following steps:

[0020] R100, obtain the flow table size parameters; the flow table size parameters include: the total number of flow table entries M to be stored, and the number of storage rows N corresponding to the preset index bit width of the off-chip hash table.

[0021] This step determines the design input parameters for the off-chip hash table. The flow table size parameters include the total number of flow table entries M to be stored and the number of storage rows N corresponding to the preset index bit width of the off-chip hash table. M is determined by the target application scenario of the network chip, with typical values ​​being tens of millions of entries, such as 67,108,864. N is determined by the index bit width of the off-chip hash table; if the index bit width is 23 bits, then the number of storage rows N=2. 23 =8,388,608 lines. Parameters M and N can be read from the configuration file or registers during chip initialization, or they can be fixed as constants in the hardware parameters during the design phase.

[0022] This step defines the design inputs of the off-chip storage structure as two quantifiable macroscopic parameters, which allows the subsequent determination of the number of slots and capacity planning to be based on precise mathematical foundations, avoiding storage waste or overflow risks caused by setting parameters based on experience.

[0023] R200, based on the total number of flow table entries M and the number of storage rows N, calculates the average load λ=M / N within each storage row of the off-chip hash table.

[0024] Based on M and N obtained in step R100, the average row load λ = M / N within each storage row of the off-chip hash table is calculated. λ represents the average number of flow table entries carried per storage row under an ideal uniform hash distribution. For example, if M = 67,108,864 and N = 8,388,608, then λ = 8, meaning there are approximately 8 entries per row on average. This value serves as the core parameter for subsequent probability calculations.

[0025] This step transforms the macroscopic flow table size and number of storage rows into the average load of a single storage row through a simple division operation, reducing the global storage planning problem to a single-row probability distribution analysis problem, which greatly simplifies the complexity of subsequent parameter selection.

[0026] R300, based on λ, uses a probability distribution model to calculate the probability P(k) of exactly k entries falling within a single storage line for different non-negative integers k.

[0027] Furthermore, the probability distribution model is a binomial distribution model or a Poisson distribution model; when the values ​​of M and N cause the average load λ to not exceed a preset threshold, the probability value P(k) is calculated using a Poisson distribution model:

[0028] ;

[0029] Where e is a natural constant and k is a non-negative integer.

[0030] In this embodiment, under the assumption of an ideal hash function, each flow table entry is independently and uniformly mapped to one of N storage rows, and the number of entries falling into a single storage row follows a binomial distribution. When N is large and λ is moderate, the binomial distribution can be approximated as a Poisson distribution to reduce computational complexity.

[0031] Specifically, when using the Poisson distribution model, the formula for calculating the probability value P(k) is: Where e is a natural constant and k is a non-negative integer. Hardware or software configuration tools can calculate P(k) sequentially for k=0,1,2,... until the value of P(k) is small enough to be ignored. Taking λ=8 as an example, the calculated values ​​are P(0)≈0.0335%, P(1)≈0.2684%, P(8)≈13.96%, P(12)≈4.81%, etc.

[0032] This step quantifies the random phenomenon of hash collisions into precise probability values ​​through a probability distribution model, enabling designers to pre-assess the overflow risk under different slot lengths, providing a scientific quantitative basis for subsequent slot length selection. The Poisson distribution approximation avoids the computational complexity of large factorials involved in the binomial distribution, is easy to implement in engineering, and the approximation error is negligible when N is sufficiently large.

[0033] R400, based on the calculated probability values ​​P(k), selects the minimum k value that makes the cumulative probability reach the preset coverage threshold Pth, as the fixed slot number η of the base area of ​​the off-chip hash table.

[0034] Based on the probability distribution in step R300, this step determines the number of base slots η according to the preset coverage threshold Pth. The cumulative probability is defined as the sum of each P(k) from k to η, representing the probability that the number of entries in a storage row does not exceed η. The value of Pth ranges from 90% to 99%, with a typical value of 93% to 95%.

[0035] For example: λ=8, Pth=93.62%. Looking up the cumulative probability table, the cumulative probability is 93.62% when k=12, which just reaches the threshold, so η=12. At this point, approximately 93.62% of the storage rows have no more than 12 entries, and only about 6.38% of the storage rows require overflow storage in the linked list area.

[0036] This step quantifies the trade-off between storage efficiency and overflow probability by using cumulative probability and coverage threshold. The smallest η value that satisfies the threshold is selected, minimizing the number of slots per row in the base area while ensuring that the vast majority of entries can be stored in fixed slots. This significantly reduces the storage overhead of the off-chip Key / Data table. Compared to fixed large-slot schemes, this method achieves a substantial reduction in storage area with a very low overflow probability.

[0037] Furthermore, the value of Pth ranges from 90% to 99%; the cumulative probability is the sum of the probability values ​​P(k) from k from 0 to the current value; when selecting a fixed number of slots η, the following conditions are met:

[0038] ;

[0039] Where η is the smallest non-negative integer that satisfies the above conditions.

[0040] In practice, P(k) can be accumulated starting from k=0. The k at which the first accumulated value is greater than or equal to Pth is η. If Pth=90%, η may be 10; if Pth=99%, then η=14. The higher Pth, the more fixed slots in the base region, resulting in greater storage overhead but a lower overflow probability; the lower Pth, the opposite is true. Designers can flexibly configure Pth according to the chip area and the tolerance for overflow without modifying the hardware structure.

[0041] This step provides a configurable coverage threshold parameter, Pth, which allows the same storage architecture to be adapted to different cost and performance requirements. The programmability of Pth gives system integrators the ability to fine-tune based on actual traffic characteristics and storage budgets without redesigning the hardware.

[0042] R500 divides the off-chip storage space into a base area and a linked list area. The base area contains N storage rows, each with η fixed slots, for storing the corresponding hash map flow table entries. The linked list area is used to dynamically store overflow entries that exceed the number of fixed slots in the base area.

[0043] In this embodiment, the base area contains N storage rows, each with η fixed slots. Each fixed slot stores the complete data of a flow table entry, including the key value, result data, and status flags. The base area is implemented using static random access or dynamic random access memory, directly indexed by row address and slot number, with a determined access latency.

[0044] The linked list area is used to dynamically store overflow entries that exceed the fixed number of slots in the base area. The linked list area consists of several linked list nodes, each storing one overflow entry and a pointer to its next node. The size of a node is comparable to the data size of a single slot in the base area. The linked list area and the base area can physically reside in different address segments of the same DDR memory.

[0045] Each row in the base area maintains a linked list head pointer, initially a null pointer. When a row overflows, a node is allocated from the linked list area and linked to the head of the linked list.

[0046] For example: η=12, each row in the base area has 12 fixed slots. The total capacity of the linked list area is determined based on the expected overflow E_overflow. If a row already has 12 entries filling the base area, when the 13th entry arrives, there is no space in the base area, so a node is allocated from the linked list area and inserted into the linked list.

[0047] This approach utilizes a two-tiered storage architecture consisting of a base area and a linked list area. Fixed slots ensure low latency and determinism for main path lookups, while the linked list area dynamically expands as needed to accommodate long tails of hash collisions. Only a small amount of linked list space is required to cover low-probability overflow scenarios, resulting in 30%-50% less storage space compared to a fully fixed-slot solution. The physical separation of the base area and the linked list area also allows the base area to use higher-performance memory types, optimizing access latency in common scenarios.

[0048] Furthermore, the capacity of the linked list area is determined through the following steps:

[0049] R510, based on P(k), calculate the expected number of storage rows E_overflow for more than η entries:

[0050] ;

[0051] R520, based on the expected value E_overflow, sets the linked list area to provide storage space for at least E_overflow linked list nodes, with each linked list node used to store an overflow entry and its next node pointer.

[0052] In this embodiment, the capacity of the linked list area is determined by the expected number of rows to overflow, E_overflow. Taking λ=8 and η=12 as an example, E_overflow≈535,000. The linked list area provides space for at least E_overflow nodes, with some margin considered for allocation granularity. Each node needs to store complete entry data and a pointer to the next node; the node size is slightly larger than a single slot in the base area. Total storage capacity of the linked list area = number of nodes × node size.

[0053] For example: E_overflow≈535,000, node size 256 bits (including 192 bits of data + 64 bits of pointer), the linked list area requires approximately 535K × 256 bits ≈ 16.7MB.

[0054] This step directly links the linked list area capacity to the expected number of overflow nodes, making the size of the overflow storage area scientifically controllable and avoiding waste due to excessive reservation or insufficient storage space due to insufficient space after overflow. Through probability expectation calculation, the planning of the linked list area capacity has a clear mathematical basis, and the design results are predictable and reproducible.

[0055] R600: When a first-order table entry is mapped to a target storage row via hash operation, and all η fixed slots in the base area of ​​the target storage row are occupied, a linked list node is allocated from the linked list area to store the overflow entry, and the linked list node is linked to the overflow linked list of the target storage row; wherein, the off-chip hash table works in conjunction with the on-chip cache, and the on-chip cache caches a subset of hot entries in the off-chip hash table.

[0056] In this embodiment, overflow processing is triggered when a first-order list entry is mapped to a target storage row via hash operation, and all η base area fixed slots of that row are occupied. The hardware controller allocates a linked list node from the free node queue of the linked list area, writes the complete data of the overflow entry to the node, and inserts the node at the head (or tail) of the overflow linked list of the target storage row. The allocation and linking operations of the linked list node are completed by the linked list management state machine, and the time required depends on the access latency of the linked list area, which is typically several DDR clock cycles.

[0057] For example: The target storage row already has 12 entries filling the base area slots. When the 13th entry arrives, the base area is full. The linked list controller retrieves a node from the free linked list queue, writes the entry data, sets the node pointer to the current linked list head (which was previously empty), and updates the row's linked list head pointer to the new node.

[0058] This step utilizes a dynamic linked list expansion mechanism to provide the off-chip hash table with elastic capacity beyond the fixed slots in the base area. This allows for the smooth absorption of localized overflows caused by hash collisions, avoiding the serious drawback of fixed-slot schemes that directly discard entries upon overflow. The on-demand allocation characteristic of the linked list ensures that overflow storage overhead is proportional to the actual degree of collision. When hash distribution is uniform, there is almost no additional overhead; when distribution is uneven, it automatically adapts, resulting in high overall storage utilization.

[0059] Furthermore, in step R600, when a first-order table entry LB is replaced from the on-chip cache and needs to be written back to off-chip storage, the method further includes the following:

[0060] R610: If the LB was originally stored in a fixed slot in the base area, then write it back to the original slot address.

[0061] R620: If the LB was originally stored in the linked list area, then the next node pointer stored in the original linked list node of the LB is used to traverse to the target node and then the write-back operation is performed.

[0062] In this embodiment, when an entry in the on-chip cache needs to be written back to off-chip storage due to replacement, its position in the off-chip base area or linked list area must be accurately located. If the entry was originally stored in a fixed slot in the base area, its off-chip address was determined during the initial allocation as "base area base address + row number × row slot offset + slot number × slot size", and the original address is directly used during the write-back. If it was originally stored in a node in the linked list area, the off-chip address field of the cache status table entry stores the starting address of the linked list node, and the hardware directly initiates a write operation to that address. If the position of the linked list node changes due to linked list reorganization, the off-chip address field in the cache needs to be updated.

[0063] For example: Entry A is located in slot 5 of row 100 in the off-chip base area. The off-chip address is fixed and known, so the replacement write-back address is directly the address of this slot. Entry B is located at node 0x1000 in the linked list area. The cache state table records the address at 0x1000. During replacement write-back, new data is written to 0x1000.

[0064] This step ensures the determinism and efficiency of write-back operations by differentiating between two write-back location methods: fixed mapping of the base area and direct addressing of the linked list area. Fixed mapping of the base area eliminates the need for additional storage and lookup of the write-back address for most entries, saving address field overhead; direct addressing of the linked list area utilizes the precise address pre-stored in the cache state table, avoiding the latency of traversing the linked list and ensuring write-back throughput.

[0065] Example 2:

[0066] The two-level storage structure of base area + linked list area described in Embodiment 1 above can cover most flow table entries. However, when all the fixed slots in the base area of ​​a storage row are occupied and the free nodes in the linked list area are exhausted, new entries will have nowhere to be stored. To address this boundary situation, this embodiment provides an on-chip escape storage area as a third-level fallback, composed of cascaded TCAM and SRAM, shared by all flow table groups; including the following steps:

[0067] The R700 has an on-chip escape storage area, which is composed of a content addressable memory and a random access memory cascaded together; the escape storage area is shared by all flow table groups within the chip.

[0068] In this embodiment, an escape storage area is provided on-chip, consisting of cascaded Content Addressable Memory (TCAM) and Random Access Memory (SRAM). The TCAM stores the flow table group identifier and complete lookup key, while the SRAM stores the corresponding action data. The escape area is shared by all flow table groups within the chip. When the fixed slots in the base area of ​​the off-chip hash table are full, and there are no available nodes in the linked list area of ​​the corresponding row, the overflow entry is transferred to the escape area. Writing to the escape area is automatically triggered by hardware, requiring no software intervention.

[0069] For example: If all 12 slots in the row base area of ​​a certain flow table group in the off-chip DDR are full, and the free nodes in the linked list area are exhausted, a new entry will arrive. The hardware will write the <flow table group ID, lookup key> of this entry to the TCAM, and the action data will be written to the cascaded SRAM.

[0070] This step provides a third level of elastic storage outside the on-chip cache through an on-chip escape area, avoiding service interruptions caused by discarding flow table entries when both the off-chip base area and linked list area are full. The escape area is shared by all flow table groups, covering extreme overflow spikes of multiple flow table groups with a relatively small total capacity, resulting in high storage resource utilization. The cascaded structure of TCAM+SRAM supports single-cycle key-value matching lookups, and entries matched in the escape area still achieve low latency similar to that of the on-chip cache.

[0071] R710: When the fixed slots in the base area of ​​the off-chip hash table are full and there are no available linked list nodes in the linked list area of ​​the corresponding storage row, the overflow entries are stored in the escape storage area.

[0072] Each escape entry contains three fields: a flow group identifier field (the bit width is determined by the number of flow groups, such as 8 bits), a lookup key field (the bit width is equal to the full key width K), and an action data field (the bit width is equal to the data entry bit width). During a lookup, the flow group ID to which the current packet belongs and the lookup key are concatenated as the TCAM matching input. Each TCAM entry can be configured to precisely match a specified bit; upon a match, the corresponding SRAM address is output, and the action data is read and returned.

[0073] For example: Querying the key value 0xABCD... in flow table group 3, the escape TCAM contains...<Group=3,Key=0xABCD...> When the TCAM match is successful, output SRAM address 0x00F and read the action data from SRAM.

[0074] This step leverages the parallel matching feature of TCAM to achieve single-cycle parallel lookup of escape entries for all flow table groups, maintaining a constant lookup latency regardless of the number of entries stored in the escape zone. The use of flow table group IDs in the matching process isolates the key-value spaces of different flow table groups, avoiding key-value conflicts between groups and ensuring lookup accuracy.

[0075] Furthermore, the storage format of each entry in the escape storage area includes:

[0076] The flow group identifier field indicates the flow group to which this entry belongs;

[0077] The lookup key field stores the complete lookup key value for this flow table entry;

[0078] The action data field is used to store the forwarding or processing policy corresponding to this flow table entry;

[0079] During the search, the current flow group identifier and the search key value are used as the matching input for the content addressable memory. If a match is found, the action data field corresponding to the random access memory address is read and output.

[0080] In this embodiment, each escape entry contains three fields: a flow group identifier field (the bit width is determined by the number of flow groups, such as 8 bits), a lookup key field (the bit width is equal to the full key width K), and an action data field (the bit width is equal to the data entry bit width). During the lookup, the flow group ID to which the current packet belongs and the lookup key are concatenated as the TCAM matching input. Each TCAM entry can be configured to precisely match a specified bit; upon a match, the corresponding SRAM address is output, and the action data is read and returned.

[0081] For example: Querying the key value 0xABCD... in flow table group 3, the escape TCAM contains...<Group=3,Key=0xABCD...> When the TCAM match is successful, output SRAM address 0x00F and read the action data from SRAM.

[0082] This step leverages the parallel matching feature of TCAM to achieve single-cycle parallel lookup of escape entries for all flow table groups, maintaining a constant lookup latency regardless of the number of entries stored in the escape zone. The use of flow table group IDs in the matching process isolates the key-value spaces of different flow table groups, avoiding key-value conflicts between groups and ensuring lookup accuracy.

[0083] Furthermore, the total capacity of the escape storage area is determined based on the following parameters:

[0084] The number of flow table groups supported by the chip, the expected number of overflow entries for each flow table group under the preset coverage threshold Pth, and the preset capacity of the linked list area.

[0085] When the usage rate of the off-chip linked list area corresponding to any flow table group exceeds a preset warning threshold, the hardware triggers the migration of some linked list entries to the escape storage area, or sends an expansion alarm signal to the control plane.

[0086] In this embodiment, the total capacity of the escape zone is determined comprehensively based on the number of flow table groups, the expected number of overflow entries for each flow table group under the coverage threshold Pth, and the preset capacity of the linked list area. During design, the theoretical overflow amount of each flow table group is first calculated using a probability model, summed, and multiplied by the number of flow table groups supported by the chip. Then, the expected simultaneous overflow peak is multiplied by an empirical coefficient (e.g., 1.5) to obtain the recommended capacity of the escape zone. During runtime, the hardware monitors the usage rate of the linked list area for each flow table group. When the usage rate of a flow table group's linked list area exceeds a warning threshold (e.g., 80%), the hardware triggers the migration of low-frequency access entries in the linked list to the escape zone, releasing the linked list nodes; or it reports an alarm to the control plane, requesting software expansion. When the usage rate of the escape zone itself also reaches its limit, the control plane is notified to adjust the overall flow table specifications.

[0087] For example, the chip supports 32 flow table groups, with each flow table group expected to have approximately 5,000 overflow entries. The initial escape zone capacity is set to 32 × 5,000 × 1.5 = 240,000 entries. During operation, the linked list area of ​​the 5th flow table group reaches 85% utilization. The hardware migrates the cold entries at the tail of this group's linked list to the escape zone, and the linked list utilization drops back to 70%.

[0088] This step, through multi-level linked capacity planning and dynamic migration mechanisms, enables a closed-loop elastic scheduling between the on-chip external linked list area and the on-chip escape area. The probabilistic model not only guides static capacity planning but also provides a reference benchmark for dynamic threshold setting. Hardware-triggered automatic migration and alarms enable real-time adaptive allocation of off-chip storage resources, significantly improving the system's ability to withstand hash collision spikes while maintaining low cost.

[0089] Furthermore, the method further includes the following steps:

[0090] The H900 has an on-chip escape storage area; the escape storage area is composed of a content addressable memory and a random access memory cascaded together; the escape storage area is shared by all flow table groups within the chip.

[0091] When the corresponding storage line in the on-chip cache has no available slots, and the entry cannot be accommodated in the off-chip main memory, an escape memory area is set up on-chip as a last resort. The escape memory area consists of cascaded Content Addressable Memory (TCAM) and Random Access Memory (SRAM), shared by all flow table groups within the chip. The TCAM portion stores the flow table group identifier and lookup key, while the SRAM portion stores the corresponding action data. Writes to the escape memory area are automatically triggered by hardware. When an entry is stored in the escape memory area, its corresponding off-chip valid flag bit ddr_vld is set to invalid, indicating that there is no backup copy of the entry in the off-chip main memory. Subsequently, if the entry is migrated from the escape memory area to the off-chip main memory, ddr_vld is updated to valid and the corresponding ddr_addr is updated.

[0092] For example: If a flow table entry has its corresponding line in the on-chip cache completely full, and there is no space in the off-chip base area and linked list area, the hardware writes the entry to the escape TCAM+SRAM. The status of the corresponding slot in the cache for this entry is marked as ddr_vld=0.

[0093] This step provides a third level of elastic storage beyond the cache and chip tables through the escape storage area, avoiding the serious problem of discarding entries due to both levels of storage being full. The escape area is shared by all flow table groups, covering extreme overflow spikes from multiple groups with a smaller total capacity. The unified flag `ddr_vld=0` for escape area entries maintains consistency in state management, ensuring that subsequent replacements still follow the low-overhead discard path of H800.

[0094] H910 When a first-order table entry needs to be stored, but there are no available slots in the corresponding storage row of the on-chip cache, and the entry cannot be accommodated in the off-chip main storage area, the entry is stored in the escape storage area.

[0095] H920, when a first-order table entry is stored in the escape storage area, the off-chip valid flag position of the slot corresponding to the entry is invalid, indicating that there is no backup copy of the entry in the off-chip main storage area.

[0096] Furthermore, the storage format of each entry in the escape storage area includes:

[0097] Flow group identifier field; used to indicate the flow group to which this entry belongs;

[0098] Lookup key field; used to store the complete lookup key value for this flow table entry as a matching input to content-addressable memory;

[0099] Action data field; used to store the forwarding or processing policy corresponding to this flow table entry;

[0100] During the search, the current flow group identifier and the current search key value are used as the matching input for the content addressable memory. After a match is found, the action data field corresponding to the random access memory address is read and output.

[0101] Each entry in the escape storage area has three fields: a flow group identifier field (its width is determined by the number of flow groups supported by the chip, indicating the flow group to which the entry belongs); a lookup key field (its width is equal to the full lookup key width K, serving as the TCAM matching input); and an action data field (its width is equal to the data table entry width, used to store policy data such as forwarding port and next-hop address). During a lookup, the flow group identifier of the current packet and the lookup key are concatenated as the TCAM matching input. All TCAM entries are compared in parallel, and upon a match, the corresponding SRAM address is output, and the action data is read and returned.

[0102] For example: Querying the key value 0xABCD in flow table group 5, the escape TCAM contains...<Group=5, Key=0xABCD> When the TCAM match is successful, the SRAM address 0x010 is output, and the motion data is read and output.

[0103] This step leverages the parallel matching feature of TCAM to achieve single-cycle parallel lookup of escape entries for all flow table groups, with a constant lookup latency independent of the number of entries. The use of flow table group IDs in the matching process isolates the key-value spaces of different flow table groups, ensuring lookup accuracy.

[0104] Furthermore, the method also includes:

[0105] H930 When the used capacity of the escape storage area reaches a preset migration threshold, the hardware controller migrates at least one entry with the lowest access frequency in the escape storage area to the off-chip main storage area, updates the off-chip valid flag corresponding to the migrated entry to valid, and updates the off-chip address field to the new physical storage address of the entry in the off-chip main storage area.

[0106] When the used capacity of the escape memory reaches a preset migration threshold (e.g., 70% of the total capacity), the hardware controller automatically triggers a migration operation. The hardware scans the escape memory, identifies at least one entry with the lowest access frequency, reads it from the escape memory, allocates space in the off-chip main memory (either a free slot in the base area or a new node in the linked list area), writes it, updates the off-chip valid flag bit `ddr_vld` of the corresponding cache slot to valid, and updates the off-chip address field `ddr_addr` to the newly allocated physical address. After the migration is complete, the storage space for this entry in the escape memory is released.

[0107] This step uses an automatic migration mechanism to move infrequently accessed cold entries from expensive on-chip TCAM resources to inexpensive off-chip DDR, ensuring rapid hits for high-frequency entries while avoiding cost overruns caused by escape zone capacity expansion. After migration, synchronized updates of ddr_vld and ddr_addr maintain consistency between state management and physical storage.

[0108] H940, when the used capacity of the escape storage area reaches a preset alarm threshold, the hardware controller sends an expansion alarm signal to the control plane; wherein, the alarm threshold is greater than the migration threshold.

[0109] When the used capacity of the escape storage area reaches a preset alarm threshold (e.g., 90% of the total capacity, where the alarm threshold exceeds the migration threshold), the hardware controller sends an expansion alarm signal to the control plane, carrying diagnostic information such as the current escape area utilization rate and the number of overflow entries in each flow table group. Upon receiving the alarm, the control plane can choose to: expand the escape area capacity configuration, increase the capacity of the off-chip linked list area, or adjust the flow table splitting strategy to reduce the load on a single group. The alarm signal is reported via an internal chip interrupt or a status register.

[0110] This step achieves a seamless transition from automatic hardware mitigation to software intervention through tiered thresholds (migration threshold < alarm threshold). When the migration threshold is triggered, the hardware first performs self-healing; when the alarm threshold is triggered, the software is notified to make a decision, forming a closed-loop management system that enhances the chip's fault tolerance under extreme loads and its long-term operational stability.

[0111] Example 3:

[0112] The off-chip hierarchical storage structure described in Embodiment 1 above has multiple applicable scenarios. This embodiment describes its first applicable scenario—an off-chip independent storage area in independent table mode (inner_mode=1). In independent table mode, if an in-chip lookup fails, the result is retrieved from this off-chip storage area and returned directly without performing a backfill operation. The in-chip lookup process employs a double hash and feature value matching mechanism, compatible with the fixed slot indexing method of the base area in the aforementioned storage structure. This method may include the following steps:

[0113] S100 receives the search request and retrieves the search key value.

[0114] In this embodiment, the lookup request is generated by the packet parsing unit inside the network chip. When a packet enters the chip, the parsing unit extracts predetermined fields from the packet header and concatenates them to form a lookup key. The constituent fields and concatenation order of the lookup key are predefined by the flow table configuration file. Typical fields include source IP address, destination IP address, source port number, destination port number, protocol type, and virtual network identifier. The lookup request receiving unit latches the lookup key into an input register and simultaneously requests a free buffer pointer from the sequence control module to temporarily store the packet's context information during the lookup process. The hardware implementation of this step can be a multiplexer working with a set of configuration registers to select the corresponding packet fields according to the currently active flow table configuration file and concatenate them for output.

[0115] This step utilizes a hardware-configurable multi-field concatenation mechanism, enabling the same lookup pipeline to adapt to the differentiated definition requirements of lookup keys in different network application scenarios. The key composition can be adjusted without modifying the hardware circuitry, thus improving the chip's flexibility and versatility.

[0116] S200, perform a first hash operation on the lookup key value to obtain the group index address, and perform a second hash operation on the lookup key value to obtain the feature value.

[0117] Furthermore, the step of performing a second hash operation on the lookup key to obtain a feature value includes the following steps:

[0118] S210, input the search key value into the second hash function to obtain a hash result value with a bit width of W.

[0119] In this embodiment, the second hash function is implemented in hardware using combinational logic circuits and operates in parallel with the first hash function without introducing additional clock cycles. The input to the second hash function is the lookup key value obtained in step S100, and its bit width is determined according to the network application scenario; typical values ​​can be 128 bits, 256 bits, or 320 bits. The output bit width W of the second hash function is jointly determined by the number of slots n per row of the on-chip hash table and the bit width of each feature value segment, satisfying W = n × w, where w is the bit width of each feature value segment.

[0120] The second hash function can employ a randomized hash algorithm based on XOR-Shift. Its hardware implementation consists of a multi-stage XOR shift network: first, the input key value is split into multiple equal-width fields and XORed to produce intermediate results; then, the intermediate results are sequentially subjected to several stages of shift and XOR operations, with each shift amount being a coprime prime offset (e.g., shift by 6, 13, or 27 bits) to fully diffuse the influence of the input bits; finally, the lower W bits of the shift network are taken as the hash result value for output.

[0121] This step uses a second hash function to compress lookup keys of arbitrary width into hash results of fixed width W. W is determined by the number of slots in each row and the feature value width of each slot, allowing a single hash calculation to provide a complete data source for parallel feature value matching of all subsequent slots. The combinational logic of the XOR-Shift algorithm completes the hash calculation within a single cycle without increasing lookup latency. Simultaneously, its multi-level shift-XOR structure effectively reduces the probability of different keys producing the same hash result, providing a high-resolution basis for subsequent slot-level matching.

[0122] S220, the hash result value is divided into n feature value segments; each feature value segment corresponds to a slot in the same storage row of the on-chip hash table; n is the maximum number of entries that can be stored in the row of the on-chip hash table.

[0123] In this embodiment, the partitioning operation requires no logic gates or registers in hardware and can be completed via hardwired bus. The physical connections of the W-bit hash result output in step S210 are divided into n groups according to the principle of equal width, with each group containing w bits. The 0th group (lowest w bits) corresponds to the feature value segment of slot 0, the 1st group corresponds to the feature value segment of slot 1, and so on, with the (n-1)th group (highest w bits) corresponding to the feature value segment of slot (n-1). Each group of w-bit signals is directly connected to the comparator input port of the corresponding slot in the subsequent step S400.

[0124] When W is not divisible by n, the following method is used: The bit width w of each segment is taken as floor(W / n), i.e., rounded down. For the first (W mod n) segments, an additional 1 bit is allocated to each, making the bit width of these segments w+1. At this point, the bit widths of each feature value segment may differ by 1 bit. Each segment is still compared with the feature value of the corresponding slot for equal bit width, and the comparator bit width is configured according to the actual bit width of each segment.

[0125] This step directly divides the result of a single hash calculation into n independent feature value segments via hardwired bus, providing matching criteria for each of the n slots without additional logic overhead. Compared to the traditional approach of calculating a hash independently for each slot, this avoids the latency accumulation and hardware area expansion caused by multiple hash calculations. Compared to the approach where all slots share the same feature value, each slot uses independent feature value segments, ensuring that the same lookup key value generates different feature values ​​in different slots. When a feature value match fails in one slot, other slots may still match successfully, thus providing multiple candidate hit positions for the same key value within the same storage row, effectively reducing the probability of lookup failures due to single feature value conflicts. Furthermore, the zero-latency characteristic of hardwired partitioning ensures that the entire feature value generation and allocation process does not occupy additional pipeline truncation time, guaranteeing a consistently high throughput for the lookup pipeline.

[0126] S300, using the group index address as the read address, read multiple pre-stored entry feature values ​​from the corresponding storage row in the on-chip hash table, with each entry feature value corresponding to a slot in the corresponding storage row.

[0127] Furthermore, each storage row of the on-chip hash table contains n slots, and each slot stores an entry feature value and a corresponding valid flag bit; reading multiple entry feature values ​​pre-stored in the corresponding storage row includes: simultaneously reading the entry feature values ​​and valid flag bits of n slots in the corresponding storage row.

[0128] In this embodiment, the group index address generated in step S200 is used as the read address to initiate a single-cycle read operation on the on-chip hash table. The on-chip hash table is implemented using static random access memory, with a depth of H rows. Each row contains n slots, and each slot stores an entry feature value and its corresponding valid flag bit. A valid flag bit of 1 indicates that the entry feature value stored in that slot is valid, while 0 indicates that the slot is idle. After the group index address is sent to the address input of the on-chip hash table, after one read cycle, the entry feature values ​​and valid flag bits of all n slots in the storage row are read out in parallel and latched into n sets of output registers. The on-chip hash table adopts a single-port design, and the read operation is exclusively powered by the lookup pipeline. The number of slots n is determined based on a combination of the desired storage capacity and hash collision tolerance. The larger n is, the stronger the tolerance for collisions in the same row, but the storage area and read power consumption increase accordingly. Typical n values ​​are 4 or 8.

[0129] This step reads the entry feature values ​​and valid flag bits of all slots in the same storage row in parallel in a single cycle, compressing the slot polling that requires multiple serial accesses in the traditional scheme into a single parallel access, which greatly reduces the lookup latency; the multi-slot group associative structure provides flexible conflict tolerance space under limited storage depth, balancing storage efficiency and lookup performance.

[0130] S400, the feature value of the search key value is compared in parallel with the feature values ​​of multiple read entries. If a matching entry feature value exists, the key value table entry of the slot corresponding to the matching entry feature value is read.

[0131] Furthermore, step S400 includes the following steps:

[0132] S410, compare the feature values ​​of the n entries read in step S300 with the feature values ​​of the search key values ​​obtained in step S200 in parallel to generate n comparison result signals.

[0133] The data read in step S300 contains n sets of entry feature values. The i-th set of entry feature values ​​corresponds to the entry feature value stored in the i-th slot, denoted as bin_tbl[i], with a bit width of w bits. The feature value of the lookup key generated in step S200 has been divided into n feature value segments, denoted as bin_key[i], with a bit width of w bits.

[0134] The hardware uses an array of n w-bit XOR gates. For the i-th slot, bin_tbl[i] and bin_key[i] are XORed bit by bit, generating w XOR result lines. These w XOR result lines are then input into a w-input NOR gate, and the output of the NOR gate is the i-th comparison result signal cmp[i]. When every bit of bin_tbl[i] and bin_key[i] is equal, all w XOR result lines are low, and the NOR gate outputs a high level, indicating that the feature value comparison result is consistent. When any bit is unequal, the NOR gate outputs a low level, indicating that the feature value comparison result is inconsistent.

[0135] The n comparator arrays are fully parallel in hardware and have no data dependency on each other. The combinational logic delay of all comparators from input to output is only one XOR gate delay plus one NOR gate delay, which can be completed in one clock cycle.

[0136] This step achieves fully parallel comparison of feature values ​​for all slots using n independent hardware comparator arrays. The comparison latency is constant at two gate stages, independent of the number of slots (n), thus preventing increased lookup latency as the number of slots expands and ensuring pipeline timing convergence. Each slot uses an independent feature value fragment for matching. Compared to schemes where all slots share the same feature value, the matching results for each slot are independent, allowing the same lookup key value to match multiple different slots within the same storage row, providing a flexible candidate match selection space for subsequent steps.

[0137] S420, for any comparison result signal RA, if the valid flag bit of the slot corresponding to RA is valid and the feature value comparison result is consistent, then the slot corresponding to RA is determined to be a candidate hit slot.

[0138] In step S300, while reading the entry feature value, the valid flag bit vld[i] corresponding to each slot is also read. The value of i ranges from 0 to n-1. The valid flag bit is a 1-bit signal. vld[i]=1 indicates that the entry feature value currently stored in the i-th slot is valid, and vld[i]=0 indicates that the slot is idle.

[0139] The hardware uses n two-input AND gates. For the i-th slot, the two inputs of the AND gate are connected to the comparison result signal cmp[i] and the valid flag bit vld[i], respectively. The output of the AND gate is the candidate hit indicator signal hit_cand[i]. hit_cand[i] = 1 if and only if cmp[i] = 1 and vld[i] = 1, indicating that the i-th slot is a candidate hit slot; otherwise, hit_cand[i] = 0.

[0140] The hardware logic in this step forcibly masks the comparison results of free slots. When vld[i]=0 for a certain slot, hit_cand[i] is always 0 regardless of the value of cmp[i]. When vld[i]=1 for a certain slot but cmp[i]=0, hit_cand[i] is also 0, indicating that although the slot is occupied, it is not the entry matched in this search.

[0141] This step incorporates the gatekeeper's valid flag into the candidate hit determination, completing the parallel validity screening of n slots with only one gate delay. This mechanism fundamentally avoids the problem of erroneous hits caused by coincidental matching of key-value features in idle slots due to stored residual values ​​or power-on initial values, thus ensuring the correctness of the search results.

[0142] S430, if there is at least one candidate hit slot, then select one from the candidate hit slots as the final hit slot according to the preset priority order.

[0143] In this embodiment, firstly, the n candidate hit indication signals hit_cand[0] to hit_cand[n-1] generated in step S420 are input into an n-input OR gate to generate a group hit signal group_hit. group_hit=1 indicates that there is at least one candidate hit slot; group_hit=0 indicates that no candidate hits are found in any slot.

[0144] When group_hit=1, the priority arbitration logic is activated. The default priority order is: the smaller the slot number, the higher the priority. That is, the priority from high to low is slot 0, slot 1, ..., slot (n-1).

[0145] The hardware implementation of priority arbitration uses a fixed-priority encoder. The encoder takes an n-bit candidate hit indication signal `hit_cand[n-1:0]` as input and outputs the final hit slot number `hit_idx`, with a bit width of `ceil(log₂n)` bits. The encoding logic is as follows: scanning from the high-order bits (n-1) to the low-order bits (0), outputting the position number of the first 1 bit, with the scanning direction corresponding to low priority to high priority, so that the valid bit with the smallest number is selected.

[0146] The specific logical expression is as follows: when hit_cand[0]=1, hit_idx=0 regardless of the value of other bits; when hit_cand[0]=0 and hit_cand[1]=1, hit_idx=1; and so on. This encoder is implemented entirely by combinational logic, with a delay of several levels of gate delay.

[0147] This step uses a fixed-priority encoder to complete a unique arbitration of multiple candidate hits within a single cycle, with hardware overhead consisting of only a few gate circuits and no timing bottlenecks. The fixed-priority design avoids the additional state storage and update circuitry required for complex round-robin or least recently used arbitration logic, consistent with the design principle of no automatic hardware state updates in the independent table mode of this embodiment. Smaller slot numbers indicate higher priority; this rule is simple and clear, allowing the software to prioritize filling lower-numbered slots when configuring entries to optimize the hardware arbitration path.

[0148] S440, using the group index address as the read address and the slot number of the final hit slot as the path selection signal, read the corresponding key value table entry from the key value table.

[0149] In this embodiment, the on-chip key-value table adopts the same storage structure as the on-chip hash table: a depth of H rows, with each row containing n slots, indexed by both group index address and slot number. Each slot in the key-value table stores the complete key value of a flow table entry, with a bit width of K bits, where K is equal to the bit width of the key value search in step S100, typically 128 bits, 256 bits, or 320 bits.

[0150] The read operation consists of two sub-actions: First, the group index address generated in step S200 is applied to the row address input of the key-value table to select the corresponding storage row. Then, the final hit slot number hit_idx output in step S430 is used as a column selection signal to select the key-value table entry of the hit_idx-th slot from the n slot data read. The column selection of the key-value table is implemented by an n-to-1 multiplexer, whose data input is connected to the output ports of the n slots in that row of the key-value table, and whose selection control is connected to hit_idx.

[0151] The entire reading process is coordinated with the hash table read in step S300. In the pipelined implementation, the group index address is ready in step S200 and can be sent to the key-value table address input in advance; hit_idx is latched after arbitration in step S430 and serves as a column strobe signal. The key-value table read latency is the same as the hash table read latency, both being one memory access cycle.

[0152] The on-chip key-value table and the on-chip hash table use a unified slot mapping relationship. When a first-order table entry is written to the addr-th row and i-th slot of the on-chip hash table, the complete key-value of that entry is simultaneously written to the addr-th row and i-th slot of the on-chip key-value table. This mapping relationship is guaranteed by the control plane when configuring entries, and is not modified during hardware lookup.

[0153] This step employs a strict isomorphic design between the key-value table and the hash table in terms of depth and slot mapping, using the group index address and slot number as a common index. This allows for direct location of the corresponding entry in the key-value table after a successful match in the hash table's feature value, eliminating the need for secondary address calculation or traversal of collision chains. The column gating latency of the n-to-1 multiplexer remains constant and does not deteriorate with the increase in the number of slots, ensuring the deterministic timing of key-value table reads. The key-value table stores complete key values ​​rather than compressed signatures, providing a precise basis for the full-width comparison in step S500 and fundamentally eliminating the possibility of false hits due to hash collisions.

[0154] S500: If the search key value matches the complete key value stored in the key-value table entry, then the data table entry of the corresponding slot is read and the search result is output; otherwise, the search result is obtained from the off-chip independent storage area; wherein, the on-chip hash table, key-value table, and data table constitute an exact matching flow table independent of the off-chip storage, the on-chip hash table, key-value table, and data table have the same depth and slot mapping relationship, and are indexed by the group index address and slot number; the on-chip storage entries are pre-configured, and no hardware automatic replacement operation is performed on the on-chip hash table, key-value table, and data table during the search process.

[0155] Furthermore, step S500 includes the following steps:

[0156] S510, compare the search key value with the complete key value stored in the key value table entry read in step S400. If every bit is consistent, the key value is determined to be successfully matched and proceed to S520; otherwise, proceed to S530.

[0157] The hardware consists of an XOR gate array with a bit width of K and a K-input NOR gate. The search key value `key_search` obtained in step S100 is XORed bit by bit with the key value entry `key_tbl` read in step S400, generating K XOR result lines. All K XOR result lines are input to a K-input NOR gate, and the output is the key-value matching signal `key_match`. When every bit of `key_search` and `key_tbl` is equal, all XOR result lines are low, `key_match` = 1, indicating a successful key-value match; if any bit is unequal, `key_match` = 0, indicating a failed key-value match.

[0158] This step achieves precise matching verification between the search key and the stored key through a full-width XOR comparison, fundamentally eliminating the possibility of false hits caused by feature value hash collisions. Since the feature value matching in the previous step S400 only compares the w-bit compressed signature, different keys may produce the same feature value. This step extends the discrimination criterion to the complete K-bit key value, reducing the probability of false hits from the probability of feature value collisions to zero, thus ensuring the absolute correctness of the search result.

[0159] S520: Using the group index address as the read address and the slot number of the finally hit slot as the path selection signal, read the data table entry of the corresponding slot from the data table and output the data table entry as the search result.

[0160] After key-value verification is successful, this step reads the final search result from the data table. Its indexing method is completely consistent with the key-value table reading in step S440: the corresponding storage row is selected using the group index address as the row address, and the corresponding data table item is selected and output from the n slots using the hit slot number as the column strobe signal. The data table, hash table, and key-value table have the same depth and slot mapping relationship; together, they constitute a complete on-chip exact match flow table.

[0161] This step leverages the design advantages of isomorphic mapping of three tables, using a unified group index address and slot number as a common index, so that reading the lookup result data does not require additional address calculations. The hardware implementation is simple and efficient, and the data return can be completed in one memory access cycle.

[0162] S530, generate an access request to the off-chip independent storage area, retrieve the flow table entry data corresponding to the lookup key value from the off-chip independent storage area as the lookup result output, and do not perform backfilling operations on the on-chip hash table, key value table and data table.

[0163] When step S510 determines that the key value matching fails, or when the feature value comparison in the previous step S400 fails to find a match, the hardware generates an off-chip access request. This request carries a lookup key value or an off-chip address generated based on the lookup key value and is sent to the off-chip memory controller. The off-chip memory controller accesses the independent flow table in the off-chip dynamic random access memory (DDR) according to the address information in the request, obtains the corresponding flow table entry data, and returns the lookup result to the message processing unit.

[0164] Throughout the process, the hardware does not perform any write operations on the on-chip hash table, key-value table, or data table. The addition, deletion, and updating of entries in the on-chip tables are entirely pre-completed by the control plane through a separate configuration interface at a time other than the lookup operation. The hardware state machine for a missed path only includes the two actions of "reading from outside the chip → returning the result," and does not include the backfill action of "reading from outside the chip → writing to inside the chip → returning the result."

[0165] This step significantly reduces hardware design complexity and state machine size by simplifying miss handling into a single off-chip read operation.

[0166] Example 4:

[0167] The above embodiment three describes the application of an off-chip hierarchical storage structure in independent table mode. This embodiment describes its second applicable scenario—as an off-chip main storage area in cache mode (inner_mode=0). In cache mode, this storage structure not only provides data retrieval in case of a miss, but also serves as the write-back target for replacement entries. During cache backfilling, entries are read from fixed slots in the base area or linked list nodes and written to the on-chip storage. During replacement write-back, entries are written to the corresponding positions according to the off-chip address field in the cache status table entry. The cache lookup process adds aging count update and replacement backfilling operations to the independent table lookup process in embodiment three. Specifically, it may include the following steps:

[0168] Q100 receives a search request and retrieves the search key value.

[0169] The lookup request is generated by the packet parsing unit inside the network chip. When a packet enters the chip, the parsing unit extracts predetermined fields from the packet header and concatenates them to form a lookup key. The components and concatenation order of the lookup key are predefined by the flow table configuration file. Typical fields include source IP address, destination IP address, source port number, destination port number, protocol type, and virtual network identifier. The lookup request receiving unit latches the lookup key into the input register and simultaneously requests a free buffer pointer from the sequence control module to temporarily store the packet's context information during the lookup process.

[0170] This step utilizes a hardware-configurable multi-field concatenation mechanism, enabling the same cache lookup pipeline to adapt to the differentiated definition requirements of lookup keys in different network application scenarios. The key composition can be adjusted without modifying the hardware circuitry, thus improving the chip's flexibility and versatility.

[0171] Q200, perform a first hash operation on the lookup key value to obtain the group index address, and perform a second hash operation on the lookup key value to obtain the feature value.

[0172] Furthermore, in step Q200, a second hash operation is performed on the lookup key to obtain a feature value, including the following steps:

[0173] Q210, input the search key value into the second hash function to obtain a hash result value with a bit width of W.

[0174] In this embodiment, the second hash function is implemented in hardware using combinational logic circuits and operates in parallel with the first hash function without introducing additional clock cycles. The input to the second hash function is the lookup key value obtained in step S100, and its bit width is determined according to the network application scenario; typical values ​​can be 128 bits, 256 bits, or 320 bits. The output bit width W of the second hash function is jointly determined by the number of slots n per row of the on-chip hash table and the bit width of each feature value segment, satisfying W = n × w, where w is the bit width of each feature value segment.

[0175] The second hash function can employ a randomized hash algorithm based on XOR-Shift. Its hardware implementation consists of a multi-stage XOR shift network: first, the input key value is split into multiple equal-width fields and XORed to produce intermediate results; then, the intermediate results are sequentially subjected to several stages of shift and XOR operations, with each shift amount being a coprime prime offset (e.g., shift by 6, 13, or 27 bits) to fully diffuse the influence of the input bits; finally, the lower W bits of the shift network are taken as the hash result value for output.

[0176] This step uses a second hash function to compress lookup keys of arbitrary width into hash results of fixed width W. W is determined by the number of slots in each row and the feature value width of each slot, allowing a single hash calculation to provide a complete data source for parallel feature value matching of all subsequent slots. The combinational logic of the XOR-Shift algorithm completes the hash calculation within a single cycle without increasing lookup latency. Simultaneously, its multi-level shift-XOR structure effectively reduces the probability of different keys producing the same hash result, providing a high-resolution basis for subsequent slot-level matching.

[0177] Q220, the hash result value is divided into n feature value segments, each feature value segment corresponding to a slot in the same storage row of the Cache hash table; where n is the maximum number of entries that can be stored in a row of the Cache hash table.

[0178] In this embodiment, the partitioning operation requires no logic gates or registers in hardware and can be completed via hardwired bus. The physical connections of the W-bit hash result output in step S210 are divided into n groups according to the principle of equal width, with each group containing w bits. The 0th group (lowest w bits) corresponds to the feature value segment of slot 0, the 1st group corresponds to the feature value segment of slot 1, and so on, with the (n-1)th group (highest w bits) corresponding to the feature value segment of slot (n-1). Each group of w-bit signals is directly connected to the comparator input port of the corresponding slot in the subsequent step S400.

[0179] When W is not divisible by n, the following method is used: The bit width w of each segment is taken as floor(W / n), i.e., rounded down. For the first (W mod n) segments, an additional 1 bit is allocated to each, making the bit width of these segments w+1. At this point, the bit widths of each feature value segment may differ by 1 bit. Each segment is still compared with the feature value of the corresponding slot for equal bit width, and the comparator bit width is configured according to the actual bit width of each segment.

[0180] This step directly divides the result of a single hash calculation into n independent feature value segments via hardwired bus, providing matching criteria for each of the n slots without additional logic overhead. Compared to the traditional approach of calculating a hash independently for each slot, this avoids the latency accumulation and hardware area expansion caused by multiple hash calculations. Compared to the approach where all slots share the same feature value, each slot uses independent feature value segments, ensuring that the same lookup key value generates different feature values ​​in different slots. When a feature value match fails in one slot, other slots may still match successfully, thus providing multiple candidate hit positions for the same key value within the same storage row, effectively reducing the probability of lookup failures due to single feature value conflicts. Furthermore, the zero-latency characteristic of hardwired partitioning ensures that the entire feature value generation and allocation process does not occupy additional pipeline truncation time, guaranteeing a consistently high throughput for the lookup pipeline.

[0181] Q300 uses the group index address as the read address to read multiple pre-stored entry feature values ​​in the corresponding storage row from the Cache hash table. Each entry feature value corresponds to a slot in the corresponding storage row.

[0182] Furthermore, each storage row of the Cache hash table contains n slots, and each slot stores an entry feature value and a corresponding valid flag bit; when the group index address is used as the read address, the Cache hash table reads out the entry feature values ​​and corresponding valid flag bits of all n slots in the storage row in parallel within one read cycle.

[0183] Using the group index address generated in step Q200 as the read address, a single-cycle read operation is initiated on the Cache hash table. The Cache hash table is implemented using static random access memory, with a depth of H rows. Each row contains n slots, and each slot stores an entry feature value and its corresponding validity flag. A validity flag of 1 indicates that the entry feature value stored in that slot is valid, while 0 indicates that the slot is idle. After the group index address is sent to the address input of the Cache hash table, after one read cycle, the entry feature values ​​and validity flags of all n slots in that storage row are read in parallel and latched into n sets of output registers. Simultaneously, using the same group index address, the aging count values ​​and operation count values ​​corresponding to all n slots in that storage row are read from the aging count table and operation count table, respectively, for use in subsequent steps.

[0184] This step reads the entry feature value, validity flag, aging count value and operation count value of all slots in the same storage line in parallel in a single cycle, compressing the slot polling that requires multiple serial accesses in the traditional scheme into a single parallel access, which greatly reduces the cache lookup latency; the multi-slot group associative structure provides flexible conflict tolerance space under limited storage depth, balancing storage efficiency and lookup performance.

[0185] Q400: The feature value of the search key value is compared in parallel with the feature values ​​of multiple read entries. If a matching entry feature value exists, the Cache key value table entry of the slot corresponding to the matching entry feature value is read.

[0186] This step is implemented in hardware using an array of n independent bit-by-bit comparators, which simultaneously compares the feature values ​​of the n slot entries read from the Cache hash table in step Q300 with the corresponding feature value fragments of the lookup key generated in step Q200.

[0187] Furthermore, step Q400 includes the following steps:

[0188] Q410, compare the feature values ​​of the n entries read in step Q300 with the feature values ​​of the search key values ​​obtained in step Q200 in parallel to generate n comparison result signals.

[0189] In this embodiment, the data read in step Q300 contains n sets of entry feature values. The i-th set of entry feature values ​​corresponds to the entry feature value stored in the i-th slot, denoted as bin_tbl[i], with a bit width of w bits. The feature value of the lookup key generated in step Q200 has been divided into n feature value segments, denoted as bin_key[i], with a bit width of w bits.

[0190] The hardware uses an array of n w-bit XOR gates. For the i-th slot, bin_tbl[i] and bin_key[i] are XORed bit by bit, generating w XOR result lines. These w XOR result lines are then input into a w-input NOR gate, and the output of the NOR gate is the i-th comparison result signal cmp[i]. When every bit of bin_tbl[i] and bin_key[i] is equal, all w XOR result lines are low, and the NOR gate outputs a high level, indicating that the feature value comparison result is consistent. When any bit is unequal, the NOR gate outputs a low level, indicating that the feature value comparison result is inconsistent.

[0191] The n comparator arrays are fully parallel in hardware and have no data dependency on each other. The combinational logic delay of all comparators from input to output is only one XOR gate delay plus one NOR gate delay, which can be completed in one clock cycle.

[0192] This step achieves fully parallel comparison of all slot feature values ​​through n independent hardware comparator arrays. The comparison latency is constant at two gate levels, independent of the number of slots (n), thus not increasing the lookup latency when the number of slots expands, ensuring the timing convergence of the cache lookup pipeline. Each slot uses an independent feature value fragment for matching. Compared to a scheme where all slots share the same feature value, the matching results of each slot are independent, allowing the same lookup key value to match multiple different slots within the same storage line. This provides a flexible candidate hit selection space for subsequent steps, effectively improving the cache's tolerance to hash collisions.

[0193] Q420: For any comparison result signal RA, perform a logical AND judgment with the valid flag bit of the slot corresponding to RA. If the valid flag bit is valid and the feature value comparison result is consistent, then the slot corresponding to RA is determined to be a candidate hit slot.

[0194] In this embodiment, step Q300 reads the entry feature value and the valid flag bit vld[i] corresponding to each slot. The value of i ranges from 0 to n-1. The valid flag bit is a 1-bit signal. vld[i]=1 indicates that the entry feature value currently stored in the i-th slot is valid, and vld[i]=0 indicates that the slot is idle.

[0195] The hardware uses n two-input AND gates. For the i-th slot, the two inputs of the AND gate are connected to the comparison result signal cmp[i] and the valid flag bit vld[i], respectively. The output of the AND gate is the candidate hit indicator signal hit_cand[i]. hit_cand[i] = 1 if and only if cmp[i] = 1 and vld[i] = 1, indicating that the i-th slot is a candidate hit slot; otherwise, hit_cand[i] = 0.

[0196] The hardware logic in this step forcibly masks the comparison results of free slots. When vld[i]=0 for a certain slot, hit_cand[i] is always 0 regardless of the value of cmp[i]. When vld[i]=1 for a certain slot but cmp[i]=0, hit_cand[i] is also 0, indicating that although the slot is occupied, it is not the entry matched in this search.

[0197] This step incorporates the validity flag into the candidate hit judgment, requiring only one gate delay to complete the parallel validity screening of n slots. This mechanism fundamentally avoids the problem of false hits caused by idle slots coincidentally matching key-value features due to stored residual values ​​or power-on initial values, ensuring the correctness of cache lookup results. In cache mode, slots are frequently allocated and released due to replacement operations. Accurate screening of the validity flag ensures that newly released idle slots will not produce false matches due to residual old data, maintaining the consistency of the cache state.

[0198] Q430: If there is at least one candidate hit slot, then select one from the candidate hit slots as the final hit slot according to the preset priority order.

[0199] In this embodiment, firstly, the n candidate hit indication signals hit_cand[0] to hit_cand[n-1] generated in step Q420 are input into an n-input OR gate to generate a group hit signal group_hit. group_hit=1 indicates that at least one candidate hit slot exists; group_hit=0 indicates that no candidate hit exists in any slot.

[0200] When `group_hit=1`, the priority arbitration logic is activated. The default priority order is: the smaller the slot number, the higher the priority. That is, the priorities from high to low are slot 0, slot 1, ..., slot (n-1). This priority order is chosen for the simplicity of hardware implementation, as the fixed-priority encoder does not need to maintain dynamic priority states.

[0201] The hardware implementation of priority arbitration uses a fixed priority encoder. The encoder takes an n-bit candidate hit indication signal hit_cand[n-1:0] as input and outputs the final hit slot number hit_idx, with a bit width of ceil(log2n) bits. The encoding logic is as follows: scan from the low bit (0) to the high bit (n-1) and output the position number of the first bit that is 1. The specific logical expression is: when hit_cand[0]=1, hit_idx=0 regardless of the value of other bits; when hit_cand[0]=0 and hit_cand[1]=1, hit_idx=1; and so on.

[0202] Under normal cache operating conditions, since the feature values ​​of entries stored in each slot come from the second hash operation results of different flow table entries, the probability of multiple slots in the same storage row simultaneously matching the same lookup key is extremely low. This arbitration mechanism is mainly used to cover this extremely low probability boundary case.

[0203] This step uses a fixed-priority encoder to complete a unique arbitration of multiple candidate hits within a single cycle, with hardware overhead consisting of only a few gate circuits and no timing bottlenecks. The fixed-priority design avoids the additional state storage and dynamic update circuitry required for complex arbitration logic such as round-robin or least recently used, aligning with the cache hardware design goal of low latency and high throughput. In slot replacement operations, new entries prioritize filling lower-numbered free slots, naturally increasing the probability of lower-numbered slots being hit; therefore, the fixed-priority rule is statistically reasonable.

[0204] Q440 uses the group index address as the read address and the slot number of the final hit slot as the path selection signal to read the corresponding key-value table entry from the Cache key-value table.

[0205] In this embodiment, the Cache key-value table adopts the same storage structure as the Cache hash table: a depth of H rows, with each row containing n slots, indexed by both the group index address and the slot number. Each slot in the key-value table stores the complete key value of a flow table entry, with a bit width of K bits, where K is equal to the bit width for looking up the key value in step Q100.

[0206] The read operation consists of two sub-actions: First, the group index address generated in step Q200 is applied to the row address input of the Cache key-value table to select the corresponding storage row. Then, the final hit slot number hit_idx output in step Q430 is used as a column selection signal to select the key-value table entry for the hit_idx-th slot from the n read slot data. Column selection of the key-value table is implemented by an n-to-1 multiplexer, whose data input is connected to the output ports of the n slots in that row of the key-value table, and whose selection control is connected to hit_idx.

[0207] In the pipelined implementation, the group index address is ready in step Q200 and can be sent to the key-value table address input in advance, initiating synchronously with the cache hash table read. hit_idx is latched after arbitration in step Q430 and applied to the multiplexer as a column strobe signal. The key-value table read latency is the same as the cache hash table read latency, both being one memory access cycle.

[0208] The cache key-value table and the cache hash table use a unified slot mapping relationship. When a first-order table entry is written to the addr-th row and i-th slot of the cache hash table through a replacement and backfill operation, the complete key-value pair of that entry is simultaneously written to the addr-th row and i-th slot of the cache key-value table. This mapping relationship is guaranteed by the replacement and backfill control unit during write operations.

[0209] This step employs a strict isomorphic design between the key-value table and the hash table in terms of depth and slot mapping. Using the group index address and slot number as a common index, it allows direct location of the corresponding entry in the key-value table after a successful hash table feature value match, eliminating the need for secondary address calculation or traversal of conflict chains. The column gating latency of the n-to-1 multiplexer remains constant and does not deteriorate with increasing slot length, ensuring the deterministic timing of key-value table reads. The key-value table stores complete key values, not just compressed signatures, providing a precise basis for the full-width comparison in step Q500. This fundamentally eliminates the possibility of cache misses due to hash collisions, ensuring the absolute correctness of cache lookup results.

[0210] Q500 compares the lookup key value with the complete key value stored in the Cache key value table entry. If they match, it is determined that the Cache has hit. The Cache data table entry of the corresponding slot is read, the lookup result is output, and the aging count of the hit slot is updated.

[0211] Furthermore, step Q500 includes the following steps:

[0212] Q510: Compare the search key value with the complete key value stored in the Cache key value table entry read in step Q400. If every bit is the same, the key value is determined to be a successful match, and proceed to Q520; otherwise, it is determined to be a Cache miss, and proceed to step Q600.

[0213] In this embodiment, a K-bit XOR gate array and a K-input NOR gate are configured in the hardware. The lookup key value `key_search` obtained in step Q100 is XORed bit by bit with the cache key value entry `key_tbl` read in step Q400, generating K XOR result lines. All K XOR result lines are input to a K-input NOR gate, and the output is the key-value matching signal `key_match`. When every bit of `key_search` and `key_tbl` is equal, all XOR result lines are low, `key_match` = 1, indicating a successful key-value match and a cache hit; if any bit is unequal, `key_match` = 0, indicating a failed key-value match and a cache miss.

[0214] For example: Suppose K = 128 bits. The first 127 bits of key_search and key_tbl are equal. The 128th bit is key_search 1 and key_tbl 0. Then the XOR gate outputs 1, the NOR gate outputs 0, key_match = 0, and it is determined that there is a cache miss.

[0215] This step achieves precise matching verification between the search key and the stored key through a full-width XOR comparison. Since the feature comparison in the previous step Q400 only compares the w-bit compressed signature, different keys may produce the same feature value (i.e., hash feature value collision). This step extends the discrimination criterion to the complete K-bit key value, reducing the probability of a false hit from the feature value collision probability to zero, thus ensuring the correctness of the cache lookup result. The full-width comparison is implemented using pure combinational logic, and the latency is proportional to the logarithm of the key width. Even for a 320-bit wide key value, the latency remains within an acceptable range per cycle and does not affect the timing convergence of the cache lookup pipeline.

[0216] Q520 uses the group index address as the read address and the slot number of the finally hit slot as the path selection signal to read the data table entry of the corresponding slot from the Cache data table as the lookup result output.

[0217] After key-value verification is successful, this step reads the final lookup result from the Cache data table. The indexing method is completely consistent with the key-value table read in step Q440: the group index address generated in step Q200 is used as the row address to select the corresponding storage row, and the hit slot number determined in step Q430 is used as the column strobe signal. An n-to-1 multiplexer selects the corresponding data table entry from the n slots of that row for output. The Cache data table, Cache hash table, and Cache key-value table have the same depth and slot mapping relationship; these three tables together constitute a complete on-chip cache storage structure.

[0218] This step leverages the design advantages of isomorphic mapping across the three tables, using a unified group index address and slot number as a common index. This allows the reading of search result data to share the same address generation logic as key-value reading, eliminating the need for additional address calculations. The hardware implementation is simple and efficient, completing data return within a single memory access cycle. The separate storage architecture of the three tables allows the hash table, key-value table, and data table to be physically implemented using different memory types and bit widths, optimizing their area and power consumption characteristics respectively.

[0219] Q530, reset the aging count corresponding to the final hit slot to the initial value, and decrement the aging count of the remaining slots in the same storage row respectively.

[0220] This step involves dynamically updating the aging count after a cache hit, and it is the core mechanism for tracking hot and cold caches in the cache replacement strategy.

[0221] The aging counter table has the same depth and slot mapping as the cache hash table. Each slot maintains an aging counter value with a width of A bits, where A is typically 4 to 8 bits. The aging counter is updated by the counter update unit in the next clock cycle after the hit signal is generated.

[0222] For a hit in slot i, its aging count age_cnt[i] is reset to the initial value init_value. The initial value init_value is usually set to the maximum value that the counter's bit width can represent (e.g., when A=4, init_value=4'b1111, i.e., 15), or configured according to the system's preset initial heat level. The reset operation is implemented by writing init_value to the i-th slot in the addr-th row of the aging count table.

[0223] For all slots j (j≠i) within the same storage row except for the hit slot, their aging count age_cnt[j] is decremented by 1. The decrement operation is implemented using a subtractor: if the current age_cnt[j]>0, then age_cnt[j]-1 is written; if the current age_cnt[j]=0, then it remains at 0 and is not decremented further to prevent the aging state from being disordered due to counter flipping. The saturation process of decrement ensures that cold entries that have not been hit for a long time remain stable at a value of 0, and will not be mistakenly identified as hot entries due to continuous decrementing and flipping to the maximum value.

[0224] For example: Let addr=0x1A, n=4, and the hit slot is the 2nd slot. The current aging count values ​​are: age_cnt[0]=5, age_cnt[1]=0, age_cnt[2]=3, age_cnt[3]=8. After the update: age_cnt[2] is reset to 15 (init_value), age_cnt[0] is decremented to 4, age_cnt[1] remains unchanged at 0, and age_cnt[3] is decremented to 7.

[0225] This step achieves fine-grained hot / cold status tracking at the slot level through a differentiated update strategy that resets the initial value of hit slots and decrements the value of other slots. Hot items, due to frequent hits, maintain a consistently high aging count; cold items, having not been hit for a long time, gradually decay their aging count to zero. Slots with zero aging counts are prioritized for replacement in the Q600's replacement and backfilling operation, thus naturally achieving a near-Least Recently Used (LRU) replacement effect. Compared to traditional LRU linked list implementations, this scheme has minimal hardware overhead for counter increment / decrement operations, requiring only adders and comparators, eliminating the need to maintain complex linked list pointers and sorting logic; furthermore, the update operation is tightly coupled with the search process, completing in the next clock cycle after a hit, eliminating the need for background periodic scanning, simplifying the hardware state machine design, and reducing power consumption.

[0226] Q600: If the feature value comparison shows no match, or the complete key value comparison shows no consistency, it is determined as a cache miss, generating an access request to the off-chip main storage area. The search result is obtained from the off-chip main storage area, and a replacement and backfill operation is performed based on the aging count and operation count of each slot in the storage row. The cache hash table, cache key-value table, and cache data table constitute a cache subset of the off-chip main storage area. The aging count is used to characterize the length of time the corresponding slot has been missed, and the operation count is used to characterize whether the corresponding slot is currently in an operational state. During the replacement and backfill operation, the slot with an aging count of zero and an operation count of zero is selected as the slot to be replaced.

[0227] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0228] Embodiments of the present invention also provide a chip, the chip comprising:

[0229] The on-chip cache unit is used to cache a subset of hot entries in the off-chip hash table.

[0230] An off-chip storage control unit is used to manage the off-chip hash table in the off-chip storage space, which is divided into a base area and a linked list area.

[0231] The parameter configuration unit is used to obtain the flow table size parameters, including the total number of flow table entries M to be stored and the number of storage rows N corresponding to the preset index bit width of the off-chip hash table.

[0232] The calculation unit is used to calculate the average load λ=M / N in each storage row based on the total number of flow table entries M and the number of storage rows N, and to calculate the probability value P(k) of exactly k entries in a single storage row for different non-negative integers k using a probability distribution model based on the average load λ.

[0233] The slot number determination unit is used to select the minimum k value that makes the cumulative probability reach a preset coverage threshold based on the calculated probability values ​​P(k), and use it as the fixed slot number η of the base area of ​​the off-chip hash table.

[0234] The storage partitioning unit is used to configure each storage row of the off-chip hash table to contain η fixed slots according to the fixed number of slots η, and to reserve storage space for the linked list area.

[0235] The off-chip storage control unit also includes:

[0236] The base area access subunit is used to preferentially store the flow table entry in the n fixed slots of the target storage row when the flow table entry is mapped to the target storage row through a hash operation.

[0237] The linked list area access subunit is used to allocate a linked list node from the linked list area to store an overflow entry when all η fixed slots of the target storage row are occupied, and to link the linked list node to the overflow linked list of the target storage row.

[0238] Embodiments of the present invention also provide a network interface card (NIC), which includes the chip described in the above embodiments.

[0239] While specific embodiments of the invention have been described in detail by way of examples, those skilled in the art should understand that the examples are for illustrative purposes only and are not intended to limit the scope of the invention. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the invention.

Claims

1. An off-chip memory structure setting method for precisely matching a flow table, characterized by, The method includes the following steps: R100, obtain the flow table size parameters; the flow table size parameters include: the total number of flow table entries M to be stored, and the number of storage rows N corresponding to the preset index bit width of the off-chip hash table; R200, based on the total number of flow table entries M and the number of storage rows N, calculate the average load λ=M / N within each storage row of the off-chip hash table; R300, based on λ, using the probability distribution model, calculate the probability value P(k) for different non-negative integers k, respectively, that exactly k entries fall within a single storage line; R400, based on the calculated probability values ​​P(k), select the minimum k value that makes the cumulative probability reach the preset coverage threshold Pth, and use it as the fixed number of slots η in the base area of ​​the off-chip hash table. R500 divides the off-chip storage space into a base area and a linked list area. The base area contains N storage rows, each row has η fixed slots, which are used to store the corresponding hash map flow table entries. The linked list area is used to dynamically store overflow entries that exceed the number of fixed slots in the base area. R600: When a first-order table entry is mapped to a target storage row via hash operation, and all η fixed slots in the base area of ​​the target storage row are occupied, a linked list node is allocated from the linked list area to store the overflow entry, and the linked list node is linked to the overflow linked list of the target storage row; wherein, the off-chip hash table works in conjunction with the on-chip cache, and the on-chip cache caches a subset of hot entries in the off-chip hash table.

2. The method of claim 1, wherein, The probability distribution model is either a binomial distribution model or a Poisson distribution model; when the values ​​of M and N cause the average load λ to not exceed a preset threshold, the probability value P(k) is calculated using a Poisson distribution model: ； Where e is a natural constant and k is a non-negative integer.

3. The method for setting up an off-chip storage structure for precise matching flow tables according to claim 1, characterized in that, The value of Pth ranges from 90% to 99%; the cumulative probability is the sum of the probability values ​​P(k) from k from 0 to the current value; when selecting a fixed number of slots η, the following conditions must be met: ； Where η is the smallest non-negative integer that satisfies the above conditions.

4. The method for setting up an off-chip storage structure for precise matching flow tables according to claim 1, characterized in that, The capacity of the linked list area is determined through the following steps: R510, based on P(k), calculate the expected number of storage rows E_overflow for more than η entries: ； R520, based on the expected value E_overflow, sets the linked list area to provide storage space for at least E_overflow linked list nodes, with each linked list node used to store an overflow entry and its next node pointer.

5. The method for setting up an off-chip storage structure for precise matching flow tables according to claim 1, characterized in that, In step R600, when a first-order table entry LB is replaced from the on-chip cache and needs to be written back to off-chip storage, the method further includes... the following: R610, if LB was originally stored in a fixed slot in the base area, then write back the original slot address directly; R620: If the LB was originally stored in the linked list area, then the next node pointer stored in the original linked list node of the LB is used to traverse to the target node and then the write-back operation is performed.

6. The method for setting up an off-chip storage structure for precise matching flow tables according to claim 1, characterized in that, The method further includes: The R700 has an on-chip escape storage area, which is composed of a cascaded content addressable memory and random access memory; the escape storage area is shared by all flow table groups within the chip. R710: When the fixed slots in the base area of ​​the off-chip hash table are full and there are no available linked list nodes in the linked list area of ​​the corresponding storage row, the overflow entries are stored in the escape storage area.

7. The method for setting up an off-chip storage structure for precise matching flow tables according to claim 6, characterized in that, The storage format of each entry in the escape storage area includes: The flow group identifier field indicates the flow group to which this entry belongs; The lookup key field stores the complete lookup key value for this flow table entry; The action data field is used to store the forwarding or processing policy corresponding to this flow table entry; During the search, the current flow group identifier and the search key value are used as the matching input for the content addressable memory. If a match is found, the action data field corresponding to the random access memory address is read and output.

8. The method for setting up an off-chip storage structure for precise matching flow tables according to claim 6, characterized in that, The total capacity of the escape storage area is determined based on the following parameters: The number of flow table groups supported by the chip, the expected number of overflow entries for each flow table group under the preset coverage threshold Pth, and the preset capacity of the linked list area. When the usage rate of the off-chip linked list area corresponding to any flow table group exceeds a preset warning threshold, the hardware triggers the migration of some linked list entries to the escape storage area, or sends an expansion alarm signal to the control plane.

9. A chip, characterized in that, The chip includes: On-chip cache units are used to cache a subset of hot entries in an off-chip hash table; An off-chip storage control unit is used to manage the off-chip hash table in the off-chip storage space, which is divided into a base area and a linked list area. The parameter configuration unit is used to obtain the flow table size parameters, including the total number of flow table entries M to be stored and the number of storage rows N corresponding to the preset index bit width of the off-chip hash table. The calculation unit is used to calculate the average load λ=M / N in each storage row based on the total number of flow table entries M and the number of storage rows N, and to calculate the probability value P(k) of exactly k entries in a single storage row for different non-negative integers k using a probability distribution model based on the average load λ. The slot number determination unit is used to select the minimum k value that makes the cumulative probability reach a preset coverage threshold based on the calculated probability values ​​P(k), and use it as the fixed slot number η of the base area of ​​the off-chip hash table. The storage partitioning unit is used to configure each storage row of the off-chip hash table to contain η fixed slots according to the fixed number of slots η, and to reserve storage space for the linked list area. The off-chip storage control unit also includes: The base area access subunit is used to preferentially store the flow table entry in the n fixed slots of the target storage row when the flow table entry is mapped to the target storage row by a hash operation; The linked list area access subunit is used to allocate a linked list node from the linked list area to store an overflow entry when all η fixed slots of the target storage row are occupied, and to link the linked list node to the overflow linked list of the target storage row.

10. A network interface card (NIC), characterized in that, Includes the chip described in claim 9.

Images