Implementation method for parallel issuing of forwarding table entries of multi-chip equipment

Abstract

The invention discloses an implementation method for parallel issuing of forwarding table entries of multi-chip equipment, relates to the technical field of the forwarding table entries of the multi-chip equipment, and solves the technical problems that although the table entry issuing efficiency is improved to a certain extent in the prior art, the issuing efficiency and the feedback mechanism are obviously insufficient. The method comprises the following steps: issuing a table item to a driving module through a protocol module; after receiving the table item, the driving module issues the table item to the first chip for processing; the issuing result of the driving module is returned to the protocol module, and whether the protocol module continues to issue the next table item or not is judged based on the issuing result; judging whether the driving module writes the table item into the shared queue or not based on the issuing result; creating an independent task thread for each of the remaining chips based on a driving module, and taking out table items from the shared queue to perform parallel issuing operation; and judging whether the abnormal table item is processed or not based on the result of the parallel issuing operation. The technical problem is solved.

Description

Technical Field

[0001] The invention belongs to the field of multi-chip device forwarding table entries, and in particular is a method for implementing parallel issuance of multi-chip device forwarding table entries. Background Art

[0002] Routing, ARP, MPLS and other forwarding table entries are generally issued globally on network devices, that is, they must be issued once to each forwarding chip on all interface boards of the network device. When there are a large number of forwarding table entries, when triggering protection switching or path switching, all relevant forwarding table entries need to be refreshed. At this time, the interruption time and the number of packet losses are required to be as small as possible. This switching performance is an important basis for measuring the performance indicators of a device. For example, MPLS path switching requires all related table entries to be refreshed. The MPLS protocol module in the software stack sends table entries to the driver module one by one in order. When the driver module processes each table entry, it must poll each forwarding chip on the interface board. Only after all items are sent can they be returned to the MPLS module, and the MPLS module can then send the next table entry; this method of sending each chip in sequence will seriously affect the switching performance when there are a large number of chips on the interface board.

[0003] The existing solution is to make the forwarding table entry asynchronous, and after the protocol module sends an entry, it directly sends the next entry without waiting; after the driver module processes an entry in its own task thread, it notifies the protocol module of the sending status (Success or Failed); although the asynchronous sending method improves the sending efficiency to a certain extent, it also brings some new problems. In particular, the protocol module needs to judge the next action according to the result returned by this sending in some cases. For example, MPLS path switching requires all related entries to be refreshed. Under asynchronous operation, the upper layer protocol does not wait for the sending result, and will refresh all the entries at once, and think that all the sending is successful. However, due to hardware resource limitations, the sending may actually fail from somewhere; this leads to inconsistent errors in the upper and lower layer entries, so it is necessary to check and roll back these operations, causing unnecessary confusion and performance loss; in summary, the existing technology has obvious deficiencies in sending efficiency and feedback mechanism, and it is difficult to meet the requirements of high-performance network equipment.

[0004] Therefore, the present invention solves the above problem by proposing a method for implementing parallel delivery of forwarding table entries of multi-chip devices. Summary of the invention

[0005] The present invention aims to solve at least one of the technical problems existing in the prior art; to this end, the present invention proposes a method for implementing parallel delivery of multi-chip device forwarding table items, which is used to solve the problem that although the prior art improves the delivery efficiency to a certain extent compared with the traditional delivery of forwarding table items, it also brings some new problems, especially that the protocol module needs to judge the next action according to the result returned by the current delivery in some cases, for example, MPLS path switching requires all related table items to be refreshed, and under asynchronous operation, the upper layer protocol does not wait for the delivery result, and will refresh all the table items at once, and think that all the delivery is successful, but due to hardware resource limitations, the actual delivery may fail from somewhere, resulting in inconsistent errors in the upper and lower layer table items, so that these operations need to be checked and rolled back, causing unnecessary confusion and performance loss.

[0006] To achieve the above object, a first aspect of the present invention provides a method for implementing parallel delivery of forwarding table entries of a multi-chip device, comprising:

[0007] Step 1: Send a table entry to the driver module through the protocol module;

[0008] Step 2: After receiving the table entry, the driver module sends the table entry to the first chip for processing;

[0009] Step 3: Return the delivery result of the driver module to the protocol module, and determine whether the protocol module continues to deliver the next table entry based on the delivery result; and determine whether the driver module writes the table entry into the shared queue based on the delivery result;

[0010] Step 4: Create a separate task thread for each remaining chip based on the driver module, and take out the table items from the shared queue for parallel distribution operations;

[0011] Step 5: Determine whether to process the abnormal entry based on the result of the parallel delivery operation.

[0012] Preferably, sending a table entry to the driver module through the protocol module includes:

[0013] A1: The protocol module generates forwarding table entries to be sent according to the network protocol; the network protocol includes: routing protocol, ARP protocol or MPLS protocol, etc.;

[0014] A2: Encapsulate the generated table entries based on the protocol module;

[0015] A3: Call the API interface provided by the driver module and send the encapsulated table items to the driver module.

[0016] It should be noted that the protocol module is a software component in the network device that is responsible for processing various network protocols (such as routing protocols, ARP protocols, MPLS protocols, etc.). It is responsible for generating and managing forwarding table entries and sending these table entries to the hardware level;

[0017] The driver module is a software component in the network device that is responsible for interacting with the hardware. It receives forwarding table entries from the protocol module and writes these table entries into each chip. Among them, the chip is a hardware component in the network device that is responsible for data forwarding. In the network device, an interface board usually contains multiple chips, and each chip is responsible for a part of the data forwarding task.

[0018] Preferably, judging whether the protocol module continues to send the next table entry based on the sending result includes:

[0019] B1: extracting the sending result of the driving module sending the table entry to the first chip for processing; wherein the sending result includes: sending success and sending failure;

[0020] B2: Return the delivery result to the protocol module through the API interface;

[0021] B3: If the delivery result is successful, the protocol module continues to deliver the next table item; if the delivery result is failed, corresponding measures are taken for the delivered table item; wherein the corresponding measures include: re-delivering the table item, recording a log or triggering an alarm, etc.

[0022] It should be noted that the sending result is usually obtained by reading the status register of the chip or receiving the response of the chip.

[0023] Normally, when the driver module processes each table item, it must poll each switching chip of the interface board. Only after the items are sent in sequence can the protocol module be returned. The protocol module then sends the next table item. This method of sending items in sequence to each chip will seriously affect the switching performance when there are many chips on the interface board. The present invention allows the driver module to send the table item of the first chip and directly return the result to the protocol module without waiting for all chips to finish sending. The protocol module can quickly send the next table item after receiving the returned result, which greatly speeds up the processing efficiency of the protocol module.

[0024] Preferably, judging whether the driver module writes the entry into the shared queue based on the delivery result includes:

[0025] If the delivery result is successful, the successfully delivered table entry is added to the shared queue; if the delivery result is failed, the successfully delivered table entry is not added to the shared queue.

[0026] It should be noted that the shared queue is a data structure used to share data in a multi-threaded or multi-tasking environment; in the present application, the shared queue is used to store the forwarding table entries that have been successfully sent to the first chip, so that the task threads of other chips can take these table entries from the queue for parallel sending.

[0027] Preferably, the determining whether to process the abnormal entry based on the result of the parallel sending operation includes:

[0028] Extracting the result of the parallel delivery operation on each chip; wherein the result of the parallel delivery operation includes: success and failure;

[0029] If the result of the parallel delivery operation is successful, the next entry is taken from the shared queue for the next round of parallel delivery operation;

[0030] If the result of the parallel delivery operation is failure, delayed delivery is adopted.

[0031] It should be noted that when the result of the parallel delivery operation is successful, it means that all chips have successfully delivered the table entries; when the result of the parallel delivery operation is failed, it means that at least one chip has failed to deliver.

[0032] The forwarding table items sent by the protocol module are of global nature, that is, all chips of the interface board have the same settings, and the software and hardware resources required for these table item settings are often uniformly allocated by the main control board. Therefore, on an interface board, if one chip is sent successfully, other chips will generally also be sent successfully. The present invention creates a separate task thread for each remaining chip, and multiple task threads can be executed simultaneously. Each thread is responsible for the table item sending operation of a chip, which means that multiple chips can process table items at the same time instead of sequentially. In this way, the driving module realizes asynchronous processing and parallel sending of forwarding table items on other chips, greatly improving the sending efficiency, and greatly reducing the time for sending a forwarding for a multi-chip interface board. At the same time, the sending on these chips is generally successful, and as a result, there is no need to notify the protocol module, and the sending efficiency is also faster.

[0033] Preferably, the delayed delivery process includes:

[0034] S1: Set the maximum number of retries and delay time; the maximum number of retries and delay time are set by experts based on actual operation experience;

[0035] S2: When at least one chip fails to be sent during the parallel sending operation, wait until the delay time ends and then send the entry to the chip that failed to be sent again;

[0036] S3: extract the number of retries for re-delivering the entry to the chip that failed to deliver;

[0037] S4: Determine whether the number of retries is greater than the maximum number of retries; if yes, notify the protocol module to refresh the table entries that failed to be sent; if no, update the result of the parallel sending operation to success.

[0038] It should be noted that the maximum number of retries refers to the maximum number of retries allowed by the system after the table entry fails to be sent. Once this number is reached, the system will no longer retry, but take other measures, such as notifying the protocol module for further processing; the delay time refers to the time interval that the system waits between each retry; re-refreshing the table entry means that the system re-reads the information of the table entry and sends it again to the corresponding hardware device or software module to ensure that the table entry can be correctly applied and take effect.

[0039] In a multi-chip device, the parallel sending operation of forwarding table items may encounter some small probability timing problems, resulting in failure of sending to some or all chips. A common cause of this problem is that multiple protocol modules try to send forwarding table items at the same time, thereby occupying the same hardware resources. Due to the limited hardware resources and the timing differences of concurrent access, this competition may cause some table items to fail to successfully reach the target chip during the sending process. Specifically, when multiple protocol modules request to send table items almost at the same time, hardware resources (such as memory, bus bandwidth, etc.) may be temporarily congested or conflicted, resulting in some table items being lost or processed incorrectly during transmission. Although the probability of this situation occurring is low, once it occurs, it will directly affect the normal operation of the system and the consistency of data. The present invention achieves this goal by By setting the maximum number of retries and the delay time, the system can effectively retry when the table item fails to be delivered. This method not only avoids the delivery failure caused by transient problems, but also prevents the waste of resources and performance degradation caused by infinite retries. The setting of the maximum number of retries ensures that the system can take other measures in time when it still fails after multiple retries, such as notifying the protocol module for further processing, thereby improving the stability and reliability of the system. In addition, the introduction of the delay time effectively alleviates the delivery failure caused by transient problems, such as network congestion, resource competition, etc. By setting an appropriate delay time between each retry, the system has enough time to recover and try again, thereby increasing the probability of successful delivery. This not only reduces the number of unnecessary retries, but also optimizes the overall performance of the system.

[0040] Compared with the prior art, the present invention has the following beneficial effects:

[0041] Although the prior art improves the sending efficiency to a certain extent compared with the traditional forwarding table item sending, it also brings some new problems. In particular, the protocol module needs to judge the next action according to the result returned by the current sending in some cases. For example, MPLS path switching needs to refresh all related table items. Under asynchronous operation, the upper layer protocol does not wait for the sending result, and will refresh all table items at once, and think that all the sending is successful. However, due to hardware resource limitations, the sending may actually fail from somewhere, resulting in inconsistent errors in the upper and lower layer table items, so that it is necessary to check and roll back these operations, causing unnecessary confusion and performance loss. The present invention creates an independent task thread for each chip, and takes out the table items from the shared queue in parallel for sending operations, thereby significantly improving the sending efficiency and the concurrent processing capability of the system. At the same time, the asynchronous operation is adopted. The step notification mechanism is adopted. The driving module lists the items of the first chip and returns the results directly to the protocol module without waiting for all chips to finish sending. The protocol module can quickly send the next item after receiving the returned result, ensuring that the protocol module can obtain the sending result of each item in time and make corresponding decisions. In addition, a delayed retry mechanism is introduced. When a chip fails to send an item for the first time, the task thread will wait for a preset delay time and then try to send it again. By setting the maximum number of retries and the delay time, further measures are taken when it still fails after multiple retries, such as notifying the protocol module to refresh the items, so as to ensure that the status of all chips remains consistent. Through these methods, the present invention not only greatly reduces the sending time and improves the overall performance of the system, but also solves the technical problems that the prior art has obvious deficiencies in sending efficiency and feedback mechanism. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0043] Figure 1 A schematic diagram of the method steps of an embodiment of the present invention;

[0044] Figure 2 The figure is a schematic diagram of the delayed delivery processing steps of an embodiment of the present invention. DETAILED DESCRIPTION

[0045] The technical solution of the present invention will be clearly and completely described below in conjunction with the embodiments. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0046] See also Figure 1 The first aspect of the present invention provides a method for implementing parallel delivery of multi-chip device forwarding table entries, including:

[0047] Step 1: Send a table entry to the driver module through the protocol module;

[0048] Step 2: After receiving the table entry, the driver module sends the table entry to the first chip for processing;

[0049] Step 3: Return the delivery result of the driver module to the protocol module, and determine whether the protocol module continues to deliver the next table entry based on the delivery result; and determine whether the driver module writes the table entry into the shared queue based on the delivery result;

[0050] Step 4: Create a separate task thread for each remaining chip based on the driver module, and take out the table items from the shared queue for parallel distribution operations;

[0051] Step 5: Determine whether to process the abnormal entry based on the result of the parallel delivery operation.

[0052] Sending a table entry to the driver module through the protocol module includes:

[0053] A1: The protocol module generates forwarding table entries to be sent according to the network protocol; the network protocol includes: routing protocol, ARP protocol or MPLS protocol, etc.;

[0054] A2: Encapsulate the generated table entries based on the protocol module;

[0055] A3: Call the API interface provided by the driver module and send the encapsulated table items to the driver module.

[0056] The protocol module determines whether to continue to send the next entry based on the delivery result, including:

[0057] B1: extracting the sending result of the driving module sending the table entry to the first chip for processing; wherein the sending result includes: sending success and sending failure;

[0058] B2: Return the delivery result to the protocol module through the API interface;

[0059] B3: If the delivery result is successful, the protocol module continues to deliver the next table item; if the delivery result is failed, corresponding measures are taken for the delivered table item; wherein the corresponding measures include: re-delivering the table item, recording a log or triggering an alarm, etc.

[0060] Based on the delivery result, it is determined whether the driver module writes the entry into the shared queue, including:

[0061] If the delivery result is successful, the successfully delivered table entry is added to the shared queue; if the delivery result is failed, the successfully delivered table entry is not added to the shared queue.

[0062] Based on the result of the parallel delivery operation, it is determined whether to process the abnormal entry, including:

[0063] Extracting the result of the parallel delivery operation on each chip; wherein the result of the parallel delivery operation includes: success and failure;

[0064] If the result of the parallel delivery operation is successful, the next entry is taken from the shared queue for the next round of parallel delivery operation;

[0065] If the result of the parallel delivery operation is failure, delayed delivery is adopted.

[0066] See also Figure 2 , take delayed delivery measures, including:

[0067] S1: Set the maximum number of retries and delay time; the maximum number of retries and delay time are set by experts based on actual operation experience;

[0068] S2: When at least one chip fails to be sent during the parallel sending operation, wait until the delay time ends and then send the entry to the chip that failed to be sent again;

[0069] S3: extract the number of retries for re-delivering the entry to the chip that failed to deliver;

[0070] S4: Determine whether the number of retries is greater than the maximum number of retries; if yes, notify the protocol module to refresh the table entries that failed to be sent; if no, update the result of the parallel sending operation to success.

[0071] Example 1: Assume that there is a network device, which includes a main control board and multiple interface boards. Each interface board has multiple chips responsible for data forwarding tasks. Now send the forwarding table items to all chips through the protocol module, and ensure that the status of all chips remains consistent. The following are the specific steps and processes:

[0072] Step 1: Send a table entry to the driver module through the protocol module;

[0073] 1. Generate table entries:

[0074] The protocol module generates forwarding table entries that need to be sent according to network protocols (such as routing protocols, ARP protocols, MPLS protocols, etc.).

[0075] For example, a protocol module generates a routing table entry to specify the next-hop address to which a data packet of a certain IP address should be forwarded.

[0076] 2. Encapsulation table items:

[0077] The protocol module encapsulates the generated table items so as to send them to the driver module through the API interface.

[0078] For example, the routing table entry is encapsulated into a data structure, which includes information such as the destination IP address and the next hop address.

[0079] 3. Call the API interface:

[0080] The protocol module calls the API interface provided by the driver module and sends the encapsulated table items to the driver module.

[0081] Step 2: After receiving the table entry, the driver module sends the table entry to the first chip for processing;

[0082] 1. Receive table entries:

[0083] The driver module receives the table items sent by the protocol module through the API interface.

[0084] For example, the driver module receives a routing table entry including information such as the destination IP address and the next hop address.

[0085] 2. Send to the first chip:

[0086] The driver module sends the table entry to the first chip for processing.

[0087] For example, call the "chip_id,entry" function to send the table entry to the first chip (assuming the chip number is 1).

[0088] Step 3: Return the delivery result of the driver module to the protocol module, and determine whether the protocol module continues to deliver the next table entry based on the delivery result; and determine whether the driver module writes the table entry into the shared queue based on the delivery result;

[0089] 1. Extract and distribute the results:

[0090] The driver module extracts the result of sending the table entry to the first chip.

[0091] For example, the status register of the chip is read or the response of the receiving chip is received to determine whether the sending result is successful or failed.

[0092] 2. Return the delivery result:

[0093] The driver module returns the delivery result to the protocol module through the API interface.

[0094] For example, call the result function to return the delivery result to the protocol module.

[0095] 3. Determine whether to continue issuing:

[0096] The protocol module determines whether to continue to send the next table entry based on the sending result.

[0097] If the delivery result is successful, the protocol module continues to deliver the next table entry.

[0098] If the delivery result is a failure, the protocol module takes corresponding measures, such as regenerating table entries, recording logs, or triggering alarms.

[0099] 4. Determine whether to write the table entry into the shared queue:

[0100] The driver module determines whether to write the table entry into the shared queue according to the delivery result.

[0101] If the delivery result is successful, the entry is added to the shared queue.

[0102] If the delivery result is failure, the entry will not be added to the shared queue.

[0103] Step 4: Create a separate task thread for each remaining chip based on the driver module, and take out the table items from the shared queue for parallel distribution operations;

[0104] 1. The driver module creates a separate task thread for each remaining chip.

[0105] For example, a POSIX thread library is used to create multiple task threads, and each thread is responsible for the table entry delivery operation of a chip.

[0106] 2. Each task thread sends the table items taken out from the shared queue to the corresponding chip.

[0107] For example, call the "chip_id,entry" function to send the table entry to the corresponding chip.

[0108] Step 5: Determine whether to process the abnormal entry based on the result of the parallel delivery operation;

[0109] 1. Extract and distribute the results in parallel:

[0110] The driver module extracts the results of the parallel dispatch operation on each chip.

[0111] Results include success and failure.

[0112] 2. Determine whether to continue issuing:

[0113] If the result of the parallel delivery operation is successful (all chips have successfully delivered the table entries), the next table entry is taken out from the shared queue to perform the next round of parallel delivery operation.

[0114] If the result of the parallel delivery operation is failure (at least one chip fails to deliver), delayed delivery is adopted.

[0115] The process of delayed delivery is as follows:

[0116] 1. Set the maximum number of retries and delay time:

[0117] Set the maximum number of retries (e.g. 3) and the delay time (e.g. 100 milliseconds).

[0118] These parameters can be adjusted based on actual operating experience.

[0119] 2. Wait and try again:

[0120] When at least one chip fails to be sent during the parallel sending operation, the task thread waits for the delay time to expire and then sends the entry to the chip that failed to be sent.

[0121] For example, wait 100 milliseconds before retrying to download the item.

[0122] 3. Extract retry times:

[0123] Extract the number of retries to re-download items to chips that failed to be delivered.

[0124] 4. Determine the number of retries:

[0125] Determine whether the number of retries is greater than the maximum number of retries.

[0126] If the number of retries is greater than the maximum number of retries, the protocol module is notified to refresh the table entries that failed to be sent.

[0127] If the number of retries is less than or equal to the maximum number of retries, the result of the update parallel delivery operation is successful, and the next round of delivery operation is continued.

[0128] Through the above steps, the present invention realizes efficient parallel delivery of forwarding table entries in a multi-chip device.

[0129] Key benefits include:

[0130] 1. Improve the efficiency of sending data: Through parallel sending operations, multiple chips can process table items at the same time instead of sequentially, which greatly improves the efficiency of sending data.

[0131] 2. Reduce latency: By returning the result to the protocol module immediately after the first chip is successfully sent, the protocol module can quickly send the next table entry, reducing the overall latency.

[0132] 3. Enhanced stability: By setting the maximum number of retries and delay time, the system can effectively retry when the table entry fails to be delivered, avoiding delivery failures caused by transient problems and improving the stability and reliability of the system.

[0133] 4. Ensure consistency: By re-flash the table items and other measures, ensure that the status of all chips remains consistent, avoiding the problem of inconsistent system status caused by the failure of individual chips to send.

[0134] Working principle of the present invention:

[0135] The present invention sends a table item to a driving module through a protocol module; after receiving the table item, the driving module sends the table item to a first chip for processing; returns the sending result of the driving module to the protocol module, and judges whether the protocol module continues to send the next table item based on the sending result; and judges whether the driving module writes the table item into a shared queue based on the sending result; creates a separate task thread for each remaining chip based on the driving module, and takes out the table item from the shared queue for parallel sending operation; judges whether to process the abnormal table item based on the result of the parallel sending operation, thereby solving the problem of poor switching performance caused by the time-consuming sequential sending of traditional forwarding table items on multiple chips, and the technical problem that the prior art has obvious deficiencies in sending efficiency and feedback mechanism.

[0136] The above embodiments are only used to illustrate the technical method of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical method of the present invention may be modified or replaced by equivalents without departing from the spirit and scope of the technical method of the present invention.

Claims

1. A method for implementing parallel delivery of multi-chip device forwarding table entries, characterized in that: include: Step 1: Send a table entry to the driver module through the protocol module; Step 2: After receiving the table entry, the driver module sends the table entry to the first chip for processing; Step 3: Return the delivery result of the driver module to the protocol module, and determine whether the protocol module continues to deliver the next table entry based on the delivery result; And judging whether the driver module writes the table entry into the shared queue based on the delivery result; Step 4: Create a separate task thread for each remaining chip based on the driver module, and take out the table items from the shared queue for parallel distribution operations; Step 5: Determine whether to process the abnormal entry based on the result of the parallel delivery operation.

2. The method for implementing parallel delivery of multi-chip device forwarding table entries according to claim 1, characterized in that: The step of sending a table entry to the driver module through the protocol module includes: A1: The protocol module generates forwarding table entries that need to be sent according to the network protocol; A2: Encapsulate the generated table entries based on the protocol module; A3: Call the API interface provided by the driver module and send the encapsulated table items to the driver module.

3. The method for implementing parallel delivery of multi-chip device forwarding table entries according to claim 1, characterized in that: The determining, based on the delivery result, whether the protocol module continues to deliver the next table entry includes: B1: extracting the sending result of the driving module sending the table entry to the first chip for processing; wherein the sending result includes: sending success and sending failure; B2: Return the delivery result to the protocol module through the API interface; B3: When the delivery result is successful, the protocol module continues to deliver the next table item; when the delivery result is failed, corresponding measures are taken for the delivered table item.

4. The method for implementing parallel delivery of multi-chip device forwarding table entries according to claim 1, characterized in that: The step of judging whether the driver module writes the entry into the shared queue based on the delivery result includes: If the delivery result is successful, the successfully delivered table entry is added to the shared queue; if the delivery result is failed, the successfully delivered table entry is not added to the shared queue.

5. The method for implementing parallel delivery of multi-chip device forwarding table entries according to claim 1, characterized in that: The determining whether to process the abnormal entry based on the result of the parallel sending operation includes: Extracting the result of the parallel delivery operation on each chip; wherein the result of the parallel delivery operation includes: success and failure; If the result of the parallel delivery operation is successful, the next entry is taken from the shared queue for the next round of parallel delivery operation; If the result of the parallel delivery operation is failure, delayed delivery is adopted.

6. The method for implementing parallel delivery of multi-chip device forwarding table entries according to claim 5, characterized in that: The delayed delivery process includes: S1: Set the maximum number of retries and delay time; S2: When at least one chip fails to be sent during the parallel sending operation, wait until the delay time ends and then send the entry to the chip that failed to be sent again; S3: extract the number of retries for re-delivering the entry to the chip that failed to deliver; S4: Determine whether the number of retries is greater than the maximum number of retries; if yes, notify the protocol module to refresh the table entries that failed to be sent; if no, update the result of the parallel sending operation to success.

Images