Load sharing method and apparatus based on RoCE sessions

Abstract

The application provides a load sharing method and device based on a RoCE session, and relates to the technical field of communication. The method comprises the following steps: receiving a to-be-forwarded message, and identifying the type of the to-be-forwarded message; when it is determined that the to-be-forwarded message is a second type of protocol message, determining a target forwarding path according to a target session identifier corresponding to the to-be-forwarded message and a load sharing path forwarding table, the second type of protocol message being a message in a session data transmission process of the RoCE session, each entry of the load sharing path forwarding table comprising a session identifier and a to-be-used path corresponding to the session identifier, the to-be-used path corresponding to one session identifier being determined according to session information corresponding to the session identifier and a preset load sharing algorithm before a session data transmission process corresponding to the session identifier; and forwarding the to-be-forwarded message according to the target forwarding path. In this way, the routing can be reduced to occur in the RoCE session data transmission process, thereby improving the transmission performance of the RoCE.

Description

Technical Field

[0001] This application relates to the field of communication technology, and more specifically, to a load-sharing method and apparatus based on RoCE sessions. Background Technology

[0002] RDMA (Remote Direct Memory Access), used in InfiniBand networks, is a direct memory access technology that transfers data directly from the memory of one computer to the memory of another. Data is quickly moved from one system to the memory of a remote system without the intervention of the operating systems on either side or the time-consuming processing by the processor, ultimately achieving high bandwidth, low latency, and low resource utilization. RoCE is a network layer protocol that encapsulates raw InfiniBand packets based on the UDP protocol and deploys RDMA services through IP routing networks. To better utilize bandwidth, RoCE networks often use ECMP (Equal Cost Multi-path) as a load-sharing strategy. In traditional ECMP load-sharing strategies, the routing methods used by network chips are prone to routing occurring during RoCE session data transmission, leading to out-of-order packets, retransmissions, and ultimately a sharp decline in transmission performance. Summary of the Invention

[0003] This application provides a load balancing method, apparatus, electronic device, and readable storage medium based on RoCE sessions, which can reduce the occurrence of routing during RoCE session data transmission, thereby improving RoCE transmission performance.

[0004] The embodiments of this application can be implemented as follows:

[0005] Firstly, this application provides a load balancing method based on RoCE sessions, the method comprising:

[0006] Receive the message to be forwarded and identify the type of the message to be forwarded;

[0007] When it is determined that the message to be forwarded is a second type of protocol message, the target forwarding path is determined according to the target session identifier and the load balancing path forwarding table corresponding to the message to be forwarded. The second type of protocol message is a message in the session data transmission process of the RoCE session. Each entry in the load balancing path forwarding table includes a session identifier and the path to be used corresponding to the session identifier. The path to be used corresponding to a session identifier is determined before the session data transmission process corresponding to the session identifier based on the session information corresponding to the session identifier and the preset load balancing algorithm.

[0008] The message to be forwarded is forwarded according to the target forwarding path.

[0009] Secondly, embodiments of this application provide a load balancing method based on RoCE sessions, the method comprising:

[0010] The network chip receives the message to be forwarded and identifies the type of the message to be forwarded;

[0011] When the network chip determines that the packet to be forwarded is a second type of protocol packet, it determines the target forwarding path according to the target session identifier and the load balancing path forwarding table corresponding to the packet to be forwarded. The second type of protocol packet is a packet in the session data transmission process of the RoCE session. Each entry in the load balancing path forwarding table includes a session identifier and the path to be used corresponding to the session identifier. The path to be used corresponding to a session identifier is determined before the session data transmission process corresponding to the session identifier based on the session information corresponding to the session identifier and the preset load balancing algorithm.

[0012] The network chip forwards the packet to be forwarded according to the target forwarding path.

[0013] Thirdly, embodiments of this application provide a load balancing device based on RoCE sessions, the device comprising:

[0014] An identification module is used to receive a message to be forwarded and identify the type of the message to be forwarded;

[0015] The path determination module is used to determine the target forwarding path based on the target session identifier and the load-sharing path forwarding table when the message to be forwarded is determined to be a second type of protocol message. The second type of protocol message is a message in the session data transmission process of a RoCE session. Each entry in the load-sharing path forwarding table includes a session identifier and the path to be used corresponding to the session identifier. The path to be used corresponding to a session identifier is determined before the session data transmission process corresponding to the session identifier based on the session information corresponding to the session identifier and a preset load-sharing algorithm.

[0016] The forwarding module is used to forward the message to be forwarded according to the target forwarding path.

[0017] Fourthly, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory stores machine-executable instructions that can be executed by the processor, and the processor can execute the machine-executable instructions to implement the RoCE session-based load balancing method described in the foregoing embodiments.

[0018] Fifthly, embodiments of this application provide a readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the RoCE session-based load balancing method as described in the foregoing embodiments.

[0019] The RoCE session-based load balancing method, apparatus, electronic device, and readable storage medium provided in this application, upon receiving a message to be forwarded, if the message type identification determines that the message to be forwarded is a second-type protocol message, then a target forwarding path is determined based on the target session identifier corresponding to the message to be forwarded and the load balancing path forwarding table, and the received message to be forwarded is forwarded according to the target forwarding path. The second-type protocol message is a message during the session data transmission process of the RoCE session. Each entry in the load balancing path forwarding table includes a session identifier and a path to be used corresponding to that session identifier. The path to be used corresponding to a session identifier is determined before the session data transmission process corresponding to that session identifier, based on the session information corresponding to that session identifier and a preset load balancing algorithm. This method, upon receiving a message to be forwarded, forwards the message based on the routing result performed before the session data transmission process corresponding to that message. This reduces the occurrence of routing during RoCE session data transmission, thereby reducing the need for message retransmission due to out-of-order delivery and improving RoCE transmission performance. Attached Figure Description

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

[0021] Figure 1 This is a schematic diagram of the RoCE packaging format;

[0022] Figure 2 This is a schematic diagram of the RoCE session process;

[0023] Figure 3 This is a schematic diagram of an existing RoCE session-based load balancing method;

[0024] Figure 4 A block diagram illustrating an electronic device provided in an embodiment of this application;

[0025] Figure 5 One of the flowcharts for the RoCE session-based load balancing method provided in the embodiments of this application;

[0026] Figure 6A second schematic flowchart of the RoCE session-based load balancing method provided in this application embodiment;

[0027] Figure 7 for Figure 6 A flowchart illustrating the sub-steps included in step S120;

[0028] Figure 8 for Figure 5 A flowchart illustrating the sub-steps included in step S130;

[0029] Figure 9 The third flowchart of the RoCE session-based load balancing method provided in this application embodiment;

[0030] Figure 10 for Figure 9 A flowchart illustrating the sub-steps included in step S150;

[0031] Figure 11 The fourth flowchart illustrates the RoCE session-based load balancing method provided in this application embodiment.

[0032] Figure 12 Fifth flowchart illustrating the RoCE session-based load balancing method provided in this application embodiment;

[0033] Figure 13 A schematic diagram illustrating an example of a RoCE session-based load balancing method provided in an embodiment of this application;

[0034] Figure 14 One of the block diagrams of a RoCE session-based load balancing device provided in the embodiments of this application;

[0035] Figure 15 This is a second block diagram of a RoCE session-based load balancing device provided in an embodiment of this application.

[0036] Icons: 100 - Electronic device; 110 - Memory; 120 - Processor; 130 - Communication unit; 200 - RoCE session-based load balancing device; 210 - Identification module; 220 - Path maintenance module; 230 - Path determination module; 240 - Forwarding module. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0038] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

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

[0040] RDMA (Remote Direct Memory Access), used in InfiniBand networks, is a direct memory access technology that transfers data directly from the memory of one computer to the memory of another. Data can be quickly moved from one system to the memory of a remote system without the intervention of the operating systems of both sides or the time-consuming processing of the processor, ultimately achieving the effects of high bandwidth, low latency, and low resource utilization.

[0041] The RoCE protocol exists in two versions: RoCEv1 and RoCEv2. RoCEv1 is an RDMA protocol implemented at the Ethernet link layer, allowing two hosts within the same VLAN to communicate. RoCEv2 is a network layer protocol, such as... Figure 1 As shown in the encapsulation method, RoCEv2 encapsulates InfiniBand raw messages based on the UDP protocol, enabling the deployment of RDMA services through IP routing networks. RoCEv2 overcomes the limitation of RoCEv1 being bound to a single VLAN, and can now be used across L2 and L3 networks.

[0042] RoCE is a connection-oriented service. The session procedures for RoCEv1 and RoCEv2 are similar. The following section combines... Figure 2 Taking writing data based on RoCEv2 as an example, the RoCE session process is explained.

[0043] RoCEv2 sessions consist of three phases: session connection creation, session data transmission, and session connection closure. Data transmission only begins after a successful session connection establishment. The session data transmission phase involves large data volumes and uses block acknowledgment. If packet loss or out-of-order delivery occurs in the network, a simple backoff mechanism is employed. For example, if the sequence number of a received frame is 1, 2, 3, 5, 6, 7, 8, 9, 10, ... 4, the transmission will backoff to sequence number 4 and retransmit the sequence 4, 5, 6, 7, 8, 9, 10, ... This mechanism causes a sharp decline in transmission performance if out-of-order delivery occurs during RoCE transmission. The session connection closure phase occurs after data transmission ends and the connection is closed.

[0044] To better utilize bandwidth, RoCEv2 networks employ ECMP (Equal Cost Multi-path) as a load balancing strategy. Traditional ECMP load balancing typically involves the CPU (Central Processing Unit) software configuring the load balancing path, while the network chip uses routing based on packets or packet segments (i.e., a certain number of packets or packets within a certain timeframe). This stateless, mechanical routing strategy is prone to routing occurring during RoCE session data transmission, leading to out-of-order packets, retransmissions, and ultimately a sharp decline in transmission performance, failing to optimize network bandwidth utilization.

[0045] like Figure 3 As shown, the CPU software system configures load-sharing path groups in the network chip. After receiving a RoCE packet, the network chip determines the load-sharing path group to use through route lookup. Then, based on a stateless mechanical selection algorithm, it selects the forwarding path from the determined load-sharing path group and forwards the RoCE packet. This traditional load-sharing method cannot precisely control the timing of load path selection. Path selection may occur during the transmission of RoCE session data, leading to packet retransmission and ultimately a sharp decline in transmission performance.

[0046] To address the aforementioned issues, embodiments of this application provide a load balancing method, apparatus, electronic device, and readable storage medium based on RoCE sessions, which can reduce the occurrence of routing during RoCE session data transmission, thereby improving RoCE transmission performance.

[0047] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0048] Please refer to Figure 4 , Figure 4This is a block diagram of an electronic device 100 provided in an embodiment of this application. The electronic device 100 can be an intermediate device used for forwarding messages in a network. The electronic device 100 includes a memory 110, a processor 120, and a communication unit 130. The memory 110, processor 120, and communication unit 130 are electrically connected to each other directly or indirectly to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines.

[0049] The memory 110 is used to store programs or data. The memory 110 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0050] The processor 120 is used to read / write data or programs stored in the memory 110 and execute corresponding functions. For example, the memory 110 stores a RoCE session-based load balancing device 200, which includes at least one software functional module that can be stored in the memory 110 in the form of software or firmware. The processor 120 executes various functional applications and data processing by running the software programs and modules stored in the memory 110, such as the RoCE session-based load balancing device 200 in this embodiment, thereby implementing the RoCE session-based load balancing method in this embodiment.

[0051] The communication unit 130 is used to establish a communication connection between the electronic device 100 and other communication terminals through the network, and to send and receive data through the network.

[0052] It should be understood that, Figure 4 The structure shown is only a schematic diagram of the electronic device 100. The electronic device 100 may also include components that are larger than... Figure 4 The more or fewer components shown, or having the same Figure 4 The different configurations shown. Figure 4 The components shown can be implemented using hardware, software, or a combination thereof.

[0053] Please refer to Figure 5 , Figure 5 This is one of the flowcharts illustrating a RoCE session-based load balancing method provided in this application. The method can be applied to Ethernet environments with high real-time data transmission requirements, such as data center networks and industrial networks. The method is applied to an intermediate device in the network used for forwarding packets. This intermediate device includes a network chip and a CPU with communication connections, and the method can be executed by the network chip.

[0054] The specific process of the RoCE session-based load balancing method is described in detail below. In this embodiment, the method may include steps S110 and S130 to S140.

[0055] Step S110: Receive the message to be forwarded and identify the type of the message to be forwarded.

[0056] In this embodiment, after receiving a packet to be forwarded, the network chip identifies the type of the packet so that it can perform different processing based on the type of the packet. This can be done by determining the type of the forwarded packet based on the values ​​of corresponding fields in the packet, or by using other methods to identify the packet type.

[0057] Step S130: When it is determined that the message to be forwarded is a second type of protocol message, the target forwarding path is determined according to the target session identifier and load balancing path forwarding table corresponding to the message to be forwarded.

[0058] Step S140: Forward the message to be forwarded according to the target forwarding path.

[0059] In this embodiment, the network chip includes a load-sharing path forwarding table. Each entry in the load-sharing path forwarding table includes a session identifier and the path to be used corresponding to that session identifier. The session identifier is used to identify a RoCE session, and the specific setting of the session identifier can be configured according to actual needs. The path to be used corresponding to a session identifier is determined before the data transmission process of the session corresponding to that session identifier, based on the session information corresponding to that session identifier and a preset load-sharing algorithm. The session information corresponding to a session identifier represents the information needed for routing during the RoCE session corresponding to that session identifier, and can be specifically determined according to actual needs. The preset load-sharing algorithm is used to select the optimal path, and can be specifically determined according to actual needs.

[0060] That is, before the session data transmission process of a RoCE session, the RoCE session is routed, and the selected path to be used and the corresponding session identifier are stored in the load-sharing path forwarding table.

[0061] Optionally, the routing performed for a RoCE session before the session data transmission process can be executed by the network chip, the CPU, or other devices; no specific limitation is made here on how the path to be used is obtained. The RoCE session involved in the embodiments of this application can be a RoCEv1 session or a RoCEv2 session.

[0062] In this embodiment, if the message to be forwarded is determined to be a second-type protocol message by message type identification, the target session identifier corresponding to the message to be forwarded can be determined based on the message to be forwarded. The second-type protocol message is a message generated during the session data transmission process of a RoCE session. The target session identifier is used to identify the target session corresponding to the message to be forwarded, that is, to identify the RoCE session corresponding to the message to be forwarded. Then, based on the target session identifier, the correspondence between each session identifier included in the load balancing path forwarding table and the path to be used, the target forwarding path can be determined, and then the message to be forwarded is forwarded according to the target forwarding path.

[0063] In this embodiment, when a message to be forwarded is received, the message is forwarded based on the routing result performed before the corresponding session data transmission process. This reduces the occurrence of routing during RoCE session data transmission, thereby reducing the need for message retransmission due to out-of-order delivery and improving RoCE transmission performance.

[0064] One possible implementation is to identify RoCEv2 packets and their specific types as follows: The values ​​of the UDP port number field and the InfiniBand.BTH field in the packet to be forwarded can be extracted. Based on the extracted field values, the process within the RoCE session to which the packet belongs can be identified, thus determining the state of the packet. The UDP port number field value for the RoCEv2 packet is 4791. For example, it can identify ConnectRequest, ConnectReply, and ReadyToUse protocol packets during the RoCE session connection creation process, protocol packets during the RoCE session data transmission process, and DisconnectRequest and DisConnectReply protocol packets during the RoCE session connection closure process. The network chip performs different processing based on the packet type identification result.

[0065] Please refer to Figure 6 , Figure 6This is a second schematic flowchart illustrating the RoCE session-based load balancing method provided in this application embodiment. In this embodiment, after step S110, the method may further include step S120.

[0066] Step S120: When it is determined that the message to be forwarded is a first type of protocol message, the path to be used is determined based on the message to be forwarded and the preset load sharing algorithm, and the determined path to be used and the target session identifier corresponding to the message to be forwarded are stored in the load sharing path forwarding table.

[0067] In this embodiment, the first type of protocol message is a message generated during the session connection creation process of the RoCE session. The first type of protocol message may include any one of the ConnectRequest, ConnectReply, and ReadyToUse protocol messages generated during the session connection creation process of the RoCE session, or at least one of ConnectRequest and ConnectReply, etc., which can be determined according to actual needs.

[0068] When the packet to be forwarded is determined to be a packet of the first type of protocol, the network chip can determine the path to be used corresponding to the target session identifier of the packet to be forwarded in any way, based on the packet to be forwarded and a preset load balancing algorithm.

[0069] For example, the network chip can determine the target session identifier and target session information of the received packet to be forwarded, and combine this with the preset load balancing algorithm to determine the path to be used for the packet. Then, the selected path to be used, along with the target session identifier, is saved in the load balancing path forwarding table. In this way, the network chip can quickly determine the path to be used without obtaining it from other chips or devices.

[0070] For example, the network chip can be used... Figure 7 The method described above obtains the path to be used and saves it to the load-sharing path forwarding table. Please refer to... Figure 7 , Figure 7 for Figure 6 A flowchart illustrating the sub-steps included in step S120. In this embodiment, step S120 may include sub-steps S121 to S122.

[0071] Sub-step S121: The message to be forwarded is sent to the CPU so that the CPU can determine the target session identifier corresponding to the message to be forwarded based on the received message to be forwarded, and determine the path to be used corresponding to the target session identifier based on the received message to be forwarded and the preset load sharing algorithm.

[0072] In this embodiment, the network chip sends the identified packet, which is a packet of the first type of protocol, to the CPU. The CPU can determine the target session identifier and target session information based on the received packet. Then, based on the target session information, the preset load balancing algorithm, and the path information corresponding to each path in different load balancing path groups, the CPU selects the path to be used for the packet. The path information may include the egress port, the current load of the egress port, and the corresponding delay of the egress port. In this way, even if the preset load balancing algorithm is complex, it will not increase the requirements on the network chip. This avoids the situation where the network chip cannot select a path due to the network chip hardware not meeting the execution requirements of the preset load balancing algorithm when the network chip performs routing based on a complex preset load balancing algorithm. It also avoids the situation where only high-cost network chips can be used because the network chip needs to perform routing based on a complex preset load balancing algorithm.

[0073] It is worth noting that if the CPU can determine the target session information based on a single packet to be forwarded, then the CPU can complete the routing after receiving the single packet forwarded by the network chip. If the CPU needs to determine the target session information based on multiple (e.g., two) packets to be forwarded, then the CPU does not complete the routing after receiving the single packet forwarded by the network chip, but only completes the routing after obtaining the complete target session information from the multiple packets forwarded by the network chip.

[0074] Optionally, the target session identifier can be determined based on IPDA, IPSA, Source QP, and Destination QP. For example, the target session identifier includes IPDA, IPSA, Source QP, and Destination QP, or it can be an identifier string calculated using a specific algorithm based on IPDA, IPSA, Source QP, and Destination QP. The target session identifier can also be determined based on IPDA, IPSA, Source QP, Destination QP, or other information. Here, IPDA represents the destination IP address; IPSA represents the source IP address; the InfiniBand protocol defines QP (Queue Pair) as the identifier for session communication, with the sender identified as the Source Queue Pair (i.e., Source QP) and the receiver identified as the Destination Queue Pair (i.e., Destination QP).

[0075] The target session information may include IPDA, or it may include IPDA and other information, depending on actual needs. The other information may include service information, which can be information required for the service carried in other packets, such as the amount of data transmitted in the session, the session duration, and the transmission bandwidth—in other words, information extracted from the session content. Thus, complex path selection algorithms can be used to select routes based on the session content. When the target session information includes service information, the CPU needs to obtain this service information from multiple packets to be forwarded. The service information may include information determined based on the values ​​of the fields InfiniBand.DETH, InfiniBand.MADHeader, and InfiniBand.CM.

[0076] The target session identifier and the target session information may be the same or different, depending on the specific requirements. To facilitate quick acquisition of the target session identifier and the target session information, the target session identifier and the target session information are the same. The target session information may include: IPDA, IPSA, Source QP, and Destination QP, or may include: IPDA, IPSA, Source QP, Destination QP, and service information.

[0077] Optionally, the CPU can obtain the path to be used in the following manner. In the examples below, the target session identifier is the same as the target session information, and the target session identifier is selected as: IPDA, IPSA, Source QP, DestinationQP, and the path selection strategy is the lightest load path.

[0078] The CPU can determine the IPDA, IPSA, Source QP, and Destination QP based on the received packet to be forwarded. The CPU can calculate based on network connectivity to determine the destination ports corresponding to all paths reachable from the destination host (IPDA identifier), and then establish a load-sharing group. The CPU compares the idle bandwidth of all destination ports in the load-sharing group and selects the port with the largest idle bandwidth as the destination port for the current session, thus determining the path to be used for the packet to be forwarded.

[0079] Optionally, upon obtaining the target session information, the CPU can also determine whether to select a path for the target session based on the target session information. If it is determined that a path should be selected for the target session, the path selection is performed based on the target session information and a preset load-sharing algorithm. If it is determined that a path should not be selected for the target session, then no path selection is performed based on the target session information and the preset load-sharing algorithm.

[0080] For example, assuming the target session information includes service information, the CPU can determine whether routing is necessary based on the service information before selecting a path to be used. For instance, if the amount of data transmitted in the target session corresponding to the message to be forwarded is small, or the duration of the target session is short, it can be determined that routing is not necessary.

[0081] When the target session is determined to be the route, the CPU can determine the path to be used based on the received packet to be forwarded according to the preset load sharing algorithm, and then send the path to be used and the corresponding target session identifier in the first instruction to the network chip.

[0082] Sub-step S122: According to the first instruction received from the CPU, the target session identifier and the corresponding path to be used included in the first instruction are saved to the load-sharing path forwarding table.

[0083] Upon receiving the first instruction, the network chip can extract the target session identifier and the corresponding path to be used from the first instruction, and then save the target session identifier and the corresponding path to be used into the load-sharing path forwarding table.

[0084] In this embodiment, as one possible implementation, the network chip can send a message to be forwarded, which is a ConnectRequest protocol message or a ConnectReply protocol message, to the CPU, so that the CPU can obtain the target session identifier and the corresponding path to be used according to the preset load balancing algorithm, the ConnectRequest protocol message, and the ConnectReply protocol message.

[0085] When the target session information is information that can only be obtained based on the ConnectRequest protocol message and the ConnectReply protocol message, obtaining the target session information and routing are performed after the CPU obtains the ConnectRequest protocol message and the ConnectReply protocol message.

[0086] Depend on Figure 2It is known that after sending the ReadyToUse protocol message, the device that sent the ReadyToUse protocol message immediately begins transmitting data. To further ensure that path selection occurs during session data transmission, after the network chip identifies the ConnectReply protocol message, it intercepts and forwards the message to be forwarded (which is a ConnectReply protocol message) to the CPU. After configuring the selected path to be used and the corresponding target session identifier into the network chip's load-sharing path forwarding table, the CPU forwards the message to be forwarded (which is a ConnectReply protocol message) to the network chip via software forwarding; the network chip receives and forwards the message to be forwarded (which is a ConnectReply protocol message). If the CPU also receives messages other than ConnectReply protocol messages during the RoCE session connection creation process, it can immediately forward those messages. In this way, by performing software forwarding on specific protocol messages, it can be ensured that the chip issues the optimal path before data transmission.

[0087] As one possible implementation, when the CPU performs path maintenance, the network chip can also send a ReadyToUse protocol message to the CPU. After the CPU sends a path 'a' to the network chip, it can count the time elapsed since sending the path 'a'. If the time elapsed is longer than a preset time and no ReadyToUse protocol message has been received from the session corresponding to the path 'a', the entry for the path 'a' previously configured in the network chip can be deleted to save hardware table resources. If a ReadyToUse protocol message is received from the session corresponding to the path 'a' before the time elapsed is greater than the preset time, the entry for the path 'a' previously configured in the network chip does not need to be deleted.

[0088] When the message to be forwarded is identified as a second type of protocol message, it can be done through... Figure 8 The target forwarding path is determined as shown. Please refer to... Figure 8 , Figure 8 for Figure 5 A flowchart illustrating the sub-steps included in step S130. In this embodiment, step S130 may include sub-steps S131 to S133.

[0089] Sub-step S131: Determine whether the target session identifier is included in the load sharing path forwarding table.

[0090] If the target session identifier is included in the load-sharing path forwarding table, proceed to sub-step S132.

[0091] Sub-step S132: The path to be used corresponding to the target session identifier in the load-sharing path forwarding table is taken as the target forwarding path.

[0092] If the target session identifier is not included in the load-sharing path forwarding table, proceed to sub-step S133.

[0093] Sub-step S133: The transmission path obtained by performing a route lookup based on the message to be forwarded is taken as the target forwarding path.

[0094] In this embodiment, the target session identifier can be searched in the load-sharing path forwarding table. If the target session identifier is found in the load-sharing path forwarding table, the path to be used corresponding to the target session identifier in the load-sharing path forwarding table can be used as the target forwarding path. If the target session identifier is not found in the load-sharing path forwarding table, it can be determined that no route selection based on a preset load-sharing algorithm was performed for the session corresponding to the packet to be forwarded before the session data transmission process. In this case, the route lookup result can be used as the target forwarding path. Thus, even if a path to be used for a session is not determined in advance due to other factors, it can still be ensured that the packets in the session data transmission process of that session can be forwarded normally.

[0095] The routing lookup method can be as follows: First, obtain the IPDA of the packet to be forwarded based on the packet to be forwarded; then perform a traditional IP routing lookup and use the found transmission path as the target forwarding path.

[0096] Optionally, the process of searching the load-sharing path forwarding table to obtain the path to be used corresponding to the target session identifier, and performing a traditional IP route lookup based on the packet to be forwarded, can be a sequential or parallel process. That is, the search in the load-sharing path forwarding table and the route lookup can be performed simultaneously; or the search can be performed first in the load-sharing path forwarding table, and then a route lookup can be performed if the path is not found.

[0097] To avoid useless entries consuming hardware table resources of the network chip, the method may further include, for example: Figure 9 Step S150 is shown below. Please refer to... Figure 9 , Figure 9 The third schematic flowchart of the RoCE session-based load balancing method provided in this application embodiment. In this embodiment, after step S110, the method may further include step S150.

[0098] Step S150: In the case where the message to be forwarded is a DisConnectReply protocol message in a RoCE session, delete the target entry corresponding to the target session identifier in the load balancing path forwarding table.

[0099] Optionally, as a possible implementation, when the network chip identifies the message to be forwarded as a DisConnectReply protocol message, it can determine the target session identifier based on the message to be forwarded, and then search the load-sharing path forwarding table. If an entry corresponding to the target session identifier is found, that entry is taken as the target entry and deleted. Thus, compared to the method of counting the unused time of each entry and deleting them when the unused time expires, the method provided in this application embodiment can precisely control the timing of deletion of session forwarding paths, ensuring that the corresponding entry is deleted when the session ends.

[0100] Alternatively, as another possible implementation, the deletion of entries in the load-sharing path forwarding table can be handled by the CPU. Please refer to... Figure 10 , Figure 10 for Figure 9 A flowchart illustrating the sub-steps included in step S150. In this embodiment, step S150 may include sub-steps S151 to S152.

[0101] Sub-step S151: When the message to be forwarded is a DisConnectReply protocol message, the message to be forwarded is sent to the CPU.

[0102] Sub-step S152: Receive the second instruction sent by the CPU according to the message to be forwarded as a DisConnectReply protocol message, and delete the target entry corresponding to the target session identifier in the load sharing path forwarding table according to the second instruction.

[0103] In this embodiment, when the network chip identifies a DisConnectReply protocol message to be forwarded, it can forward the message to the CPU. When the CPU receives the DisConnectReply message, since it is the last message of the session, it can determine that the target session corresponding to the message is about to end. In this case, the CPU can determine the target session identifier based on the message and issue a second instruction based on that identifier. This second instruction may include the target session identifier and is used to instruct the deletion of the entry corresponding to the target session identifier in the load balancing path forwarding table. After receiving the second instruction, the network chip can delete the target entry corresponding to the target session identifier in the load balancing path forwarding table according to the second instruction.

[0104] In this embodiment, a stateful load balancing strategy is used for RoCE traffic, separating forwarding and path maintenance. The CPU performs stateful, complex, and efficient path maintenance, while the network chip uses the path specified by the CPU for the data transmission process of the RoCE session. This achieves load balancing for RoCE traffic transmission in the network, improves RoCE transmission performance, and reduces the implementation complexity of the network chip.

[0105] Please refer to Figure 11 , Figure 11 This is the fourth flowchart illustrating the RoCE session-based load balancing method provided in this application embodiment. The method can be applied to network chips and CPUs used for communication connections in network devices. The following section... Figure 11 The specific flow of the RoCE session-based load balancing method is described below. In this embodiment, the method may include steps S210 and S230 to S240.

[0106] In step S210, the network chip receives the message to be forwarded and identifies the type of the message to be forwarded.

[0107] In step S220, when the network chip determines that the packet to be forwarded is a second type of protocol packet, it determines the target forwarding path based on the target session identifier and load balancing path forwarding table corresponding to the packet to be forwarded.

[0108] The second type of protocol message is a message generated during the session data transmission process of the RoCE session. Each entry in the load-sharing path forwarding table includes a session identifier and the path to be used corresponding to that session identifier. The path to be used corresponding to a session identifier is determined before the session data transmission process of that session identifier based on the session information corresponding to that session identifier and a preset load-sharing algorithm.

[0109] Step S240: The network chip forwards the packet to be forwarded according to the target forwarding path.

[0110] Please refer to Figure 12 , Figure 12 This is the fifth flowchart illustrating the RoCE session-based load balancing method provided in this embodiment. In this embodiment, after step S210, the method may further include steps S221 to S224.

[0111] Step S221: When it is determined that the message to be forwarded is a first type of protocol message, the network chip forwards the message to be forwarded to the CPU.

[0112] The first type of protocol message is a message sent during the session connection creation process of the RoCE session.

[0113] In step S222, the CPU obtains target session information based on the received message to be forwarded, and determines whether the target session is the target session corresponding to the message to be forwarded based on the target session information.

[0114] In step S223, when the CPU determines that the target session is the route to be selected, it selects the route according to the target session information and the preset load sharing algorithm, and sends the determined path to be used and the corresponding target session identifier to the load sharing path forwarding table.

[0115] In step S224, if the CPU determines that it is not to select a route for the target session, it does not select a route based on the target session information and the preset load balancing algorithm.

[0116] Optionally, in this embodiment, when the packet to be forwarded is a DisConnectReply protocol packet, the network chip can send the packet to be forwarded to the CPU. The CPU sends a second instruction to the network chip based on the packet to be forwarded as a DisConnectReply protocol packet. The network chip receives the second instruction sent by the CPU based on the packet to be forwarded as a DisConnectReply protocol packet, and deletes the target entry corresponding to the target session identifier in the load-sharing path forwarding table according to the second instruction.

[0117] In this embodiment, for a detailed description of the RoCE session-based load balancing method applied to network chips and CPUs, please refer to the above description. Figures 5 to 11 The description of the RoCE session-based load balancing method shown will not be repeated here.

[0118] The following is combined Figure 13 The above-mentioned RoCE session-based load balancing method is illustrated with an example. This method consists of three parts: creating entries in the load balancing path forwarding table, forwarding data based on the load balancing path forwarding table, and deleting entries in the load balancing path forwarding table. The network chip includes a RoCE packet identification module and a route lookup module, while the CPU's software system includes a RoCE session information extraction module, a RoCE session load balancing path selection module, a load balancing path forwarding table maintenance module, and a RoCE session packet soft forwarding module.

[0119] Create an entry in the load-sharing path forwarding table:

[0120] S11. The message field is matched by the RoCE message recognition module to identify the ConnectRequest and ConnectReply protocol messages of the RoCE session, and the identified ConnectRequest and ConnectReply protocol messages are redirected and forwarded to the CPU software system.

[0121] S12. The RoCE session information extraction module in the CPU software system extracts the RoCE session identification information from the ConnectRequest and ConnectReply protocol messages.

[0122] The session identification information includes: IPDA, IPSA, Source QP, Destination QP, and other service-required information carried in other messages (i.e., service information). This session identification information can be extracted by the RoCE session information extraction module from the ConnectRequest and ConnectReply protocol messages.

[0123] The S13.RoCE session load balancing path selection module selects an optimal path based on session identifier information and path information, using a software strategy algorithm.

[0124] Optionally, in cases of low data transmission volume or short session duration, the RoCE session load balancing path selection module may not perform optimal path selection for the session corresponding to the received message.

[0125] S14. The load balancing path forwarding table maintenance module sends the extracted RoCE session identifier information and the selected optimal path to the load balancing path forwarding table of the network chip.

[0126] S15. After confirming the completion of step S14, i.e., the successful distribution of the optimal path to the load-sharing path forwarding table of the network chip, the RoCE session message soft forwarding module forwards the ConnectReply message. If the CPU receives other messages during the RoCE session connection creation process, the RoCE session message soft forwarding module can immediately forward those other messages.

[0127] Delete entries from the load-sharing path forwarding table:

[0128] The S21.RoCE message recognition module performs message field matching to identify RoCE data transmission messages; when identifying RoCE data transmission messages, it extracts session identification information.

[0129] The session identification information includes: IPDA, IPSA, Source QP, Destination QP, and other service-required information carried in the messages.

[0130] S22. The network chip searches the load-sharing path forwarding table based on the session identifier information to obtain the path corresponding to the session identifier information as forwarding path b.

[0131] S23. The routing lookup module performs a traditional IP routing lookup based on the RoCE data transmission message to obtain the forwarding path c.

[0132] S24. Prioritize forwarding path b to forward RoCE data transmission packets.

[0133] Delete entries from the load-sharing path forwarding table:

[0134] S31. The message field is matched by the RoCE message recognition module to identify the ConnectReply protocol message of the RoCE session, and the identified ConnectReply protocol message is redirected and forwarded to the CPU software system.

[0135] The RoCE session information extraction module in the S32 CPU software system extracts the RoCE session identification information from the ConnectRequest and ConnectReply protocol messages.

[0136] The session identification information includes: IPDA, IPSA, Source QP, Destination QP, and other service-required information carried in the messages.

[0137] S33. The load balancing path forwarding table maintenance module deletes the corresponding entries in the load balancing path forwarding table of the network chip based on the extracted RoCE session identifier information.

[0138] S34. The RoCE session message soft forwarding module forwards the DisConnectReply message. If the CPU receives other messages during the RoCE session connection closing process, the RoCE session message soft forwarding module can immediately forward those other messages.

[0139] Optionally, after determining that S33 is complete, i.e., after determining that the corresponding entry in the load-sharing path forwarding table has been deleted, the RoCE session message soft forwarding module can forward the DisConnectReply message.

[0140] To perform the corresponding steps in the above embodiments and various possible methods, an implementation of a RoCE session-based load balancing device 200 is given below. Optionally, the RoCE session-based load balancing device 200 can adopt the above-described... Figure 4 The device structure of the electronic device 100 shown. Further, please refer to... Figure 14 , Figure 14 This is one of the block diagrams of a RoCE session-based load balancing device 200 provided in this application embodiment. It should be noted that the basic principle and technical effects of the RoCE session-based load balancing device 200 provided in this embodiment are the same as those in the above embodiments. For the sake of brevity, any parts not mentioned in this embodiment can be referred to the corresponding content in the above embodiments. In this embodiment, the RoCE session-based load balancing device 200 may include: an identification module 210, a path determination module 230, and a forwarding module 240.

[0141] The identification module 210 is used to receive the message to be forwarded and identify the type of the message to be forwarded.

[0142] The path determination module 230 is used to determine the target forwarding path based on the target session identifier and load-sharing path forwarding table corresponding to the message to be forwarded when it is determined that the message to be forwarded is a second type of protocol message.

[0143] The second type of protocol message is a message generated during the session data transmission process of the RoCE session. Each entry in the load-sharing path forwarding table includes a session identifier and the path to be used corresponding to that session identifier. The path to be used corresponding to a session identifier is determined before the session data transmission process of that session identifier based on the session information corresponding to that session identifier and a preset load-sharing algorithm.

[0144] The forwarding module 240 is used to forward the message to be forwarded according to the target forwarding path.

[0145] Please refer to Figure 15 , Figure 15 This is a second block diagram of the RoCE session-based load balancing device 200 provided in this embodiment. In this embodiment, the RoCE session-based load balancing device 200 may further include a path maintenance module 220. The path maintenance module 220 is used to, when determining that the packet to be forwarded is a first-type protocol packet, obtain a path to be used determined based on the packet to be forwarded and the preset load balancing algorithm, and store the determined path to be used and the target session identifier corresponding to the packet to be forwarded in the load balancing path forwarding table. The first-type protocol packet is a packet generated during the session connection creation process of a RoCE session.

[0146] In this embodiment, the path maintenance module 220 is further configured to delete the target entry corresponding to the target session identifier in the load-sharing path forwarding table when the message to be forwarded is a DisConnectReply protocol message in a RoCE session.

[0147] Optionally, the above modules can be stored in the form of software or firmware. Figure 4 The memory 110 shown is either stored in or embedded in the operating system (OS) of the electronic device 100, and can be used by... Figure 4 The processor 120 executes the program. Meanwhile, the data and program code required to execute the above modules can be stored in the memory 110.

[0148] This application also provides a readable storage medium storing a computer program thereon, which, when executed by a processor, implements the RoCE session-based load balancing method described above.

[0149] In summary, this application provides a load balancing method, apparatus, electronic device, and readable storage medium based on RoCE sessions. Upon receiving a message to be forwarded, if the message type identification determines it to be a second-type protocol message, a target forwarding path is determined based on the target session identifier and the load balancing path forwarding table corresponding to the message. The received message is then forwarded according to this target forwarding path. The second-type protocol message is a message transmitted during the session data transmission process of a RoCE session. Each entry in the load balancing path forwarding table includes a session identifier and a path to be used corresponding to that session identifier. The path to be used corresponding to a session identifier is determined before the session data transmission process of that session identifier, based on the session information and a preset load balancing algorithm. This method, upon receiving a message to be forwarded, forwards the message based on the routing results performed before the session data transmission process of the message. This reduces the likelihood of routing occurring during RoCE session data transmission, thereby reducing the need for message retransmission due to out-of-order delivery and improving RoCE transmission performance.

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

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

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

[0153] The above description is merely an optional embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A load balancing method based on RoCE sessions, characterized in that, The method includes: Receive the message to be forwarded and identify the type of the message to be forwarded; When it is determined that the message to be forwarded is a second type of protocol message, the target forwarding path is determined according to the target session identifier and the load balancing path forwarding table corresponding to the message to be forwarded. The second type of protocol message is a message in the session data transmission process of the RoCE session. Each entry in the load balancing path forwarding table includes a session identifier and the path to be used corresponding to the session identifier. The path to be used corresponding to a session identifier is determined before the session data transmission process corresponding to the session identifier based on the session information corresponding to the session identifier and the preset load balancing algorithm. The message to be forwarded is forwarded according to the target forwarding path.

2. The method according to claim 1, characterized in that, The method further includes: When it is determined that the message to be forwarded is a first type of protocol message, the path to be used is obtained based on the message to be forwarded and the preset load sharing algorithm, and the determined path to be used and the target session identifier corresponding to the message to be forwarded are stored in the load sharing path forwarding table. The first type of protocol message is a message in the session connection creation process of the RoCE session.

3. The method according to claim 2, characterized in that, The step of obtaining the path to be used determined based on the packet to be forwarded and the preset load balancing algorithm, and storing the determined path to be used and the target session identifier corresponding to the packet to be forwarded in the load balancing path forwarding table, includes: The message to be forwarded is sent to the central processing unit (CPU) so that the CPU can determine the target session identifier corresponding to the message to be forwarded based on the received message to be forwarded, and determine the path to be used corresponding to the target session identifier based on the received message to be forwarded and the preset load balancing algorithm. According to the first instruction received from the CPU, the target session identifier and the corresponding path to be used included in the first instruction are saved to the load-sharing path forwarding table.

4. The method according to claim 3, characterized in that, The step of sending the packet to be forwarded to the central processing unit (CPU) so that the CPU can determine the target session identifier corresponding to the packet to be forwarded based on the received packet, and determine the path to be used corresponding to the target session identifier according to the preset load balancing algorithm includes: The message to be forwarded, which is a ConnectRequest protocol message or a ConnectReply protocol message, is sent to the CPU so that the CPU can obtain the target session identifier and the corresponding path to be used according to the preset load sharing algorithm, the ConnectRequest protocol message and the ConnectReply protocol message. In particular, for the ConnectReply protocol message, an interception and forwarding method is adopted. Receive and forward the ConnectReply protocol message to be forwarded sent by the CPU after the first instruction.

5. The method according to claim 2, characterized in that, When determining that a route is not selected for the target session corresponding to the packet to be forwarded based on the target session information obtained from the packet to be forwarded, the step of determining the target forwarding path based on the target session identifier and load-sharing path forwarding table corresponding to the packet to be forwarded includes: Determine whether the target session identifier is included in the load-sharing path forwarding table; If the target session identifier is not included in the load-sharing path forwarding table, the transmission path obtained by performing a route lookup based on the packet to be forwarded will be used as the target forwarding path.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: If the message to be forwarded is a DisConnectReply protocol message in a RoCE session, delete the target entry corresponding to the target session identifier in the load balancing path forwarding table.

7. The method according to claim 6, characterized in that, In the case of the DisConnectReply protocol message in the RoCE session to be forwarded, deleting the target entry corresponding to the target session identifier in the load-sharing path forwarding table includes: When the message to be forwarded is a DisConnectReply protocol message, the message to be forwarded is sent to the CPU; The CPU receives a second instruction sent by the CPU according to the message to be forwarded as a DisConnectReply protocol message, and deletes the target entry corresponding to the target session identifier in the load balancing path forwarding table according to the second instruction.

8. A load balancing method based on RoCE sessions, characterized in that, The method includes: The network chip receives the message to be forwarded and identifies the type of the message to be forwarded; When the network chip determines that the packet to be forwarded is a second type of protocol packet, it determines the target forwarding path according to the target session identifier and the load balancing path forwarding table corresponding to the packet to be forwarded. The second type of protocol packet is a packet in the session data transmission process of the RoCE session. Each entry in the load balancing path forwarding table includes a session identifier and the path to be used corresponding to the session identifier. The path to be used corresponding to a session identifier is determined before the session data transmission process corresponding to the session identifier based on the session information corresponding to the session identifier and the preset load balancing algorithm. The network chip forwards the packet to be forwarded according to the target forwarding path.

9. The method according to claim 8, characterized in that, The method further includes: When the network chip determines that the message to be forwarded is a first type of protocol message, it forwards the message to be forwarded to the CPU. The first type of protocol message is a message in the session connection creation process of the RoCE session. The CPU obtains target session information based on the received packet to be forwarded, and determines whether it is the target session routing corresponding to the packet to be forwarded based on the target session information. When the CPU determines that the target session is the route to be selected, it selects the route according to the target session information and the preset load sharing algorithm, and sends the determined path to be used and the corresponding target session identifier to the load sharing path forwarding table. If the CPU determines that it is not to select a route for the target session, it will not select a route based on the target session information and the preset load-sharing algorithm.

10. A load-sharing device based on RoCE sessions, characterized in that, The device includes: An identification module is used to receive a message to be forwarded and identify the type of the message to be forwarded; The path determination module is used to determine the target forwarding path based on the target session identifier and the load-sharing path forwarding table when the message to be forwarded is determined to be a second type of protocol message. The second type of protocol message is a message in the session data transmission process of a RoCE session. Each entry in the load-sharing path forwarding table includes a session identifier and the path to be used corresponding to the session identifier. The path to be used corresponding to a session identifier is determined before the session data transmission process corresponding to the session identifier based on the session information corresponding to the session identifier and a preset load-sharing algorithm. The forwarding module is used to forward the message to be forwarded according to the target forwarding path.

Images