A hard table entry adjustment method, electronic equipment, storage medium and program product

Abstract

Embodiments of the present application provide a hard table entry adjustment method, an electronic device, a storage medium and a program product. The method comprises: in the case of determining that a to-be-added hard table entry is a first type of entry, if the space occupancy rate of the first memory does not exceed a preset occupancy threshold, storing the to-be-added hard table entry in the first memory; in the case of determining that the to-be-added hard table entry is a second type of entry, storing the to-be-added hard table entry in the second memory. By designing first memory priority storage logic for the first type of entry and second memory fixed storage logic for the second type of entry, differentiated allocation of memory resources is realized, laying a foundation for breaking through the number limit of the first type of entry, while ensuring the stability of the storage of the second type of entry.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a method for adjusting hard table entries, electronic devices, storage media, and program products. Background Technology

[0002] In network switching and network security equipment, network chips are the hardware that enables fast data forwarding. They integrate two main types of memory resources: hash memory and tri-state content-addressed memory (TCAM). However, the number of hard table entries in related technologies is limited, resulting in low resource utilization and an inability to meet the device requirements of high-user-volume scenarios. Summary of the Invention

[0003] The purpose of this application is to provide a method for adjusting hard table entries, an electronic device, a storage medium, and a program product, so as to achieve the technical effect of breaking through the limitation on the number of entries and improving resource utilization.

[0004] The first aspect of this application provides a method for adjusting hard table entries. The method is applied to a network chip, which includes a first memory and a second memory, wherein the first memory and the second memory have different hardware resource types. The method includes:

[0005] If the hard table entry to be added is determined to be a first type of entry, and the space occupancy rate of the first memory does not exceed the preset occupancy threshold, then the hard table entry to be added is stored in the first memory.

[0006] If it is determined that the hard table entry to be added is a second type of entry, the hard table entry to be added is stored in the second memory.

[0007] In the above implementation process, by designing a first memory priority storage logic for the first type of table entries and a second memory fixed storage logic for the second type of table entries, the differentiated allocation of memory resources is realized, laying the foundation for breaking through the limitation on the number of first type of table entries, while ensuring the stability of the storage of second type of table entries.

[0008] Furthermore, the method also includes:

[0009] If it is determined that the hard table entry to be added is a first type of entry, and the space occupancy rate of the first memory exceeds the preset occupancy threshold, the hard table entry to be added is stored in the second memory.

[0010] In the above implementation process, the logic of switching to the second memory when the first type of table entry exceeds the threshold is clearly defined, which breaks through the capacity limitation of the first type of table entry relying on only a single memory, significantly improves the maximum number of supported first type of table entries, and avoids the problem that table entries cannot be added due to the first memory being full.

[0011] Furthermore, the method also includes:

[0012] If it is determined that the hard table entry to be added is a third type of entry, the hard table entry to be added is stored in the first memory.

[0013] In the above implementation process, the rule of storing the third type of table entries in the first memory is clearly defined to ensure the stability of the management of the third type of table entries, prevent them from competing with the first type of table entries for the second memory resources, and ensure the orderly allocation of memory resources.

[0014] Furthermore, the preset occupancy threshold is determined based on the total capacity of the first memory; the first memory is hash memory, and the second memory is tri-state content-addressable memory; the first type of entry includes address resolution protocol type entries or neighbor discovery protocol type entries, the second type of entry includes Internet Protocol version 6 routing type entries, and the third type of entry includes Internet Protocol version 4 routing type entries.

[0015] In the above implementation process, it is clearly defined that the first memory is hash memory, the second memory is tri-state content addressing memory, the first type of table entries are Address Resolution Protocol / Neighbor Discovery Protocol table entries, the second type is Internet Protocol version 6 routing table entries, and the third type is Internet Protocol version 4 routing table entries, and the preset occupancy threshold is determined based on the total capacity of the first memory.

[0016] Furthermore, the method also includes:

[0017] Receive table entry deletion command;

[0018] If the target table entry to be deleted is determined to belong to the first type of table entry or the third type of table entry based on the table entry deletion instruction, the target table entry to be deleted is searched from the first memory.

[0019] If the target entry to be deleted is found in the first memory, then the target entry to be deleted is deleted from the first memory.

[0020] If the target entry to be deleted is not found in the first memory, but is found in the second memory, then the target entry to be deleted is deleted from the second memory.

[0021] In the above implementation process, a cross-memory deletion logic is designed for the first and third types of table entries, which first uses the first memory and then the second memory to solve the problem of deletion failure caused by the unknown storage location of the table entry.

[0022] Furthermore, the method also includes:

[0023] If, based on the table entry deletion instruction, it is determined that the target table entry to be deleted belongs to the second type of table entry, and the target table entry to be deleted is found in the second memory, the target table entry to be deleted is deleted from the second memory.

[0024] In the above implementation process, the rule of deleting the second type of table entries from the second memory is clearly defined. This not only conforms to the storage logic of the second type of table entries, but also simplifies the deletion process, ensuring the efficiency and stability of the deletion operation of the second type of table entries.

[0025] Furthermore, the method also includes:

[0026] If it is determined that the space occupancy rate of the first memory exceeds the preset occupancy threshold, a first entry to be deleted belonging to the first type of entry is determined from the first memory;

[0027] If it is determined that the first entry to be deleted was successfully deleted from the first memory, the entry to be added to the hard table is stored in the first memory.

[0028] In the above implementation process, by deleting redundant first-type table entries in the first memory to free up space, newly added first-type table entries can still be preferentially stored in the first memory, thus balancing the storage efficiency of first-type table entries with the efficient utilization of first memory resources.

[0029] Furthermore, the method also includes:

[0030] If it is determined that the first entry to be deleted fails to be deleted from the first memory, a second entry to be deleted belonging to the first type of entry is determined from the second memory;

[0031] If it is determined that the second entry to be deleted was successfully deleted from the second memory, then the entry to be added to the hard table is stored in the second memory.

[0032] In the above implementation process, the logic of deleting redundant entries from the second memory when the deletion of the first entry to be deleted fails further broadens the ways to release memory space, ensuring that even if there are no redundant entries to delete in the first memory, the storage requirements of the newly added entries can still be met by releasing the second memory space.

[0033] Further, storing the hard table entry to be added into the first memory includes:

[0034] The software development kit interface corresponding to the network chip is invoked to write the hard table entry to be added into the first memory;

[0035] The step of storing the hard table entry to be added into the second memory includes:

[0036] The hard table entry to be added is written into the second memory through the software development kit interface.

[0037] In the above implementation process, the specific means of storing table entries in memory is clearly defined, namely, calling the software development kit interface, which ensures that the table entry writing operation conforms to the hardware interaction standard, guarantees the compatibility of the solution in network chips from different manufacturers, and achieves stable writing of table entries through standardized interfaces, avoiding table entry storage anomalies caused by inconsistent hardware interaction methods.

[0038] A second aspect of this application provides an electronic device, the electronic device comprising:

[0039] processor;

[0040] Memory used to store processor-executable instructions;

[0041] Wherein, when the processor invokes the executable instructions, it implements any of the methods described in the first aspect.

[0042] A third aspect of this application provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of any of the methods described in the first aspect.

[0043] A fourth aspect of this application provides a computer program product, the computer program product including a computer program, which, when executed by a processor, implements any of the methods described in the first aspect. Attached Figure Description

[0044] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 A conventional flowchart for adding table entries is provided for embodiments of this application;

[0046] Figure 2 A flowchart illustrating a conventional deletion of a table entry is provided for an embodiment of this application.

[0047] Figure 3 A flowchart for adding table entries is provided as an embodiment of this application;

[0048] Figure 4 A flowchart for deleting a table entry is provided in an embodiment of this application;

[0049] Figure 5A flowchart illustrating a hard table entry adjustment method provided in an embodiment of this application;

[0050] Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0051] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0052] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0053] In network switching and network security equipment, hash memory and Tcam memory are hardware resources that network chips possess simultaneously. (See reference...) Figures 1-2 , Figure 1 This application provides a flowchart of a conventional method for adding table entries. Figure 2 This application provides a flowchart of a conventional table entry deletion process. In related technologies, the allocation of space for hard table entries such as ARP and ND stored in the network chip is a single choice, such as specifying the use of Hash memory space or specifying the use of Tcam memory space. Routing hard table entries are specified to use Tcam memory space. In related technologies, the hard table resources used by ARP and ND are Hash memory, but in fact, Tcam resources can also be used for ARP and ND. Therefore, related technologies limit the maximum increase in the number of ARP and ND entries. When the number is large, it may cause the device to be unable to meet the demand.

[0054] For any of the questions raised above, refer to Figures 3-4 , Figure 3 This application provides a flowchart for adding table entries. Figure 4This application provides a flowchart for deleting entries. Based on the chip memory resource configuration, ARP and ND entries support the use of Hash memory and Tcam memory, automatically determining the type of operation being processed. When adding an entry, Hash resources are used first. When Hash resource usage reaches the designed reasonable upper limit, Hash memory usage stops, and Tcam resources are used for this operation. When deleting an entry, deletion is first attempted from Hash resources; if this fails, deletion is then attempted from Tcam resources. If this also fails, the entry is returned as not existing. This implementation ensures better performance when the number of ARP and ND users increases. According to the technical solution of this application, the number of hard table entries for ARP and ND is expanded from N entries using Hash resources to N+M entries after adding M entries using Tcam resources.

[0055] Based on this, the embodiments of this application provide a method for adjusting hard table entries, referring to... Figure 5 , Figure 5 This is a flowchart illustrating a method for adjusting hard table entries provided in an embodiment of this application.

[0056] In this embodiment, the method is applied to a network chip, which includes a first memory and a second memory, the first memory and the second memory having different hardware resource types; the method includes:

[0057] Step S10: If it is determined that the hard table entry to be added is a first type of entry, and if the space occupancy rate of the first memory does not exceed the preset occupancy threshold, then the hard table entry to be added is stored in the first memory.

[0058] It should be noted that hard table entries refer to the hardware-level forwarding rule storage units in network chips, including ARP entries, ND entries, IPv4 routing table entries, IPv6 routing table entries, etc.

[0059] A network chip is a hardware chip that integrates data forwarding and memory management functions, and has two different types of memory built in: primary memory and secondary memory.

[0060] Optionally, the first memory refers to a storage unit with a hardware resource type of hash memory, characterized by fast read / write speed and low cost.

[0061] The first type of table entry refers to a hard table entry that requires dynamic memory allocation. Optionally, the first type of table entry includes ARP table entries (stores IP and MAC address mappings) and ND table entries (IPv6 network node address discovery).

[0062] Optionally, the space utilization rate refers to the ratio of the number of currently stored entries (or occupied space) in the first memory to the total capacity, which is used to measure the utilization status of the first memory resources (e.g., if the total capacity is 1000 entries and 800 entries are stored, the utilization rate is 80%).

[0063] The preset occupancy threshold refers to the pre-set upper limit of the first memory space occupancy rate (such as 80%), which is the critical value that triggers the switching of the first type of table entry to the second memory.

[0064] As an example, the method is applied to a network chip that includes a first memory (Hash memory, total capacity 1000 entries) and a second memory (TCAM memory, total capacity 2000 entries), with different hardware resource types (Hash is based on a hash algorithm, and TCAM is based on parallel lookup). Assuming the entry to be added is an ARP entry (belonging to the first type of entry), the space occupancy rate of the first memory is first calculated: if 700 entries are currently stored, the occupancy rate is 70%; if the occupancy rate does not exceed a preset occupancy threshold (e.g., 80%), then the ARP entry is stored in the first memory.

[0065] Step S20: If it is determined that the hard table entry to be added is a second type of entry, the hard table entry to be added is stored in the second memory.

[0066] It should be noted that the second type of table entry refers to a hard table entry that uses the second memory. Optionally, the second type of table entry includes IPv6 routing table entries (which store IPv6 routing and forwarding rules).

[0067] Optionally, the second memory refers to a storage unit with a hardware resource type of tri-state content-addressable memory (TCAM), characterized by supporting parallel lookups and having a large capacity.

[0068] As an example, suppose the entry to be added is an IPv6 routing table entry (belonging to the second type of entry). Regardless of the second memory usage rate, it is directly stored in the second memory.

[0069] In this embodiment, by designing a first memory priority storage logic for the first type of entries and a second memory fixed storage logic for the second type of entries, differentiated allocation of memory resources is achieved, laying the foundation for overcoming the limitation on the number of first type of entries, while ensuring the stability of the storage of second type of entries.

[0070] Based on any of the above embodiments, the method further includes:

[0071] If it is determined that the hard table entry to be added is a first type of entry, and the space occupancy rate of the first memory exceeds the preset occupancy threshold, the hard table entry to be added is stored in the second memory.

[0072] As an example, if the table entry to be added is a first-type table entry (such as an ND table entry), calculate the first memory space occupancy rate: if 850 entries have already been stored (total capacity 1000 entries), the occupancy rate is 85%, exceeding the preset threshold of 80%; at this time, the ND table entry will no longer be stored in the first memory, but will be switched to the second memory (TCAM) to complete the storage operation, so as to avoid the problem of table entries not being able to be added due to the Hash memory being full.

[0073] In this embodiment, the logic of switching from the first type of table entry to the second memory when the first memory exceeds the threshold is clearly defined, which breaks through the capacity limitation of the first type of table entry relying on only a single memory, significantly increases the maximum number of supported first type of table entries, and avoids the problem that table entries cannot be added due to the first memory being full.

[0074] Based on any of the above embodiments, the method further includes:

[0075] If it is determined that the hard table entry to be added is a third type of entry, the hard table entry to be added is stored in the first memory.

[0076] Optionally, the third type of entry refers to a hard table entry that uses the first memory. The third type of entry includes IPv4 routing table entries (which store IPv4 routing and forwarding rules).

[0077] It should be noted that the third type of entry uses hash memory by default. The difference between the third type and the first type is that the third type does not require dynamic memory checks. That is, regardless of the space occupancy rate of the first memory, the IPv4 routing table entry is directly stored in the first memory.

[0078] In this embodiment, the rule of storing the third type of entries in the first memory is clearly defined to ensure the stability of the management of the third type of entries, prevent them from competing with the first type of entries for the second memory resources, and ensure the orderly allocation of memory resources.

[0079] Based on any of the above embodiments, the preset occupancy threshold is determined based on the total capacity of the first memory; the first memory is hash memory, the second memory is tri-state content-addressable memory; the first type of entry includes address resolution protocol type entries or neighbor discovery protocol type entries, the second type of entry includes Internet Protocol version 6 routing type entries, and the third type of entry includes Internet Protocol version 4 routing type entries.

[0080] Optionally, the preset occupancy threshold is set based on the total capacity of the first memory, and can be determined in the following two ways:

[0081] Set a fixed number: for example, if the total memory capacity is 1000, set the threshold to 800.

[0082] Set proportionally: For example, if the total capacity of the first memory is 1000 entries, the threshold is set to 80% of the total capacity (i.e., 800 entries).

[0083] It should be noted that Hash memory is Hash memory, Tri-state Content Addressing memory is Tcam memory, Address Resolution Protocol Type Entry is ARP entry, Neighbor Discovery Protocol Type Entry is ND entry, Internet Protocol Version 6 Routing Type Entry is IPv6 routing entry, and Internet Protocol Version 4 Routing Type Entry is IPv4 routing entry.

[0084] In this embodiment, the first memory is defined as hash memory, the second memory as tri-state content addressing memory, the first type of table entries are Address Resolution Protocol / Neighbor Discovery Protocol entries, the second type are Internet Protocol version 6 routing table entries, and the third type are Internet Protocol version 4 routing table entries. The preset occupancy threshold is determined based on the total capacity of the first memory.

[0085] Based on any of the above embodiments, the method further includes:

[0086] Receive table entry deletion command;

[0087] If the target table entry to be deleted is determined to belong to the first type of table entry or the third type of table entry based on the table entry deletion instruction, the target table entry to be deleted is searched from the first memory.

[0088] If the target entry to be deleted is found in the first memory, then the target entry to be deleted is deleted from the first memory.

[0089] If the target entry to be deleted is not found in the first memory, but is found in the second memory, then the target entry to be deleted is deleted from the second memory.

[0090] It should be noted that the target entry to be deleted can be a single entry or multiple entries. The sources of the target entries to be deleted can include the following two categories: first, the hard table entries to be added that belong to the first or third category of entries mentioned in the above embodiments (i.e., newly added entries that have completed storage operations); second, existing entries that have been stored in the first or second memory in the past (such as ARP entries, IPv4 routing entries, etc. that were created and stored during the early operation of the device). The above search and deletion logic applies to entries from both categories.

[0091] The table entry deletion command must carry at least a unique identifier for the target table entry to be deleted (e.g., the IP address corresponding to an ARP entry, the IPv6 address corresponding to an ND entry, or the routing network segment corresponding to a Type 3 entry, such as an IPv4 routing table entry); this command exists in the following two forms:

[0092] Format 1: Only carries the unique identifier of the target table entry to be deleted, without carrying table entry type information;

[0093] Format 2: Simultaneously carry the unique identifier of the target entry to be deleted and the corresponding entry type identifier (such as ARP type, IPv4 routing type).

[0094] Based on the form of the table entry deletion command, the category of the target table entry to be deleted is determined using the following methods (primarily determining whether it is a Category 1 or Category 3 table entry):

[0095] If the instruction is of form two (i.e. carrying a type identifier): the entry category is determined directly based on the type identifier. For example, if the identifier is ARP or ND, it belongs to the first type of entry; if the identifier is IPv4 route, it belongs to the third type of entry.

[0096] If the instruction is of form one (i.e. without a type identifier): call the network chip's table of table attributes (this table pre-records the correspondence between the unique identifiers and types of all stored table entries), and match the unique identifier of the target table entry to be deleted against the index table to determine whether it belongs to the first type or the third type of table entry.

[0097] Based on the judgment result, the operation is performed following the logic of prioritizing the first memory location and then distinguishing whether to check the second memory location based on the category, as follows:

[0098] (1) Uniform priority search of the first memory:

[0099] Regardless of whether the target entry to be deleted belongs to the first or third category, the software development kit interface corresponding to the network chip is first invoked to search for the entry in the first memory (i.e., hash memory) based on the entry's unique identifier.

[0100] If the target entry to be deleted is found in the first memory: the entry is deleted directly from the first memory through the software development kit interface, and the resource usage record of the first memory (such as the number of stored entries, remaining capacity, etc.) is updated synchronously, and the deletion process is terminated;

[0101] If the target entry to be deleted is not found in the first memory location: perform subsequent operations according to the differences in entry categories.

[0102] (2) Differentiate whether to search for the second memory based on the category of the table entry:

[0103] Scenario 1: The target table entry to be deleted belongs to the first category of table entries:

[0104] Because the memory usage rule for the first type of entry is that it can dynamically use either the first memory or the second memory (that is, when the first memory exceeds the preset usage threshold, it will be stored in the second memory), it is necessary to further call the software development kit interface to look up the entry in the second memory:

[0105] If the entry is found in the second memory: delete the entry from the second memory via the interface, and the deletion process terminates;

[0106] If the entry is not found in the second memory: return a result indicating that the entry does not exist, and the deletion process terminates.

[0107] Scenario 2: The target table entry to be deleted belongs to the third category of table entries:

[0108] Since the memory usage rule for the third type of table entries is to always use the first memory, and the second memory of the network chip never stores the third type of table entries (such as IPv4 routing table entries), there is no need to perform a lookup operation in the second memory. The result that the table entry does not exist is returned directly, and the deletion process terminates.

[0109] In this embodiment, a cross-memory deletion logic is designed for the first and third types of table entries, first in the first memory and then in the second memory, to solve the problem of deletion failure caused by the unknown storage location of the table entry.

[0110] Based on any of the above embodiments, the method further includes:

[0111] If, based on the table entry deletion instruction, it is determined that the target table entry to be deleted belongs to the second type of table entry, and the target table entry to be deleted is found in the second memory, the target table entry to be deleted is deleted from the second memory.

[0112] It should be noted that the second type of table entry is permanently stored in the second memory and does not need to be searched in the first memory. If it is found, the SDK interface is called to delete it.

[0113] As an example, when receiving a deletion command, if the entry to be deleted is a second-type entry, such as an IPv6 routing table entry, the system directly searches for the IPv6 routing table entry in the second memory. If found, the SDK interface is called to delete it; if not found, the system returns that the entry does not exist.

[0114] In this embodiment, the rule that the second type of table entries are always deleted from the second memory is clearly defined. This not only conforms to the storage logic of the second type of table entries, but also simplifies the deletion process, ensuring the efficiency and stability of the deletion operation of the second type of table entries.

[0115] Based on any of the above embodiments, the method further includes:

[0116] If it is determined that the space occupancy rate of the first memory exceeds the preset occupancy threshold, a first entry to be deleted belonging to the first type of entry is determined from the first memory;

[0117] If it is determined that the first entry to be deleted was successfully deleted from the first memory, the entry to be added to the hard table is stored in the first memory.

[0118] It should be noted that this embodiment is for a scenario where the first memory exceeds the threshold but the first type of table entries need to be stored first.

[0119] As an example, the first type of table entry to be added, such as an ARP table entry, has a memory space utilization rate of 85% (exceeding the 80% threshold).

[0120] Filter the first entries to be deleted from the first memory: select the first type of inactive / expired entries, such as ARP entries that have not been updated for 1 hour;

[0121] Call the SDK interface to delete the first entry to be deleted: If the deletion is successful (the first memory usage drops to 82%, still exceeding the threshold but freeing up space), then the newly added ARP entry will be stored in the first memory.

[0122] In this embodiment, by deleting redundant first-type entries in the first memory to free up space, newly added first-type entries can still be preferentially stored in the first memory, thus balancing the storage efficiency of first-type entries with the efficient utilization of first memory resources.

[0123] Based on any of the above embodiments, the method further includes:

[0124] If it is determined that the first entry to be deleted fails to be deleted from the first memory, a second entry to be deleted belonging to the first type of entry is determined from the second memory;

[0125] If it is determined that the second entry to be deleted was successfully deleted from the second memory, then the entry to be added to the hard table is stored in the second memory.

[0126] As an example, if the first entry to be deleted fails to be deleted from the first memory, such as because the active ARP entry cannot be deleted, or because the first memory does not contain the first entry to be deleted which belongs to the first type of entry, the deletion will fail.

[0127] Filter the second list of entries to be deleted from the second memory: select inactive / expired first-category entries, such as ND entries stored in TCAM;

[0128] Call the SDK interface to delete the second entry to be deleted: If the deletion is successful (TCAM frees up space), the newly added first type of entry (such as an ARP entry) will be stored in the second memory.

[0129] In this embodiment, the logic of deleting redundant entries from the second memory when the deletion of the first entry to be deleted fails further broadens the ways to release memory space, ensuring that even if there are no redundant entries to delete in the first memory, the storage requirements of the newly added entries can still be met by releasing the second memory space.

[0130] Based on any of the above embodiments, storing the hard table entry to be added into the first memory includes:

[0131] The software development kit interface corresponding to the network chip is invoked to write the hard table entry to be added into the first memory;

[0132] The step of storing the hard table entry to be added into the second memory includes:

[0133] The hard table entry to be added is written into the second memory through the software development kit interface.

[0134] It should be noted that the Software Development Kit (SDK) interface refers to the standardized hardware interaction interface provided by network chip manufacturers, which is used to implement write / delete operations on table entries.

[0135] Specifically, storing in the first memory (Hash): call the network chip SDK's Hash memory write interface (such as hash_mem_write()), pass in the parameters of the entry to be added (such as the IP and MAC addresses of the ARP entry), and the interface will write the entry to the specified address of the Hash memory;

[0136] Store in the second memory (TCAM): Call the SDK's TCAM memory write interface (such as tcam_mem_write()), pass in the parameters of the entry to be added (such as the network segment and next hop of the IPv6 routing table entry), and the interface will write the entry to the specified address of the TCAM.

[0137] In addition, the embodiments of this application also provide the following two alternative solutions:

[0138] I. Alternative Solution 1: Implement dynamic storage logic for hard table entries at the SDK layer:

[0139] (a) The idea behind alternative solution 1:

[0140] The core of Alternative Solution 1 is to embed the judgment and operation logic of dynamically allocating table entry storage locations based on memory resource status mentioned in the above embodiments into the table entry management core function of the network chip software development kit (SDK). By modifying the internal implementation of the SDK rather than the driver layer, the dual memory utilization of Hash memory and TCAM memory of ARP / ND hard table entries is achieved, ultimately increasing the maximum value of the table entries.

[0141] (ii) Exemplary implementation steps:

[0142] 1. Modification of core functions in the SDK layer:

[0143] The basic functions in the SDK responsible for adding and deleting hard table entries have been modified, and dynamic memory judgment logic has been added. Taking the common SDK functions add_hard_entry() (add hard table entry function) and delete_hard_entry() (delete hard table entry function) as examples:

[0144] (1) Modify the add_hard_entry() function (add process to corresponding table entries):

[0145] Parameter reception and preprocessing: The function receives key parameters of the entries to be added, including the entry type (such as ARP, ND, IPv6 routing, IPv4 routing) and the specific data of the entry (such as the IP address and MAC address of the ARP entry; the network segment and next hop of the IPv6 routing entry).

[0146] Added entry type judgment branch: Added entry type judgment logic inside the function, focusing on dynamic memory allocation branch for ARP / ND entries (first type of entry):

[0147] If the table entry type is ARP or ND: call the get_hash_memory_usage() interface newly added inside the SDK to get the current space occupancy rate of the first memory (Hash memory) (e.g., by reading the Hash memory controller register to calculate the ratio of the number of stored table entries to the total capacity).

[0148] If the Hash memory space occupancy rate does not exceed the preset threshold (e.g., 80%): directly call the SDK's original Hash memory write interface hash_mem_write() to write the ARP / ND table entries to the Hash memory, and update the Hash memory resource occupancy record maintained internally by the SDK (e.g., the number of used entries and the remaining capacity) through the update_hash_memory_record() interface.

[0149] If the Hash memory space occupancy rate exceeds the preset threshold: call the SDK's original TCAM memory write interface tcam_mem_write() to write the ARP / ND table entry to the second memory (TCAM memory), and at the same time record the storage address and type of the table entry in the newly added tcam_arp_nd_record linked list inside the SDK for subsequent deletion and lookup;

[0150] If the entry type is IPv6 routing: follow the original logic and directly call the tcam_mem_write() interface to write to TCAM memory;

[0151] If the table entry type is IPv4 routing: follow the original logic and directly call the hash_mem_write() interface to write to the Hash memory;

[0152] If the field type is invalid input: return "Parameter error" message and terminate function execution.

[0153] Return result processing: The function returns a table entry with a success / failure status to the caller (such as the driver layer or upper-layer protocol). If successful, it synchronously returns the memory type and address where the table entry is stored.

[0154] (2) Modification of the delete_hard_entry() function (corresponding to the table entry deletion process):

[0155] Parameter reception and preprocessing: The function receives key parameters of the entries to be deleted, including the entry type and entry identifier (such as the IP address of ARP entries and the IPv6 address of ND entries).

[0156] Adding a new branch for ARP / ND table entry deletion: Design cross-memory lookup and deletion logic for ARP / ND table entries.

[0157] If the entry type is ARP or ND: First, query the hash_memory_record linked list maintained internally by the SDK to determine whether the entry is stored in hash memory;

[0158] If the entry is found in the Hash memory: call the hash_mem_delete() interface to delete the entry, update the hash_memory_record record, and return a success message for deletion;

[0159] If not found in Hash memory: query the newly added tcam_arp_nd_record linked list in the SDK to determine whether the entry is stored in TCAM memory;

[0160] If the entry is found in TCAM memory: call the tcam_mem_delete() interface to delete the entry, update the tcam_arp_nd_record record, and return a success message for deletion;

[0161] If the entry is not found in either of the two memory locations, a "table entry not found" message will be returned.

[0162] If the table entry type is IPv6 route / IPv4 route: follow the original logic and search and delete according to the fixed memory type.

[0163] 2. SDK interface compatibility handling:

[0164] To ensure that existing callers (such as older drivers and upper-layer protocols) are not affected, the SDK must maintain the same parameter and return value formats for its external interfaces, modifying only the internal implementation logic. For example, the function names, parameter lists, and return value types of add_hard_entry() and delete_hard_entry() should remain the same as before the modification, allowing callers to adapt without modifying their code.

[0165] (iii) Deficiencies of Alternative Solution 1:

[0166] This challenges the simplicity of SDK software packages. Specifically, the essential role of an SDK is to provide a standardized hardware interaction interface, only responsible for translating upper-layer instructions into hardware-recognizable operations (such as memory read / write and register configuration), without undertaking business logic decisions (such as dynamically determining the storage location of table entries).

[0167] Alternative solution 1 embeds business logic for matching table entry types and memory resources in the SDK, causing the SDK to change from a simple interface encapsulation layer to an interface + business logic layer, blurring the functional boundaries.

[0168] In subsequent maintenance, if it is necessary to adjust the memory allocation threshold or add new table entry types, the SDK core functions need to be modified, which may cause compatibility issues between the SDK and different callers (such as drivers and protocols from different manufacturers), and increase the testing complexity of the SDK (it needs to cover both business logic and hardware interface scenarios).

[0169] 2. Alternative Solution 2: Implement dynamic storage logic for hard table entries at the upper protocol layer:

[0170] (a) The idea behind alternative solution 2:

[0171] The core of Alternative Solution 2 is to embed the dynamic memory allocation judgment logic into the table entry processing flow of the upper-layer protocol module (such as the ARP protocol module, ND protocol module, and routing protocol module). The upper-layer protocol directly decides the storage memory type of the ARP / ND table entry, and then completes the table entry writing / deletion by calling the lower-layer interface (such as the SDK interface and driver interface), thereby breaking through the table entry limit of a single memory.

[0172] (ii) Exemplary implementation steps:

[0173] Taking the ARP protocol module (responsible for ARP entry management) and the ND protocol module (responsible for ND entry management) in the upper-layer protocol as examples, the modification details include:

[0174] 1. ARP protocol module modification (adding / deleting corresponding ARP table entries):

[0175] (1) ARP entry addition process modification:

[0176] ARP entry generation trigger: When the ARP protocol module obtains a new IP-MAC mapping relationship through ARP request / response packets, it triggers the ARP entry addition process to generate ARP entry data to be added (including source IP, source MAC, aging time, etc.).

[0177] Memory resource status query: The ARP protocol module calls the underlying memory resource query interface (such as through the ioctl interface exposed by the driver, or directly calls the SDK's get_hash_memory_usage() interface) to obtain the current space occupancy rate of Hash memory;

[0178] Storage memory decision and execution:

[0179] If the Hash memory usage does not exceed the preset threshold: the ARP protocol module calls the SDK's hash_mem_write() interface to write the ARP entry into the Hash memory, and records the IP, MAC and storage address of the entry in the arp_hash_list linked list maintained inside the module;

[0180] If the Hash memory usage exceeds the preset threshold: the ARP protocol module calls the SDK's tcam_mem_write() interface to write the ARP entry into the TCAM memory, and records the entry information in the newly added arp_tcam_list linked list inside the module (for subsequent deletion and lookup).

[0181] Entry Synchronization and Aging Management: The ARP protocol module synchronizes the storage location (Hash / TCAM) of newly added entries to the entry aging timer within the module. During subsequent aging judgment, the corresponding interface needs to be called to delete the entry based on the storage location.

[0182] (2) Modification of ARP entry deletion process:

[0183] ARP entry deletion trigger: The ARP entry deletion process is triggered when an ARP entry becomes old or when an ARP clearing command is received (such as user configuration deletion or interface down event).

[0184] Cross-memory search and delete:

[0185] The ARP protocol module first traverses the internal arp_hash_list linked list and looks up the corresponding entry record based on the IP address of the entry to be deleted.

[0186] If a record is found (the entry is stored in Hash memory): call the hash_mem_delete() interface to delete the entry, remove the record from arp_hash_list, and update the Hash memory ARP entry count in the module;

[0187] If no record is found: Traverse the internal arp_tcam_list linked list to find the entry to be deleted;

[0188] If a record is found (the entry is stored in TCAM memory): call the tcam_mem_delete() interface to delete the entry and remove the record from arp_tcam_list;

[0189] If the entry is not found in either of the two linked lists, the system returns an "ARP entry does not exist" message.

[0190] 2. Modification of the ND protocol module (addition / deletion of corresponding ND table entries):

[0191] The modification logic for the ND protocol module is completely consistent with that for the ARP protocol module:

[0192] When adding a new ND table entry, first query the Hash memory usage rate, dynamically select Hash / TCAM memory storage, and maintain nd_hash_list and nd_tcam_list records respectively;

[0193] When deleting an entry in the ND table, first look up nd_hash_list, then look up nd_tcam_list, completing the deletion operation across memory.

[0194] 3. Routing protocol module adaptation (corresponding to IPv4 / IPv6 routing table entries):

[0195] The IPv6 routing protocol module continues to use the original logic, directly calling tcam_mem_write() to write to TCAM when adding a new IPv6 routing table entry; the IPv4 routing protocol module directly calls hash_mem_write() to write to Hash memory when adding a new IPv4 routing table entry, without any additional modifications, to ensure the stability of the original functions.

[0196] (iii) Deficiencies of Alternative Solution 2:

[0197] This disrupts the standardization of upper-layer protocol software. Specifically, the essential role of upper-layer protocols (such as ARP and ND protocols) is to implement network protocol specifications. For example, the ARP protocol is only responsible for the resolution and interaction of IP and MAC addresses, and the ND protocol is only responsible for neighbor discovery and address configuration in IPv6 networks, without taking on the responsibility of hardware memory resource management.

[0198] Alternative solution 2 embeds hardware-related logic such as memory usage judgment and cross-memory storage decision into the protocol module, causing the protocol module to change from a pure protocol logic layer to a protocol logic + hardware resource management layer, which deviates from the design boundaries of standard protocols such as TCP / IP.

[0199] Upper-layer protocol modules from different manufacturers typically need to follow unified industry standards (such as RFC826 for ARP and RFC4861 for ND). The modification of alternative solution 2 will result in non-standardized protocol modules, making it difficult to be compatible with hardware / software from other manufacturers, and will also increase the maintenance difficulty of the protocol modules (it is necessary to adapt to the memory characteristics of different hardware simultaneously).

[0200] III. The main features of the original solution (i.e., the solution that implements dynamic memory allocation logic in the driver layer) composed of the above embodiments and this embodiment compared to alternative solutions 1 and 2 are as follows:

[0201] (1) Clear functional boundaries, without disrupting the existing architecture:

[0202] The driver layer is essentially positioned as an intermediate adaptation layer between hardware and software. It is responsible for converting upper-layer instructions (such as table operation requests from protocol modules) into hardware-executable operations, and also has hardware resource management capabilities (such as monitoring the status of memory and registers).

[0203] Adding hardware resource configuration judgment (Hash memory usage judgment) and memory usage and release management (Hash resource record update and cross-memory deletion coordination) to the driver layer fully complies with the functional responsibilities of the driver layer. It does not undermine the positioning of the SDK as a simple interface layer, nor does it disrupt the positioning of the upper-layer protocol standard logic layer, thus ensuring the clarity and compatibility of the entire system architecture.

[0204] (2) Resources are fully utilized and managed in a unified manner:

[0205] The driver layer can directly access the hardware controller of the network chip to obtain the resource status of Hash memory and TCAM memory in real time and accurately (such as by reading the status register of the memory controller to obtain the actual space occupancy rate, rather than relying on indirect calculations by the SDK or protocol module).

[0206] Based on real-time resource status, the driver layer can uniformly schedule two types of memory resources, ensuring that ARP / ND entries use Hash first when Hash memory is not full (while taking into account read and write efficiency), and automatically switch to TCAM when Hash memory is full (to avoid the inability to add entries), thus achieving full utilization of all available resources (Hash + TCAM).

[0207] (3) High compatibility and high portability:

[0208] The driver layer provides standardized interfaces (such as a unified interface for adding / deleting entries) to the upper-layer protocol modules and SDK, which can be called without any modification to the upper-layer protocol and SDK, ensuring compatibility with the existing software ecosystem;

[0209] If the network chip hardware is replaced in the future, only the memory state acquisition interface of the driver layer needs to be modified (such as adapting the register address to the new chip), without modifying the upper layer protocol or SDK. The portability is significantly better than the two alternative solutions.

[0210] In this embodiment, the specific implementation method for storing table entries in memory is clearly defined, namely, calling the software development kit interface, which ensures that the table entry writing operation conforms to the hardware interaction standard, guarantees the compatibility of the solution in network chips from different manufacturers, and achieves stable writing of table entries through standardized interfaces, avoiding table entry storage anomalies caused by inconsistent hardware interaction methods.

[0211] Based on the methods described in any of the above embodiments, this application also provides, as follows: Figure 6 The diagram shows the structure of an electronic device. Figure 6 At the hardware level, the electronic device includes a processor, an internal bus, a network interface, memory, and non-volatile memory, and may also include other hardware required for business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to implement the methods described in any of the above embodiments.

[0212] Based on the methods described in any of the above embodiments, this application also provides a computer storage medium storing a computer program, which, when executed by a processor, can be used to perform the methods described in any of the above embodiments.

[0213] Based on the methods described in any of the above embodiments, this application also provides a computer program product, which includes one or more computer programs or instructions. The computer program or instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. When executed by a processor, the computer program implements the methods described in any of the above embodiments.

[0214] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0215] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0216] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0217] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0218] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0219] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A method for adjusting hard table entries, characterized in that, The method is applied to a network chip, which includes a first memory and a second memory, the first memory and the second memory having different hardware resource types; the method includes: If the hard table entry to be added is determined to be a first type of entry, and the space occupancy rate of the first memory does not exceed the preset occupancy threshold, then the hard table entry to be added is stored in the first memory. If it is determined that the hard table entry to be added is a second type of entry, the hard table entry to be added is stored in the second memory. If it is determined that the hard table entry to be added is a first type of entry, and the space occupancy rate of the first memory exceeds the preset occupancy threshold, the hard table entry to be added is stored in the second memory. If it is determined that the hard table entry to be added is a third type of entry, the hard table entry to be added is stored in the first memory. The preset occupancy threshold is determined based on the total capacity of the first memory; the first memory is hash memory, and the second memory is tri-state content-addressable memory; the first type of entry includes address resolution protocol type entries or neighbor discovery protocol type entries, the second type of entry includes Internet Protocol version 6 routing type entries, and the third type of entry includes Internet Protocol version 4 routing type entries.

2. The method according to claim 1, characterized in that, The method further includes: Receive table entry deletion command; If, based on the table entry deletion instruction, it is determined that the target table entry to be deleted belongs to the first type of table entry or the third type of table entry, the target table entry to be deleted is searched from the first memory. If the target entry to be deleted is found in the first memory, then the target entry to be deleted is deleted from the first memory. If the target entry to be deleted is not found in the first memory, but is found in the second memory, then the target entry to be deleted is deleted from the second memory.

3. The method according to claim 2, characterized in that, The method further includes: If, based on the table entry deletion instruction, it is determined that the target table entry to be deleted belongs to the second type of table entry, and the target table entry to be deleted is found in the second memory, the target table entry to be deleted is deleted from the second memory.

4. The method according to claim 1, characterized in that, The method further includes: If it is determined that the space occupancy rate of the first memory exceeds the preset occupancy threshold, a first entry to be deleted belonging to the first type of entry is determined from the first memory; If it is determined that the first entry to be deleted was successfully deleted from the first memory, the entry to be added to the hard table is stored in the first memory.

5. The method according to claim 4, characterized in that, The method further includes: If it is determined that the first entry to be deleted fails to be deleted from the first memory, a second entry to be deleted belonging to the first type of entry is determined from the second memory; If it is determined that the second entry to be deleted was successfully deleted from the second memory, then the entry to be added to the hard table is stored in the second memory.

6. The method according to claim 1, characterized in that, The step of storing the hard table entry to be added into the first memory includes: The software development kit interface corresponding to the network chip is invoked to write the hard table entry to be added into the first memory; The step of storing the hard table entry to be added into the second memory includes: The hard table entry to be added is written into the second memory through the software development kit interface.

7. An electronic device, characterized in that, The electronic device includes: processor; Memory used to store processor-executable instructions; Wherein, when the processor invokes the executable instructions, it implements the method according to any one of claims 1-6.

8. A computer-readable storage medium, characterized in that, It stores computer instructions that, when executed by a processor, implement the steps of any of the methods described in claims 1-6.

9. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-6.

Images