RoCEv2 message-based flow table aging method, electronic devices and readable media

By parsing the Remote QPN field in the RoCEv2 disconnection request message, flow table entries are dynamically managed, solving the problem of untimely flow table aging in existing technologies and improving system resource utilization efficiency and performance.

CN119299370BActive Publication Date: 2026-03-06SUZHOU CENTEC COMM CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411410336.5
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-10-10
Publication Date
2026-03-06
Estimated Expiration
2044-10-10

AI Technical Summary

Technical Problem

Existing RoCEv2 network devices fail to age flow tables in a timely manner when connections are lost or communication is interrupted, resulting in wasted resources and reduced system performance.

Method used

By parsing the Remote QPN field in the RoCEv2 disconnection request message as a key identifier, the corresponding flow table entries can be found and deleted, thus achieving dynamic aging of the flow table.

Benefits of technology

It improves the flexibility of flow table management and system processing efficiency, reduces resource consumption, and avoids the resource waste caused by the traditional fixed timeout mechanism.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119299370B_ABST
    Figure CN119299370B_ABST
Patent Text Reader

Abstract

This invention discloses a flow table aging method, electronic device, and readable medium based on RoCEv2 packets. The method includes: extracting the Remote QPN field from the RoCEv2 disconnection request packet; using the Remote QPN field as a key identifier to search for flow table information; if the Remote QPN field matches the destination queue pair field of a flow table entry, deleting the flow table entry to achieve flow table aging for RoCEv2 packets. The flow table aging method, electronic device, and readable medium based on RoCEv2 packets provided by this invention, upon receiving a RoCEv2 disconnection request packet, can accurately determine if a connection has been disconnected by parsing the key fields in the packet and directly trigger the flow table aging operation. It no longer relies on a fixed timeout mechanism but performs flow table aging based on actual network events, making flow table management more intelligent and dynamic, thereby reducing resource consumption and improving the overall system processing efficiency.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention belongs to the field of computer communication technology, specifically relating to a flow table aging method based on RoCEv2 messages, an electronic device, and a readable medium. Background Technology

[0002] In today's rapidly developing data centers and high-performance computing fields, RDMA (Remote Direct Memory Access) technology, with its low latency and high throughput, has gradually become one of the important technologies in network transmission. RDMA technology bypasses the operating system kernel and directly transfers data between applications, reducing processor intervention and memory copying operations in traditional transmission methods, thus greatly improving transmission efficiency. Building on RDMA technology, RoCE (RDMA over Converged Ethernet) allows RDMA functionality to be implemented over standard Ethernet, and RoCEv2 has further evolved into a protocol capable of operating in Layer 3 network environments. RoCEv2 utilizes UDP (User Datagram Protocol) encapsulation, enabling it to cross routers and different broadcast domains, thereby expanding its application scope.

[0003] Although RDMA and RoCEv2 have been widely adopted in high-performance computing and large-scale data centers, several challenges remain in managing and maintaining flow tables for these high-speed data flows in real-world network environments. Existing RoCEv2 network devices require the maintenance of numerous flow tables, each recording detailed information about a specific flow, including source and destination addresses, queue pairs (QPNs), and sequence numbers. However, in the event of connection drops or communication interruptions, these flow tables often fail to age out or be deleted in a timely manner, leading to wasted device resources and reduced overall system performance.

[0004] Therefore, it is necessary to provide a new solution to the above-mentioned technical problems. Summary of the Invention

[0005] The purpose of this invention is to provide a flow table aging method, electronic device, and readable medium based on RoCEv2 messages, which can solve the problem of the current fixed and inflexible flow table aging time based on RoCEv2 messages.

[0006] To achieve the above objectives, the technical solution provided by the present invention is as follows:

[0007] In a first aspect, the present invention provides a flow table aging method based on RoCEv2 packets, comprising:

[0008] Extract the Remote QPN field from the RoCEv2 disconnection request message; use the Remote QPN field as a key identifier to search for flow table information; if the Remote QPN field matches the destination queue pair field of the flow table entry, delete the flow table entry to achieve flow table aging of RoCEv2 messages.

[0009] In one or more embodiments, the method further includes: receiving and parsing a RoCEv2 message to extract a feature field of the RoCEv2 message; if the feature field of the RoCEv2 message meets a preset condition, then the RoCEv2 message is a RoCEv2 disconnection request message.

[0010] In one or more embodiments, the method includes: if the UDP destination of the RoCEv2 message is 4791, the opcode of the BTH is 100, and the Attribute ID of the MAD Header is 21, then the RoCEv2 message is a RoCEv2 disconnection request message.

[0011] In one or more embodiments, the method further includes: if the RoCEv2 message is a RoCEv2 disconnection request message, then performing IPFIX processing.

[0012] In one or more embodiments, the method further includes: parsing the received RoCEv2 message and extracting the destination queue pair field; using the destination queue pair field as a key identifier for searching the flow table, searching for a corresponding flow table entry in the stored flow table; if no matching flow table entry is found, performing a flow table learning operation, recording the destination queue pair field in the flow table, and generating a new flow table entry; if a matching flow table entry is found, updating the information of the flow table entry.

[0013] In one or more embodiments, the method further includes: if the Remote QPN field does not match the destination queue pair field of a flow table entry in the flow table, then no processing is performed on the flow table entry.

[0014] In one or more embodiments, the RoCEv2 disconnection request message includes ETH field, IP field, UDP field, BTH field, DETH field, MAD field, CM field, and ICRC & CRC field.

[0015] Secondly, the present invention provides a flow table aging device based on RoCEv2 messages, comprising:

[0016] The extraction module is used to extract the Remote QPN field of the RoCEv2 disconnection request message; the search module is used to search for flow table information using the Remote QPN field as a key identifier; and the deletion module is used to delete the flow table entry when the destination queue pair field of the flow table entry matches the Remote QPN field, so as to realize the flow table aging of RoCEv2 messages.

[0017] Thirdly, the present invention provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the flow table aging method as described above.

[0018] Fourthly, the present invention provides a computer-readable medium carrying computer-executable instructions, which, when executed by a processor, are used to implement the flow table aging method as described above.

[0019] Compared with existing technologies, the flow table aging method, electronic device, and readable medium based on RoCEv2 packets provided by this invention can accurately determine that a connection has been broken by parsing key fields in the RoCEv2 disconnection request packet after receiving it, and directly trigger the flow table aging operation. It no longer relies on a fixed timeout mechanism, but performs flow table aging based on actual network events, making flow table management more intelligent and dynamic, thereby reducing resource consumption and improving the overall processing efficiency of the system. Attached Figure Description

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

[0021] Figure 1 This is a schematic diagram of the Rocev2 message interaction process in one embodiment of the present invention;

[0022] Figure 2 This is a flowchart of a flow table aging method in one embodiment of the present invention;

[0023] Figure 3 This is a structural diagram of a RoCEv2 disconnection request message in one embodiment of the present invention;

[0024] Figure 4 This is a schematic diagram of a flow meter aging device in one embodiment of the present invention;

[0025] Figure 5 This is a schematic diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0026] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0027] Current flow table aging mechanisms are primarily based on a fixed aging time. That is, after the last data packet of a flow is transmitted, the device sets a timeout period. If no new data packets arrive within the timeout period, the flow table entry is deleted. However, this fixed-time aging mechanism has significant drawbacks. In some scenarios, communication has been interrupted, but flow table entries have not aged out in time, causing flow tables to consume device memory resources. This situation is particularly serious in high-speed networks; the long-term retention of flow table entries not only wastes valuable resources but may also affect the establishment of other new connections.

[0028] This invention stems from the significant shortcomings of existing technologies in managing flow table aging in high-performance computing and data center network environments. In the RoCEv2 protocol, network devices manage different data flows through flow tables, and timely aging of these tables is crucial for the efficient utilization of system resources. However, existing flow table aging mechanisms often rely on fixed time thresholds, meaning that flow tables are only deleted after a timeout. This approach exhibits significant limitations in practical applications, especially when facing high-frequency connection and disconnection operations. A fixed aging time can easily lead to flow table entries occupying system resources for extended periods, impacting device performance. Furthermore, in some cases, even after a connection is broken, the flow table may not be deleted in a timely manner, further exacerbating the problem of resource waste.

[0029] To address this issue, this invention proposes a flow table aging method based on RoCEv2 packets. By parsing specific packets, the timing of flow table aging is dynamically adjusted, thereby improving the flexibility of flow table management. The core of this technology lies in the fact that after receiving a RoCEv2 disconnection request packet, the device can accurately determine that a connection has been broken by parsing key fields in the packet and directly trigger the flow table aging operation. Unlike existing technologies, this invention does not rely on a fixed timeout mechanism but instead performs flow table aging based on actual network events, making flow table management more intelligent and dynamic, thereby reducing resource consumption and improving the overall system processing efficiency.

[0030] This method achieves rapid updating or deletion of flow tables when flow connections are broken by parsing RoCEv2 packets. This event-driven flow table aging mechanism enables devices to release flow table resources in a timely manner based on changes in network status, avoiding resource waste caused by unreasonable timeout settings in traditional methods.

[0031] Please refer to Figure 1 The diagram shown illustrates the Rocev2 message interaction process in an exemplary application scenario of the present invention. Figure 1 In the scenario shown, RoCEv2 message interaction is mainly carried out through RDMA (Remote Direct Memory Access) operations.

[0032] The client sends a Connect Request message to the server, indicating that the client wishes to establish an RDMA connection with the server. This request typically carries relevant client information, such as the Queue Pair (QP) number and connection parameters, so that the server can perform matching and resource allocation.

[0033] After receiving a connection request from the client, the server performs necessary verification and resource configuration. If the verification is successful, the server sends a Connect Reply message to confirm the connection request and provide connection information, such as the server's QP number. At this point, the RoCEv2 connection between the client and the server is initially established, ready for subsequent data transmission operations.

[0034] After receiving a connection response from the server, the client will send a ReadyToUse message to confirm that the connection is ready. This message indicates that the client is ready to receive or send RDMA data, and the connection enters an available state. Upon receiving this message, the server will also enter a data transmission preparation state, and both parties can perform RDMA operations.

[0035] Once the connection is established and ready, the client can begin sending RDMA Write messages to directly write data into the server's memory. The biggest advantage of RDMA Write is that data is transferred directly to the server's memory, bypassing operating system intervention and reducing processor load and latency. During data transmission, the client can continuously send multiple RDMA Write messages to write large amounts of data to the server.

[0036] After the client completes data transmission, it will send a Disconnect Request message to the server, requesting to disconnect the RDMA connection with the server. This request typically carries connection-related information, notifying the server that the connection is about to be closed, and the flow table can be updated or aged accordingly.

[0037] After receiving the disconnection request, the server sends a Disconnect Reply message to confirm the disconnection. At this point, the RDMA connection between the client and the server is officially broken, resources are released, and flow table entries can be deleted or aged out.

[0038] Please refer to Figure 2 The diagram shows a flowchart of a flow table aging method based on RoCEv2 packets according to an embodiment of the present invention. This RoCEv2 packet-based flow table aging method specifically includes the following steps:

[0039] S201: Extract the Remote QPN field from the RoCEv2 disconnect request message.

[0040] The Remote QPN is a crucial queue pair identifier used to identify the queue pair number of a remote device. During RoCEv2 communication, each connection between the client and server is uniquely identified by a QPN (Queue Pair Number). Therefore, by parsing the Remote QPN field in a disconnection request message, the device can directly obtain information about connections that need to be aged out or deleted. The device can accurately pinpoint the flow table entry corresponding to the disconnection, avoiding mishandling of other active connections.

[0041] In specific implementation step S201, the device (such as a switch) first receives a RoCEv2 CM Disconnect Request message from the client or server. This message is used to notify the remote device that the current connection has completed data transmission and is about to be disconnected. After the message arrives at the device, the device parses the header information of the message, especially extracting the Remote QPN field. In RDMA communication, each queue pair (QP) has a unique number, and the QPN is used to identify the session associated with that connection. Therefore, by extracting the Remote QPN, the device can determine which remote connection is about to be disconnected.

[0042] In one embodiment, assume that client A and server B transmit data through a switch. Client A writes data to server B's memory by sending an RDMA Write message. After the data transmission is complete, client A sends a Disconnect Request message to server B to notify it that the current session has ended. This message contains server B's RemoteQPN number, for example, QPN=12345. When the switch receives this message, it needs to parse the message and extract Remote QPN=12345, indicating that this is server B's queue pair number. By extracting this field, the switch can know that the connection with number 12345 is about to be disconnected.

[0043] By parsing the Remote QPN field in the message, network devices can directly determine which remote device's connection has been lost. This differs from traditional timeout mechanisms, which assume a connection is lost if no new data packets are received within a fixed time period. In this invention, the device directly determines the connection status by receiving a disconnection request message, thus avoiding the delays and uncertainties associated with fixed timeout mechanisms.

[0044] In one exemplary embodiment, after receiving a RoCEv2 message, the device performs flow table learning, specifically including: parsing the received RoCEv2 message and extracting the destination queue pair field; using the destination queue pair field as a key identifier for searching the flow table, searching for the corresponding flow table entry in the stored flow table; if no matching flow table entry is found, performing a flow table learning operation, recording the destination queue pair field in the flow table, and generating a new flow table entry; if a matching flow table entry is found, updating the information of the flow table entry.

[0045] After receiving a RoCEv2 message, the network device parses the message header and extracts the Destination Queue Pair field. In RDMA communication, each communication session has a unique queue pair (QP) to identify the source and destination of the data stream. Therefore, the Destination Queue Pair field is a core field for determining the target device and connection of the message. By extracting this field, the device can clearly identify the receiving target of the data stream.

[0046] Next, the device uses the extracted destination queue pair field as the key identifier to search for a matching flow table entry in the existing flow table. A flow table is a table used by network devices to track and manage the status of various data flows in the network. Each flow table entry records key information about a data flow, such as source address, destination address, source QPN, and destination QPN. The significance of using the destination QPN as the key identifier is that it can accurately identify which existing data flow the packet belongs to, thereby determining how the packet should be processed.

[0047] If no matching flow table entry is found, it means this is a new data flow, and the device has not yet recorded information about it. In this case, the device performs a flow table learning operation. Flow table learning refers to adding new data flow information to the flow table, generating new flow table entries. Specifically, the device records the destination QPN field extracted from the packet in the flow table and assigns it a new entry, ensuring that subsequent packets of the same data flow can be quickly found. This flow table learning mechanism allows network devices to dynamically adapt and record information when faced with new data flows, thereby enhancing the device's flow table management capabilities.

[0048] If a matching flow table entry is found, it means that the data flow already existed in the flow table. At this point, the device updates the flow table entry. Update operations may include updating the status of the flow table entry (such as the flow's activity status), adjusting statistics (such as the amount of data transmitted, the flow duration, etc.), or updating the device's processing strategy for the data flow. Flow table updates ensure that the entry information in the flow table is always up-to-date, thereby helping the device better manage ongoing network communications.

[0049] For example, suppose client A communicates with server B via a RoCEv2 network through a switch. A sends a data write request to B. The switch first parses the RoCEv2 packet and extracts the destination queue pair field (let's say QPN=5678). The device checks the flow table to see if there is already an entry related to QPN=5678. If no matching flow table entry is found, the device creates a new entry and records QPN=5678 in the flow table, so that subsequent packets of the same data flow can be quickly found. If the switch finds an existing entry for QPN=5678, it updates the entry, for example, by adding flow throughput statistics or updating the flow's activity status.

[0050] In one exemplary embodiment, the method further includes: receiving and parsing a RoCEv2 message to extract feature fields of the RoCEv2 message; if the feature fields of the RoCEv2 message meet preset conditions, then the RoCEv2 message is a RoCEv2 disconnection request message.

[0051] When a device (such as a switch) receives a RoCEv2 message, it parses the message and extracts its characteristic fields. These characteristic fields are crucial information identifying the message type and typically include the UDP destination port number, the opcode in the BTH (Base Transport Header), and the Attribute ID in the MAD Header. In a RoCEv2 network, there are many types of messages, such as data transmission messages, connection establishment messages, and disconnection request messages. To distinguish between different message types, the device needs to use these characteristic fields for identification.

[0052] The device compares the extracted feature fields with preset conditions. If the extracted feature fields meet the preset conditions—that is, if the packet fields match the standard format of a disconnection request packet—the device determines that the packet is a disconnection request packet. This step aims to ensure that the device can accurately identify disconnection request packets, thereby performing corresponding resource management operations. For example, after determining that the packet is a disconnection request, the device can begin performing flow table aging operations, deleting flow table entries related to the connection and releasing system resources.

[0053] Specifically, if the UDP destination of the RoCEv2 message is 4791, the opcode of BTH is 100, and the Attribute ID of MADHeader is 21, then the RoCEv2 message is a RoCEv2 disconnection request message.

[0054] The UDP destination port number is one of the important criteria for determining the message type. In the RoCEv2 communication protocol, the UDP destination port number of a message is usually 4791. This is a port number specifically reserved in the RoCEv2 standard communication to distinguish RoCEv2 messages from other types of network traffic. By checking whether the UDP destination port number is 4791, the device can quickly and preliminarily determine whether the message belongs to RoCEv2 communication.

[0055] Next, the device checks the opcode of the BTH (Base Transport Header). In RoCEv2 messages, the BTH is the base transport header, which contains key information for control and operation messages. The Opcode field identifies the type of operation in the message. For disconnection request messages, the value of the Opcode field in the BTH is 100. This value indicates that the current message is a communication management operation, specifically a request to disconnect. By parsing the Opcode field of the BTH, the device can further confirm whether the message is part of a disconnection operation.

[0056] In addition, the Attribute ID field in the MAD (Management Datagram) header of the message is also a crucial field. The MAD message carries management information, while the Attribute ID specifically describes the function or attribute of the current message. In RoCEv2 disconnection request messages, the Attribute ID value is typically 21, indicating that the message is a management operation requesting the disconnection of the RDMA connection. By checking the Attribute ID field, the device can accurately determine whether the message is related to connection management, specifically a disconnection request.

[0057] By comprehensively judging these three fields—UDP destination port number 4791, BTH Opcode 100, and MADHeader Attribute ID 21—the device can determine that the current packet is a RoCEv2 disconnection request packet. Ensuring the device can promptly identify connection status changes, especially in high-performance network environments, accurately determining connection disconnection can effectively prevent the retention of flow table resources, thereby improving system performance.

[0058] Furthermore, if the RoCEv2 message is a RoCEv2 disconnection request message, then IPFIX processing is performed. Through the IPFIX (IP Flow Information Export) protocol, network traffic information is collected and analyzed, and the data is exported to relevant monitoring and management systems to achieve dynamic monitoring and management of network traffic.

[0059] The RoCEv2 disconnect request message is used to notify remote devices that a connection has been completed or needs to be disconnected. In the RoCEv2 flow table management of this invention, the disconnect request message is the trigger point for flow table aging or deletion. Therefore, after receiving this message, the device needs to perform flow table aging processing as well as further traffic information recording and processing. IPFIX processing is introduced to collect, record, and export the traffic data related to this disconnect message for system analysis and statistics.

[0060] In one exemplary embodiment, please refer to Figure 3 As shown, the RoCEv2 disconnection request message includes the ETH field, IP field, UDP field, BTH field, DETH field, MAD field, CM field, and ICRC & CRC fields.

[0061] The ETH field (Ethernet Header) is the outermost encapsulation part of the message, located at the data link layer of the OSI model. The ETH field contains information such as the source MAC address and destination MAC address, used for message transmission in an Ethernet environment. Through the ETH field, RoCEv2 messages can be transmitted between different network devices via Ethernet, identifying the source and destination devices. The Ethernet header ensures that RoCEv2 messages can achieve point-to-point transmission in a Layer 3 network.

[0062] The IP field (IP Header) is used to encapsulate the source and destination IP addresses at the network layer. This field ensures that RoCEv2 packets can traverse multiple routers and be transmitted between different network segments. The presence of the IP field enables RoCEv2 to be routed through Layer 3 networks, achieving cross-domain communication. Therefore, in large-scale network deployments, the IP field is crucial for the flexible transmission of RoCEv2 packets, especially for communication between different subnets within a data center.

[0063] The UDP header field, located at the transport layer, encapsulates information such as the source port number, destination port number, and data length. RoCEv2 uses the UDP protocol for encapsulation, and the UDP destination port number for RoCEv2 messages is typically 4791. UDP's lightweight nature ensures efficient and low-latency data transmission, while the port number is used to determine the data flow at the application layer. When processing RoCEv2 disconnection request messages, the device identifies whether the message is a RoCEv2 protocol message based on the destination port number in the UDP header.

[0064] The Base Transport Header (BTH) field is the fundamental transport header of RoCEv2 messages, containing key fields such as the opcode. For disconnection request messages, the Opcode field value of the BTH is typically 100, indicating that the message is a management operation for disconnection. The BTH field defines the transmission behavior of RoCEv2 messages, ensuring that network devices can accurately understand the message type and purpose. In disconnection request scenarios, devices use the BTH header to identify the operation type of the message and perform corresponding resource release and flow table aging operations.

[0065] The DETH (Datagram Extended Transport Header) field is an extended transport header in RoCEv2 messages, primarily used to carry additional information about the datagram. The DETH field typically contains extra control information, helping devices to perform more granular control and management during transmission.

[0066] The MAD (Management Datagram Header) field is the management header in RoCEv2 messages, primarily used to carry management-level information. For disconnection request messages, the Attribute ID field in the MAD header is typically 21, indicating that the message is a disconnection request message in communication management. Through the MAD field, the device can identify and process management operations, especially in scenarios involving connection disconnection and flow table aging, where this field provides important guidance.

[0067] The CM (Communication Management Header) field carries specific information related to connection management, the most important of which is the Remote QPN (Remote Queue Number) field. This field is a key identifier for the device to perform flow table lookups and aging, ensuring that the device can accurately match the flow table entries for disconnected connections. Upon receiving a disconnection request message, the device extracts the Remote QPN from the CM header and uses this field to find the corresponding flow table entry, ensuring the accuracy of the aging operation.

[0068] The ICRC and CRC fields are used for data integrity verification, ensuring that data has not been tampered with or corrupted during transmission. ICRC is used for message transmission verification, while CRC is used for frame verification. Through these verification fields, the device can determine whether a message contains errors during transmission. If an error is detected, the device can discard the message, thus ensuring the reliability of the entire data transmission.

[0069] S202: Use the Remote QPN field as the key identifier to look up the flow table information.

[0070] It should be noted that the Remote QPN is a queue pair number for the remote device, used to identify the communication queue of the remote device during RoCEv2 communication. Each queue pair has a unique QPN number, which the device uses to identify and manage data flows. The main purpose of this step S202 is to find the corresponding entry in the network device's flow table using the extracted Remote QPN field, so that subsequent flow table aging, update, or deletion operations can be performed.

[0071] In practice, the device extracts the Remote QPN field by parsing the RoCEv2 disconnection request message. This field is typically found in the CM (Communication Management) header, which contains crucial connection management information. After obtaining the Remote QPN, the device uses it as the key field to look up the flow table. A flow table is a table used to record and manage the status of each data flow in the network, containing information such as source address, destination address, source QPN, and destination QPN. The Remote QPN is the core field in the flow table used to identify remote connections.

[0072] The device then uses the Remote QPN to match stored flow table entries to check if a corresponding entry exists. If a matching entry is found, the device can update or delete it as needed; if no matching entry is found, it indicates that the connection may be aging, and the device can continue to perform other operations (such as adding a flow table entry or maintaining the status quo).

[0073] For example, suppose client A and server B communicate via a switch using the RoCEv2 protocol. Client A's QPN is 67890, and server B's QPN is 12345. When client A sends a disconnect request packet to server B, the switch receives and parses the packet, extracting the Remote QPN field. In this example, the Remote QPN is 12345 (client A's queue number). Next, the switch searches its flow table for an entry matching Remote QPN=12345. If a matching entry is found, the switch marks the connection as "disconnected" and prepares to age out or delete the flow table entry. In this way, the device can accurately manage the status of each connection, ensuring that resources are released in a timely manner.

[0074] Remote QPN lookup ensures that devices identify and locate flow table entries requiring processing in the most accurate way. This lookup method avoids interference with other irrelevant flow table entries, ensuring processing accuracy. This mechanism makes flow table management more flexible, allowing for dynamic updating and aging of flow table entries without relying on a fixed time aging mechanism. This can significantly improve system performance and resource management efficiency in network environments with high-frequency connection and disconnection operations.

[0075] By using the Remote QPN as an identifier to look up flow table information, precise control over multiple concurrent connections can be achieved. Especially in large-scale data centers and high-performance computing environments, this mechanism can greatly reduce the waste of system resources and ensure that devices can efficiently process large amounts of data streams.

[0076] S203: If the Remote QPN field matches the destination queue pair field of the flow table entry in the flow table, then delete the flow table entry to achieve flow table aging of RoCEv2 packets.

[0077] In RoCEv2 communication, queue pairs (QPs) are used to identify the communication channel between the two devices. Each connection has a source QPN and a destination QPN, which identify the queue numbers of the client and server, respectively. As the communication process ends or a disconnection request is sent, the associated queue pair will no longer be used, and therefore the associated flow table entries need to be deleted in a timely manner to prevent resources from being unnecessarily occupied.

[0078] In specific implementation step S103, when the device finds a matching flow table entry in step S102 (i.e., the RemoteQPN field is the same as the destination queue pair field in the flow table), it indicates that communication for that connection has been completed. At this time, the device will mark or delete the flow table entry associated with that queue pair and perform a flow table aging operation. This deletion operation can immediately release the device's memory and computing resources, avoiding performance degradation due to unused flow table entries remaining in the system.

[0079] For example, suppose client A's queue pair number is 67890, and it is communicating with server B's queue pair number is 12345. When client A sends a RoCEv2 disconnect request message, the switch receives and parses the message, extracts Remote QPN=12345, and searches for an entry matching this QPN in the flow table. If an entry with QPN=12345 is found, the switch confirms that the communication has been completed and that the flow table entry is no longer needed. At this point, the switch deletes the entry, removes it from the flow table, and releases the corresponding resources to ensure that the device can be used for subsequent new connections.

[0080] In this invention, flow table aging is performed in an event-driven manner (based on changes in connection state), which is more flexible than the traditional fixed-timeout aging method. Traditional timeout aging mechanisms may set a long time window to prevent premature deletion of flow table entries, but this leads to excessive resource occupation time and cannot flexibly adapt to actual network traffic changes. However, by using Remote QPN-based matching and deletion, the device can take immediate action based on the actual connection state, thereby ensuring efficient resource utilization.

[0081] In one exemplary embodiment, if the Remote QPN field does not match the destination queue pair field of a flow table entry in the flow table, then no processing is performed on the flow table entry.

[0082] If the device does not find an entry matching the Remote QPN in the flow table, this could be because the connection has already been processed and removed from the flow table, or because the request message belongs to a connection outside the current device's control. In this case, the device should not perform any operation on the flow table entry. Otherwise, mishandling irrelevant flow table entries could lead to system chaos or incorrect resource release, thereby affecting system stability and performance.

[0083] Please refer to Figure 4 As shown, based on the same inventive concept as the aforementioned flow table aging method based on RoCEv2 messages, the present invention provides a flow table aging device 400 based on RoCEv2 messages, which includes: an extraction module 401, a search module 402, and a deletion module 403.

[0084] Extraction module 401 is used to extract the Remote QPN field from RoCEv2 disconnection request packets. Lookup module 402 is used to look up flow table information using the Remote QPN field as a key identifier. Deletion module 403 is used to delete a flow table entry when its destination queue pair field matches the Remote QPN field, thereby achieving flow table aging for RoCEv2 packets.

[0085] Please refer to Figure 5 As shown, embodiments of the present invention also provide an electronic device 500, which includes at least one processor 501, a memory 502 (e.g., non-volatile memory), a main memory 503, and a communication interface 504, and the at least one processor 501, the memory 502, the main memory 503, and the communication interface 504 are connected together via a bus 505. The at least one processor 501 is used to invoke at least one program instruction stored or encoded in the memory 502 to cause the at least one processor 501 to perform various operations and functions of the RoCEv2 message-based flow table aging method described in various embodiments of this specification.

[0086] In the embodiments of this specification, electronic device 500 may include, but is not limited to: personal computer, server computer, workstation, desktop computer, laptop computer, notebook computer, mobile electronic device, smartphone, tablet computer, cellular phone, personal digital assistant (PDA), handheld device, messaging device, wearable electronic device, consumer electronic device, etc.

[0087] This invention also provides a computer-readable medium carrying computer-executable instructions. When executed by a processor, these instructions can be used to implement various operations and functions of the RoCEv2-based flow table aging method described in the various embodiments of this specification.

[0088] The computer-readable medium in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0089] In this invention, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wireline, optical fiber, RF, etc., or any suitable combination thereof.

[0090] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0091] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus, systems, and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0092] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0093] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for aging a flow table based on a RoCEv2 packet, characterized in that, The method comprises the following steps: receiving an RoCEv2 message carried by Ethernet, wherein the RoCEv2 message comprises an ETH field, an IP field, a UDP field, a BTH field and a MAD field; analyzing the UDP field, the BTH field and the MAD field, and determining the RoCEv2 message as a disconnection request message when it is detected that the destination port in the UDP field is equal to 4791, the opcode in the BTH field is equal to 100 and the Attribute ID in the MAD field is equal to 21; extracting a destination queue pair field from the RoCEv2 message, taking the destination queue pair field as a key identifier for searching a flow table, searching a corresponding flow table entry in the stored flow table, performing a flow table learning operation if no matching flow table entry is found, recording the destination queue pair field in the flow table to generate a new flow table entry, and updating the information of the flow table entry if a matching flow table entry is found; when the RoCEv2 message is the disconnection request message, extracting a Remote QPN field of the disconnection request message, and taking the Remote QPN field as a key identifier for searching a flow table entry with the destination queue pair field equal to the Remote QPN field in the flow table; if the Remote QPN field matches the destination queue pair field of the flow table entry in the flow table, deleting the flow table entry to realize flow table aging of the RoCEv2 message.

2. The method of claim 1, wherein, The method further comprises the following steps: if the RoCEv2 message is an RoCEv2 disconnection request message, performing IPFIX processing.

3. The method of claim 1, wherein, The method further comprises the following steps: if the Remote QPN field does not match the destination queue pair field of the flow table entry in the flow table, not processing the flow table entry.

4. The method of claim 2, wherein, The RoCEv2 disconnection request message comprises a DETH field, a CM field and an ICRC&CRC field.

5. A flow table aging apparatus based on the flow table aging method according to any one of claims 1 to 4, characterized by The method comprises the following steps: an extracting module configured to extract a Remote QPN field of an RoCEv2 disconnection request message; a searching module configured to take the Remote QPN field as a key identifier for searching flow table information; a deleting module configured to delete a flow table entry in a flow table when the destination queue pair field of the flow table entry matches the Remote QPN field, so as to realize flow table aging of the RoCEv2 message.

6. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor realizes the flow table aging method according to any one of claims 1-4 when executing the program.

7. A computer readable medium characterized by The computer readable medium carries computer execution instructions, and the computer execution instructions are used to realize the flow table aging method according to any one of claims 1-4 when executed by the processor.

Citation Information

Patent Citations

  • Message forwarding method, device, equipment and chip system

    CN117424862A

  • Hardware unloading flow table deletion method and device

    CN117857446A