Data processing method and device, nonvolatile storage medium and electronic equipment

Abstract

The invention discloses a data processing method and device, a nonvolatile storage medium and electronic equipment. The method comprises the following steps: when it is detected that a deadlock state occurs in a target network architecture, determining a target port queue in the deadlock state; a deadlock recovery timer is started, a deadlock state detection thread is created, and the deadlock state detection thread is used for detecting the deadlock state of the target port queue and writing a target message used for indicating that the deadlock state is changed into a database under the condition that the deadlock state of the target port queue is changed; and receiving a target message published by the database, and ending the deadlock recovery timer under the condition of determining that the deadlock state of the target port queue is released in the target network architecture. According to the method and the device, the technical problem that the network performance is reduced due to the fact that the recovery time of the recovery timer cannot be accurately determined in the prior art in allusion to the PFC deadlock condition is solved.

Description

Technical Field

[0001] The present application relates to the field of network technology and security, and specifically, to a data processing method and device, a non-volatile storage medium, and an electronic device. Background Art

[0002] Priority Flow Control (PFC) is a lossless flow control technology widely used in Ethernet, which aims to achieve priority-based flow control in a hop-by-hop manner. Compared with the traditional Ethernet Pause mechanism, PFC can control traffic more accurately, allowing the creation of multiple virtual channels on the link, independently pausing and restarting any channel, and ensuring that traffic of different priorities does not interfere with each other. This technology avoids congestion and deadlock by sending and receiving PAUSE frames and setting thresholds, and is one of the key means to build a lossless Ethernet. In Ethernet, when the sending rate of a certain priority message exceeds the receiving rate, resulting in insufficient available data buffer space on the receiver, the device will send a PFCPAUSE frame to feedback to the upstream device. After receiving the PAUSE frame, the upstream device stops sending the priority message until it receives a PFCCON frame or after a certain aging time, it can resume traffic sending. Figure 1 A schematic diagram of a priority-based flow control is shown, such as Figure 1 As shown in FIG. 4 , this mechanism ensures that congestion of a certain type of traffic will not affect the normal forwarding of other types of traffic, so that different types of messages on the same link will not interfere with each other.

[0003] In modern data centers and large network architectures, efficient and reliable data transmission and flow control are key to ensuring business continuity and performance. The combination of PFC technology and networking architectures such as CLOS aims to build a network environment that can not only guarantee service quality but also achieve high scalability and non-blocking transmission.

[0004] However, the widespread use of PFC in CLOS also brings the risk of deadlock, such as Figure 2 As shown in the figure, due to the multi-level and multi-path characteristics of the CLOS architecture, when a loop or improper configuration occurs in the network, multiple switches may fall into a deadlock state because they are waiting for each other to release resources. In this case, not only will data packets with specific priorities fail to be transmitted, but the performance and stability of the entire network may also be affected.

[0005] In response to the PFC deadlock that occurs in the CLOS network, which causes the phenomenon that traffic cannot be forwarded, the relevant processing method will start a timer to perform the deadlock recovery action after reporting the deadlock interrupt information, that is, ignore the received PFCXOFF message and the flow control state of the current port queue, and perform the port forwarding action. The relevant processing method cannot accurately control the recovery time of the recovery timer. Too long recovery time may cause the subsequent flow control state to be ignored, while too short recovery time will cause the deadlock to not be resolved.

[0006] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0007] The present application provides a data processing method and device, a non-volatile storage medium, and an electronic device to at least solve the technical problem of network performance degradation caused by the inability of related technologies to accurately determine the recovery time of a recovery timer in the case of PFC deadlock.

[0008] According to one aspect of the present application, a data processing method is provided, including: when a deadlock state is detected in a target network architecture, determining a target port queue where the deadlock state occurs; starting a deadlock recovery timer and creating a deadlock state detection thread, wherein the deadlock state detection thread is used to detect the deadlock state of the target port queue, and when the deadlock state of the target port queue changes, writing a target message indicating that the deadlock state has changed into a database; receiving a target message published by the database, and when it is determined that the deadlock state of the target port queue has been released in the target network architecture, ending the deadlock recovery timer.

[0009] Optionally, receiving a target message published by a database, and ending a deadlock recovery timer when it is determined that the deadlock state of the target port queue has been released in the target network architecture, includes: receiving a target message published by a database, and determining a recovery duration set in a deadlock recovery timer; when the recovery duration set in the deadlock recovery timer is greater than a first preset threshold, judging whether the deadlock state of the target port queue has been released in the target network architecture; when it is determined that the deadlock state of the target port queue has not been released in the target network architecture, keeping the deadlock recovery timer working; when it is determined that the deadlock state of the target port queue has been released in the target network architecture, ending the deadlock recovery timer.

[0010] Optionally, the method also includes: in a case where the recovery duration set in the deadlock recovery timer is less than a second preset threshold, after the deadlock recovery timer ends, determining whether the deadlock state of the target port queue has been released in the target network architecture, wherein the second preset threshold is less than the first preset threshold; in a case where it is determined that the deadlock state of the target port queue has not been released in the target network architecture, restarting the deadlock recovery timer until it is monitored that the deadlock state of the target port queue has been released in the target network architecture.

[0011] Optionally, the method also includes: when it is determined that the deadlock state of the target port queue has not been released in the target network architecture, determining whether the number of times the deadlock state occurs is greater than a third preset threshold; when it is determined that the number of times the deadlock state occurs is less than the third preset threshold, re-detecting the deadlock state of the target port queue; when it is determined that the number of times the deadlock state occurs is greater than the third preset threshold, stopping detecting the deadlock state of the target port queue.

[0012] Optionally, after starting the deadlock recovery timer, the method further includes: turning on a flow control switch of the target port queue, wherein the flow control switch is used to ignore a flow control action for regulating data traffic when in an turned-on state.

[0013] Optionally, after creating the deadlock state detection thread, the method further includes: defining a target channel for publishing and subscribing to target messages, and the main thread subscribes to the target channel using the SUBSCRIBE command of Redis; when the deadlock state changes, the target message is sent to the target channel using the PUBLISH command of Redis.

[0014] Optionally, after determining that a target port queue is in a deadlock state, the method further includes: stopping detecting the deadlock state of the target port queue.

[0015] According to another aspect of the present application, a data processing device is also provided, including: a determination module, used to determine the target port queue in the deadlock state when a deadlock state is detected in the target network architecture; a first processing module, used to start a deadlock recovery timer and create a deadlock state detection thread, wherein the deadlock state detection thread is used to detect the deadlock state of the target port queue, and when the deadlock state of the target port queue changes, a target message indicating the change of the deadlock state is written into a database; a second processing module, used to receive the target message published by the database, and when it is determined that the deadlock state of the target port queue has been released in the target network architecture, end the deadlock recovery timer.

[0016] According to another aspect of the present application, a non-volatile storage medium is provided, the storage medium includes a stored program, wherein when the program is executed, the device where the storage medium is located is controlled to execute the above data processing method.

[0017] According to another aspect of the present application, an electronic device is provided, including: a memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the above data processing method is executed when the program is run.

[0018] According to yet another aspect of the present application, a computer program is provided, wherein the above data processing method is implemented when the computer program is executed by a processor.

[0019] According to another aspect of the present application, a computer program product is provided, which includes a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the above data processing method is implemented.

[0020] In the present application, when a deadlock state is detected in a target network architecture, a target port queue in which a deadlock state occurs is determined; a deadlock recovery timer is started, and a deadlock state detection thread is created, wherein the deadlock state detection thread is used to detect the deadlock state of the target port queue, and when the deadlock state of the target port queue changes, a target message indicating that the deadlock state has changed is written into a database; a target message published by the database is received, and when it is determined that the deadlock state of the target port queue has been released in the target network architecture, the deadlock recovery timer is ended. By determining the target port queue in which a deadlock state occurs, the deadlock recovery timer is started, a recovery action is executed, and a thread is started at the same time for obtaining the change in the deadlock state and writing it into the database, so as to accurately end the recovery timer, thereby achieving the purpose of accurately determining the recovery time of the recovery timer, thereby realizing the technical effect of improving network performance, and further solving the technical problem of network performance degradation caused by the inability of the relevant technology to accurately determine the recovery time of the recovery timer in the case of PFC deadlock. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0022] Figure 1 A schematic diagram of a priority-based flow control is shown;

[0023] Figure 2 A schematic diagram showing a deadlock state;

[0024] Figure 3 is a flow chart of a data processing method according to an embodiment of the present application;

[0025] Figure 4 is a topological diagram of a network architecture according to an embodiment of the present application;

[0026] Figure 5 is a flow chart of another data processing method according to an embodiment of the present application;

[0027] Figure 6 is a structural diagram of a data processing device according to an embodiment of the present application;

[0028] Figure 7 It is a hardware structure block diagram of a computer terminal according to a data processing method of an embodiment of the present application. DETAILED DESCRIPTION

[0029] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0030] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0031] According to an embodiment of the present application, a method embodiment of a data processing method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0032] Figure 3 is a flow chart of a data processing method according to an embodiment of the present application, such as Figure 3 As shown, the method comprises the following steps:

[0033] Step S302, when a deadlock state is detected in the target network architecture, a target port queue where the deadlock state occurs is determined.

[0034] The target network architecture is, for example, CLOS networking, where CLOS networking is a network architecture widely used in data center networks. It has been applied and developed in data center networks, especially in building large-scale, non-blocking, and highly scalable network environments.

[0035] The CLOS network architecture contains multiple levels of switches. The most common form is a two-layer or three-layer architecture, namely the Leaf-Spine architecture or Leaf-Spine-Leaf architecture. In the two-layer architecture, the Leaf switch is directly connected to the server, and the Spine switch connects all the Leaf switches to form a fully interconnected network. The three-layer architecture adds a layer of Leaf on this basis, further improving the scalability of the network. The characteristics of CLOS networking include: 1. Non-blocking: In theory, the CLOS architecture can achieve non-blocking communication between any server and any server, that is, the communication path between any two servers will not be occupied or blocked by other communication paths. 2. High scalability: The CLOS architecture can easily expand the network by increasing the number and level of switches to support more server access without significantly increasing the complexity of the network. 3. Multi-path: In the CLOS architecture, data packets usually have multiple paths to choose from, which provides path redundancy and enhances the reliability and fault tolerance of the network. 4. Flow control: CLOS networking can integrate various flow control mechanisms, such as PFC, to optimize data transmission and avoid congestion and deadlock.

[0036] In the process of real-time monitoring of network traffic, once the deadlock detection mechanism detects the existence of a PFC deadlock state in the CLOS network architecture, the specific port queue where the deadlock occurs is located. For example, this is achieved by analyzing the interrupt information of the network device, which contains the identifier of the deadlocked port and the queue priority group (PG) information, so that the deadlock location can be accurately determined.

[0037] For example, the following methods can be used to detect whether a deadlock occurs in the target network architecture: 1. The network device (such as a switch) continuously monitors the traffic status at the inlet and outlet, especially the queue status for each priority group (PG). Check whether a PFC PAUSE frame is received and whether a PFC PAUSE frame has been sent. If a PAUSE frame is sent and no XON frame is received within a preset time, it may indicate that a deadlock has occurred. 2. Set a threshold to determine whether a queue is approaching or reaching a deadlock state. If a queue continues to send PAUSE frames for a period of time and does not receive an XON frame to resume traffic, this may trigger a deadlock detection. Once a deadlock state is detected, the network device will generate an interrupt signal and report it to the network monitoring system or control plane. 3. After receiving the interrupt, the monitoring system will parse the interrupt information and extract the specific port and priority group (PG) where the deadlock occurred. 4. By querying the interface status of the switch, including queue depth, PAUSE frame send and receive counts, etc., it is further confirmed whether the port queue is in a deadlock state.

[0038] Step S304, start the deadlock recovery timer and create a deadlock state detection thread, wherein the deadlock state detection thread is used to detect the deadlock state of the target port queue, and when the deadlock state of the target port queue changes, write a target message indicating the change of the deadlock state into the database.

[0039] After the deadlocked port queue is determined, the following operations are performed: 1. Start a timer to control the time window for deadlock recovery. The setting time of the timer needs to find a balance between ensuring sufficient time to release the deadlock and avoiding long-term resource occupation, and can be dynamically adjusted according to the specific network environment and traffic characteristics. 2. Create a dedicated thread to continuously monitor the deadlock status of the target port queue. This thread is activated at the same time as the timer is started, and its function is to detect whether the deadlock status has changed, especially whether it has been released. 3. When the deadlock status detection thread detects that the deadlock status has changed, it will write a message indicating the state change (target message) to the REDIS database. The use of the REDIS database ensures that state changes can be quickly and reliably notified to other components in the system, including the main thread.

[0040] Step S306, receiving the target message published by the database, and ending the deadlock recovery timer when it is determined that the deadlock state of the target port queue has been released in the target network architecture.

[0041] Set up a subscription mechanism so that the main thread can quickly respond to status change information in the database. The specific operation is as follows: the main thread subscribes to the REDIS database. Once the target message of the deadlock status change is written to the database, the main thread will be notified immediately. After receiving the target message, the main thread will check whether the deadlock status of the target port queue in the target network architecture has been released. If the deadlock status has indeed been released, proceed to the next step. After confirming that the deadlock status has been released, stop the deadlock recovery timer, release resources and restore normal network monitoring and flow control mechanisms.

[0042] According to the above steps, the PFC deadlock problem in the networking architecture can be effectively handled, avoiding the degradation of network performance and the interruption of data transmission. Compared with other timer recovery methods, this application is more flexible and responsive, and can be adjusted according to the real-time changes in network status. At the same time, through the database subscription notification mechanism, it ensures the timely transmission of deadlock release information, improving the overall stability and efficiency of the system.

[0043] The following Figure 3 The steps shown are exemplary and explanatory.

[0044] According to some optional embodiments of the present application, receiving a target message published by a database, and ending a deadlock recovery timer when it is determined that the deadlock state of the target port queue has been released in the target network architecture, can be achieved by the following method: receiving a target message published by a database, and determining a recovery duration set in a deadlock recovery timer; when the recovery duration set in the deadlock recovery timer is greater than a first preset threshold, determining whether the deadlock state of the target port queue has been released in the target network architecture; when it is determined that the deadlock state of the target port queue has not been released in the target network architecture, keeping the deadlock recovery timer working; when it is determined that the deadlock state of the target port queue has been released in the target network architecture, ending the deadlock recovery timer.

[0045] Furthermore, when the recovery duration set in the deadlock recovery timer is less than a second preset threshold, after the deadlock recovery timer ends, it is determined whether the deadlock state of the target port queue has been released in the target network architecture, wherein the second preset threshold is less than the first preset threshold; when it is determined that the deadlock state of the target port queue has not been released in the target network architecture, the deadlock recovery timer is restarted until it is monitored that the deadlock state of the target port queue has been released in the target network architecture.

[0046] The main thread or other processes responsible for network monitoring and recovery continuously monitor the REDIS database. Once a message indicating a change in the deadlock state (target message) is written to the database, the monitoring mechanism responds immediately. Key information is extracted from the target message, including the network architecture involved, the specific port queues, and the change in the deadlock state.

[0047] Check the current setting of the deadlock recovery timer to determine its recovery duration.

[0048] If the recovery time of the deadlock recovery timer is greater than the first preset threshold, it means that the system has given sufficient time to recover the deadlock state. At this time, the system will check whether the deadlock state of the target port queue in the target network architecture has been released. If the deadlock state has been released, the deadlock recovery timer is terminated. If the deadlock state has not been released, the deadlock recovery timer is kept running.

[0049] When the recovery duration of the deadlock recovery timer is less than the second preset threshold, it indicates that the system has not given enough time to observe the recovery effect. After the timer ends, the system checks the deadlock status of the target port queue in the target network architecture again. If the deadlock status has been released, the deadlock recovery timer is terminated after confirming that the recovery is successful. If the deadlock status has not been released, consider restarting the deadlock recovery timer to allow additional recovery time.

[0050] The above threshold control strategy can help the system make more reasonable judgments and responses at different recovery stages. Specifically: The first preset threshold: used to determine whether the system has given enough time to try to restore the deadlock state. If this threshold is exceeded and the deadlock state is still not resolved, it indicates that there are deeper network problems and further investigation is required. The second preset threshold: set a smaller threshold to give the system a short observation period in the early stage of recovery to confirm whether the deadlock recovery is effective. If the recovery time is less than this threshold and the deadlock state is still not resolved, the system will automatically extend the recovery time to give more opportunities to resolve the deadlock state and avoid stopping the recovery timer too early, causing the deadlock state to continue.

[0051] Through the above implementation methods, the system can intelligently and dynamically adjust the deadlock recovery strategy, which not only ensures that the network can recover in a timely and effective manner when encountering a PFC deadlock, but also avoids the performance impact and resource waste caused by improper recovery strategy, and maintains the efficient and stable operation of the network.

[0052] Furthermore, when it is determined that the deadlock state of the target port queue has not been released in the target network architecture, it is determined whether the number of times the deadlock state occurs is greater than a third preset threshold; when it is determined that the number of times the deadlock state occurs is less than the third preset threshold, the deadlock state of the target port queue is re-checked; when it is determined that the number of times the deadlock state occurs is greater than the third preset threshold, the deadlock state of the target port queue is stopped.

[0053] At the end of the deadlock recovery timer, check whether the deadlock state of the target port queue in the target network architecture has been released. If the deadlock state has not been released, count the number of times the target port queue deadlocks in a specific time period and compare it with the third preset threshold. If the number of deadlocks is less than the third preset threshold, it means that the deadlock phenomenon does not occur abnormally frequently, and the system can continue to run its regular deadlock detection and recovery process. At this time, the system restarts the deadlock detection cycle and continues to monitor the deadlock state of the target port queue so that once the deadlock occurs again, the recovery mechanism can be started in time.

[0054] If the number of deadlocks exceeds the third preset threshold, it indicates that the target port queue is frequently deadlocked, and there is an abnormality or network configuration problem. At this time, the system will stop detecting the deadlock state of the target port queue to avoid continuing to try to recover under abnormal circumstances, which may lead to resource waste or further degradation of network performance.

[0055] The system records the number of deadlocks that exceed the threshold, as well as all related network status information, to provide a basis for subsequent network optimization and troubleshooting. Based on the collected abnormal information, network administrators or automation systems may need to re-evaluate network configuration, traffic control policies, and even hardware performance to find the root cause and take effective measures to prevent similar deadlock problems from occurring in the future.

[0056] According to other optional embodiments of the present application, after the deadlock recovery timer is turned on, the following steps can also be performed: turn on the flow control switch of the target port queue, wherein the flow control switch is used to ignore the flow control action for regulating data traffic when it is in the turned-on state.

[0057] Once the deadlock state is confirmed, the deadlock recovery timer is started to set a time window for the recovery action. At the same time as the deadlock recovery timer is started, the flow control switch of the target port queue is turned on. The function of this switch is to allow the port queue to ignore the flow control actions (such as PFC PAUSE frames) used to regulate data flow when it is turned on, ensuring the normal forwarding of data packets even when the flow control signal still exists. This can prevent the deadlock state from further deteriorating and create favorable conditions for deadlock recovery. After the flow control switch is turned on, the target port queue will no longer respond to PAUSE frames, and even if the upstream device continues to send PAUSE frames, it will not stop sending data packets.

[0058] In some optional embodiments of the present application, after creating a deadlock state detection thread, the following steps may also be performed: define a target channel for publishing and subscribing to target messages, and the main thread uses the SUBSCRIBE command of Redis to subscribe to the target channel; when the deadlock state changes, use the PUBLISH command of Redis to send the target message to the target channel.

[0059] Before you start monitoring, you first need to define a target channel for publishing and subscribing target messages. The target channel should be named descriptively, clearly identifying the network architecture, port, and queue information associated with it. For example, the target channel can be named:

[0060] PFC_DEADLOCK_STATUS_ <networkarchitecture> _ <port> _ <queuegroup>.

[0061] The main thread or other process responsible for network monitoring uses the Redis SUBSCRIBE command to subscribe to the target channel defined above, so that the main thread can receive all messages from the target channel, that is, real-time updates on the deadlock status.

[0062] The network device continuously monitors the PFC deadlock status. Once a change in the deadlock status is detected (such as release or reoccurrence), the monitoring mechanism of the network device will respond immediately. In the event of a change in the deadlock status, the network device uses Redis's PUBLISH command to send the target message to the target channel. The target message should contain complete information, such as the network architecture identifier, port number, queue group (PG) information, deadlock status (released or not released), and possible timestamps, so that the main thread can accurately identify the state change and respond in time. After the main thread receives the target message of the deadlock state change, it updates its internal state according to the information in the message, and decides whether to continue running the deadlock recovery timer, restart deadlock detection, adjust the flow control strategy, etc. based on the updated state.

[0063] By introducing the Redis publish / subscribe mechanism, the network monitoring system can respond to changes in the PFC deadlock status in the CLOS network in real time and efficiently, which not only improves the network's automated management capabilities, but also enhances the network's adaptability and response speed to abnormal situations.

[0064] As some optional embodiments of the present application, after determining that a target port queue is in a deadlock state, the following step may be performed: stopping detecting the deadlock state of the target port queue.

[0065] Once the target port queue is confirmed, the system will start the deadlock recovery process, including but not limited to turning off the PG's deadlock detection, setting the flow control switch to ignore PAUSE frames, starting the deadlock recovery timer, etc. At the same time as starting the deadlock recovery process, the system will suspend further detection of the deadlock status of the target port queue. Because when performing deadlock recovery, continuing to detect the deadlock status may cause conflicts, interfere with the recovery action, and cause unnecessary resource consumption. Once the deadlock status is released, the system will re-enable the deadlock status detection of the target port queue to ensure the continued healthy operation of the network. If the deadlock status is not released and is confirmed to be an abnormal situation, the system may no longer restart the deadlock detection, but instead take higher-level diagnostic and recovery measures.

[0066] Figure 4 is a topological diagram of a network architecture according to an embodiment of the present application, wherein: Figure 4 The figure shows two leaf switches, Leaf1 and Leaf2. Each leaf switch is directly connected to multiple servers, and is responsible for processing network traffic from the servers and forwarding this traffic to the spine layer. The lines in the topology diagram represent network links, and the accompanying labels (such as 400G, 100G) indicate the bandwidth capabilities of these links. High-bandwidth links (such as 400G) are usually used to connect the spine and leaf switches, while lower-bandwidth links (such as 100G) are used for connections between servers and leaf switches. When the system detects a PFC deadlock on a path, it starts a deadlock recovery process, which involves turning off deadlock detection, counting the number of deadlocks, adjusting the flow control switch, and using the Redis database to monitor the status, so as to quickly and intelligently resolve the deadlock and resume data transmission. In this process, if the deadlock state is not resolved within the specified time, but the number of deadlocks does not exceed the abnormal threshold, the system will retry recovery; if the number of deadlocks is abnormally frequent and exceeds the preset threshold, the system will take further abnormal handling measures, such as turning off deadlock detection for specific ports, to avoid resource waste and may trigger higher-level troubleshooting.

[0067] Figure 5 is a flow chart of another data processing method according to an embodiment of the present application. Figure 5 As shown, the method comprises the following steps:

[0068] Step S501, deadlock detection loop, if no deadlock is detected, the loop continues. The status of all port queues is checked regularly to determine whether there is a PFC deadlock. If no deadlock is detected, the system will continue to monitor in a loop to ensure that potential problems in the network can be responded to in a timely manner.

[0069] Step S502, exit the loop upon detecting deadlock. If a deadlock state of a port queue is identified in the loop detection, the loop will be exited immediately and the deadlock processing flow will be entered. This means that the system will suspend regular network monitoring activities and focus on solving the current deadlock problem.

[0070] Step S503, parse the uploaded interrupt information to determine the deadlocked port and queue PG information. After the deadlock is detected, parse the uploaded interrupt information to extract the specific deadlocked port and priority queue (PG) information.

[0071] Step S504, turn off the deadlock detection function of the port queue to ensure that no new deadlock is reported during the recovery process. Turn off the deadlock detection function To prevent new and unnecessary deadlock signals from being generated during the deadlock recovery process, the system will turn off the deadlock detection function of the port queue involved in the deadlock. This step ensures that the recovery operation will not be interfered by the ongoing deadlock monitoring.

[0072] Step S505, the number of deadlocks N in the time period is increased by 1. The statistical system records the number of deadlocks N of the port queue in the current time period and increases it by 1 to monitor the frequency of deadlocks.

[0073] Step S506, start the deadlock recovery timer. Start the deadlock recovery timer with a preset duration. During the timer running, the system will perform recovery actions and try to release the deadlock state. The duration of the timer should be optimized according to network characteristics, hardware performance and data transmission requirements to balance recovery efficiency and resource consumption.

[0074] Step S507, start the interrupt status acquisition thread, once the thread acquires the deadlock status change, write it to the Redis database. In order to be able to respond immediately when the deadlock status changes, the system will start a special status acquisition thread, once the thread detects the deadlock status change, write the update information to the Redis database, so that other system components or monitoring systems can obtain this information in real time.

[0075] Step S508, set the execution action when the port queue ignores flow control during deadlock recovery, discard or forward. During deadlock recovery, the system will adjust the flow control strategy of the target port queue to temporarily ignore the PAUSE frame, that is, when a PAUSE frame is received, choose to continue forwarding the data packet or discard the data packet instead of pausing.

[0076] Step S509, turning on the port queue ignoring flow control switch to ensure that the target port queue can ignore the PAUSE frame and forward data traffic normally.

[0077] Step S510: During the recovery timer, receive Redis subscription messages. When the deadlock state is released, stop the current timer immediately. While the deadlock recovery timer is running, the system continues to monitor the Redis database and receive subscription messages. Once a message about the deadlock state change is received, indicating that the deadlock has been released, the system will immediately stop the deadlock recovery timer and end the recovery process.

[0078] Step S511, when the deadlock is released, end the deadlock recovery timer.

[0079] Step S512: After the recovery timer times out, check whether the deadlock is released.

[0080] Step S513: If the deadlock has not been resolved, restart the deadlock recovery timer until the deadlock is resolved. That is, if the deadlock recovery timer is too short and the deadlock has not been resolved, the deadlock recovery timer needs to be restarted.

[0081] Step S514: if the deadlock is released, check whether the number of deadlocks exceeds a threshold.

[0082] Step S515: If the threshold is not exceeded, the deadlock detection of the port queue is restarted.

[0083] Step S516: if the deadlock threshold is exceeded, it is an abnormal situation and there is no need to enable the deadlock detection function.

[0084] Figure 6 is a structural diagram of a data processing device according to an embodiment of the present application, such as Figure 6 As shown, the device comprises:

[0085] The determination module 62 is used to determine the target port queue where the deadlock state occurs when a deadlock state is detected in the target network architecture.

[0086] The first processing module 64 is used to start a deadlock recovery timer and create a deadlock state detection thread, wherein the deadlock state detection thread is used to detect the deadlock state of the target port queue and write a target message indicating the change of the deadlock state into the database when the deadlock state of the target port queue changes.

[0087] The second processing module 66 is used to receive the target message published by the database, and end the deadlock recovery timer when it is determined that the deadlock state of the target port queue has been released in the target network architecture.

[0088] Optionally, the second processing module 66 is used to perform the following steps: receiving a target message published by the database, and determining a recovery duration set in a deadlock recovery timer; when the recovery duration set in the deadlock recovery timer is greater than a first preset threshold, determining whether the deadlock state of the target port queue has been released in the target network architecture; when it is determined that the deadlock state of the target port queue has not been released in the target network architecture, keeping the deadlock recovery timer working; when it is determined that the deadlock state of the target port queue has been released in the target network architecture, ending the deadlock recovery timer.

[0089] Optionally, the data processing device is also used to perform the following steps: when the recovery duration set in the deadlock recovery timer is less than a second preset threshold, after the deadlock recovery timer ends, determine whether the deadlock state of the target port queue in the target network architecture has been released, wherein the second preset threshold is less than the first preset threshold; when it is determined that the deadlock state of the target port queue in the target network architecture has not been released, restart the deadlock recovery timer until it is monitored that the deadlock state of the target port queue in the target network architecture has been released.

[0090] Optionally, the data processing device is also used to perform the following steps: when it is determined that the deadlock state of the target port queue has not been released in the target network architecture, determine whether the number of times the deadlock state occurs is greater than a third preset threshold; when it is determined that the number of times the deadlock state occurs is less than the third preset threshold, re-detect the deadlock state of the target port queue; when it is determined that the number of times the deadlock state occurs is greater than the third preset threshold, stop detecting the deadlock state of the target port queue.

[0091] Optionally, the data processing device is further used to perform the following steps after starting the deadlock recovery timer: turning on the flow control switch of the target port queue, wherein the flow control switch is used to ignore the flow control action for regulating data flow when in the turned-on state.

[0092] Optionally, the data processing device is also used to execute the following steps after creating a deadlock state detection thread: define a target channel for publishing and subscribing to target messages, and the main thread uses Redis's SUBSCRIBE command to subscribe to the target channel; when the deadlock state changes, use Redis's PUBLISH command to send the target message to the target channel.

[0093] Optionally, the data processing device is further configured to, after determining that a target port queue in a deadlock state occurs, execute the following step: stop detecting the deadlock state of the target port queue.

[0094] It should be noted that the above Figure 6 The modules in the embodiment may be program modules (e.g., a set of program instructions for implementing a specific function) or hardware modules. For the latter, they may be expressed in the following forms, but are not limited thereto: the expression form of the above modules is a processor, or the functions of the above modules are implemented by a processor.

[0095] It should be noted that Figure 6 The preferred implementation of the illustrated embodiment can be found in Figure 3 The relevant description of the illustrated embodiment will not be repeated here.

[0096] Figure 7 FIG. 1 shows a hardware structure block diagram of a computer terminal for implementing a data processing method. Figure 7 As shown, the computer terminal 70 may include one or more (shown as 702a, 702b, ..., 702n in the figure) processors 702 (the processor 702 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 704 for storing data, and a transmission module 706 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. It can be understood by those skilled in the art that Figure 7 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 7 More or fewer components as shown, or with Figure 7 Different configurations are shown.

[0097] It should be noted that the one or more processors 702 and / or other data processing circuits described above may generally be referred to herein as "data processing circuits". The data processing circuits may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuit may be a single independent processing module, or may be incorporated in whole or in part into any of the other components in the computer terminal 70. As described in the embodiments of the present application, the data processing circuit acts as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0098] The memory 704 can be used to store software programs and modules of application software, such as program instructions / data storage devices corresponding to the data processing method in the embodiment of the present application. The processor 702 executes various functional applications and data processing by running the software programs and modules stored in the memory 704, that is, realizing the above-mentioned data processing method. The memory 704 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 704 may further include a memory remotely arranged relative to the processor 702, and these remote memories may be connected to the computer terminal 70 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0099] The transmission module 706 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the computer terminal 70. In one example, the transmission module 706 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission module 706 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0100] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 70 .

[0101] It should be noted that, in some optional embodiments, the above Figure 7 The computer terminal shown may include hardware elements (including circuits), software elements (including computer code stored on a computer-readable medium), or a combination of hardware elements and software elements. It should be noted that Figure 7 This is merely one example of a particular embodiment and is intended to illustrate the types of components that may be present in the computer terminal described above.

[0102] It should be noted that Figure 7 The computer terminal shown is used to execute Figure 3 The data processing method shown, therefore the relevant explanations in the execution method of the above command are also applicable to the electronic device and will not be repeated here.

[0103] An embodiment of the present application further provides a non-volatile storage medium, which includes a stored program, wherein when the program is executed, the device where the storage medium is located is controlled to execute the above data processing method.

[0104] A program for performing the following functions on a non-volatile storage medium: determining a target port queue in which a deadlock state occurs when a deadlock state is detected in a target network architecture; starting a deadlock recovery timer and creating a deadlock state detection thread, wherein the deadlock state detection thread is used to detect the deadlock state of the target port queue, and when the deadlock state of the target port queue changes, writing a target message indicating that the deadlock state has changed into a database; receiving a target message published by the database, and ending the deadlock recovery timer when it is determined that the deadlock state of the target port queue has been released in the target network architecture.

[0105] An embodiment of the present application further provides an electronic device, including: a memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the above data processing method is executed when the program is run.

[0106] The processor is used to run a program that performs the following functions: when a deadlock state is detected in a target network architecture, determine the target port queue in which the deadlock state occurs; start a deadlock recovery timer and create a deadlock state detection thread, wherein the deadlock state detection thread is used to detect the deadlock state of the target port queue, and when the deadlock state of the target port queue changes, write a target message indicating that the deadlock state has changed into a database; receive a target message published by the database, and when it is determined that the deadlock state of the target port queue has been released in the target network architecture, end the deadlock recovery timer.

[0107] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0108] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0109] In the above-mentioned embodiments of the present application, the collected information is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with relevant laws, regulations and standards, take necessary protection measures, do not violate public order and good morals, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0110] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0111] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0112] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0113] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the relevant technology or all or part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk, etc. Various media that can store program codes.

[0114] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.< / queuegroup> < / port> < / networkarchitecture>

Claims

1. A data processing method, characterized in that: include: In the case of detecting that a deadlock state occurs in the target network architecture, determining a target port queue where the deadlock state occurs; Starting a deadlock recovery timer and creating a deadlock state detection thread, wherein the deadlock state detection thread is used to detect the deadlock state of the target port queue and, when the deadlock state of the target port queue changes, write a target message indicating that the deadlock state has changed into a database; The target message published by the database is received, and when it is determined that the deadlock state of the target port queue has been released in the target network architecture, the deadlock recovery timer is ended.

2. The method according to claim 1, characterized in that Receiving the target message published by the database, and ending the deadlock recovery timer when determining that the deadlock state of the target port queue has been released in the target network architecture, includes: receiving the target message published by the database, and determining the recovery duration set in the deadlock recovery timer; When the recovery time length set in the deadlock recovery timer is greater than a first preset threshold, determining whether the deadlock state of the target port queue has been released in the target network architecture; When it is determined that the deadlock state of the target port queue has not been resolved in the target network architecture, keeping the deadlock recovery timer working; When it is determined that the deadlock state of the target port queue has been released in the target network architecture, the deadlock recovery timer is ended.

3. The method according to claim 2, characterized in that The method further comprises: In a case where the recovery duration set in the deadlock recovery timer is less than a second preset threshold, after the deadlock recovery timer ends, determining whether the deadlock state of the target port queue has been released in the target network architecture, wherein the second preset threshold is less than the first preset threshold; When it is determined that the deadlock state of the target port queue has not been released in the target network architecture, the deadlock recovery timer is restarted until it is monitored that the deadlock state of the target port queue has been released in the target network architecture.

4. The method according to claim 3, characterized in that include: The method further comprises: In the case where it is determined that the deadlock state of the target port queue is not released in the target network architecture, determining whether the number of times the deadlock state occurs is greater than a third preset threshold; When it is determined that the number of occurrences of the deadlock state is less than the third preset threshold, re-detecting the deadlock state of the target port queue; When it is determined that the number of times the deadlock state occurs is greater than the third preset threshold, the detection of the deadlock state of the target port queue is stopped.

5. The method according to claim 1, characterized in that: After starting the deadlock recovery timer, the method further includes: Turn on the flow control switch of the target port queue, wherein the flow control switch is used to ignore the flow control action for regulating data flow when in the turned-on state.

6. The method according to claim 1, characterized in that After creating the deadlock state detection thread, the method further includes: Define a target channel for publishing and subscribing to the target message, and the main thread uses the Redis SUBSCRIBE command to subscribe to the target channel; When the deadlock state changes, the target message is sent to the target channel using the PUBLISH command of Redis.

7. The method according to claim 1, characterized in that After determining the target port queue in which the deadlock state occurs, the method further includes: stopping detecting the deadlock state of the target port queue.

8. A data processing device, characterized in that: include: A determination module, configured to determine a target port queue where the deadlock state occurs when a deadlock state is detected in the target network architecture; A first processing module is used to start a deadlock recovery timer and create a deadlock state detection thread, wherein the deadlock state detection thread is used to detect the deadlock state of the target port queue and, when the deadlock state of the target port queue changes, write a target message indicating that the deadlock state has changed into a database; The second processing module is used to receive the target message published by the database, and end the deadlock recovery timer when it is determined that the deadlock state of the target port queue has been released in the target network architecture.

9. A non-volatile storage medium, characterized in that: The non-volatile storage medium includes a stored program, wherein when the program is executed, the device where the non-volatile storage medium is located is controlled to execute the data processing method according to any one of claims 1 to 7.

10. An electronic device, characterized in that: include: A memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the program executes the data processing method according to any one of claims 1 to 7 when running.

11. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the data processing method according to any one of claims 1 to 7 is implemented.

Images