WO2015067118A1

WO2015067118A1 - Multiple protocol stack load balancing method and apparatus

Info

Publication number: WO2015067118A1
Application number: PCT/CN2014/088442
Authority: WO
Inventors: 文刘飞
Original assignee: 华为技术有限公司
Priority date: 2013-11-08
Filing date: 2014-10-13
Publication date: 2015-05-14
Also published as: CN104639578A; CN104639578B

Abstract

Disclosed in the present invention are a multiple protocol stack load balancing method and apparatus. The method comprises: creating a first socket in response to an application request, and deploying the first socket on all protocol stacks; receiving data packets requesting connection; judging the protocol type of the data packets requesting connection, and creating a second socket to establish a session connection if the protocol type is TCP; choosing one protocol stack for the second socket on the basis of the load condition of each protocol stack, creating a matching flow table on a network card on the basis of a shunt policy of the network card when the data packets of the second socket cannot be shunted, through a default shunt rule of the network card, to an RSS network card reception queue bound to the chosen protocol stack, and upon the reception of the data packets, shunting the received data packets of the second socket to the RSS network card reception queue; and completing data packets distribution between the second socket and the chosen protocol stack. By doing so, the present invention enables protocol stack load to balance and reduces the data distribution overhead of CPU in an environment of multiple protocol stacks by matching and combining load awareness of protocol stack and application with RSS network card reception/transmission queues and flow table.

Description

Multi-stack stack load balancing method and device

Technical field

The present invention relates to the field of communications technologies, and in particular, to a multi-protocol stack load balancing method and apparatus.

Background technique

The rapid development of cloud computing makes the computing work more and more concentrated in the data center, and the terminal is more to use the network to quickly send the requested task to the data center, so the terminal's demand for computing power is decreasing, but The demand for network capabilities is increasing. As a bridge between applications and physical networks, the protocol stack has not developed rapidly and has gradually become a bottleneck between the two. It has become inevitable that multiple protocol stacks combine to handle the expansion of single or multiple ports. At this time, the shunt algorithm is used to forward the data packets belonging to the same connection to different protocol stacks. Since all the protocol stacks share one distribution module, it is not really parallel processing, and it is easy to have performance bottlenecks at the distribution module.

Most commercial 10G network cards now have a shunt function such as RSS (Receive Side Scaling), which performs hardware shunting tasks by hashing received network packets based on triples/quintuples. The data packets belonging to the same connection are sent to the same RSS network card receiving queue of the network card, which is sent to the same protocol stack instance for processing. As shown in FIG. 1 , each network card interface 100 has multiple protocol stacks, such as protocol stack 0, protocol stack 1, protocol stack 2, and protocol stack 3. Each protocol stack is bound with at least one RSS network card receiving and sending queue. The RSS network card receiving queue is processed by the corresponding protocol stack. For example, a packet sent by a firewall gateway usually has the same IP (Internet Protocol). If the RSS offload of the network card is only based on source, destination IP, and protocol triplet, hashing is performed. The data packets of the same gateway are likely to be allocated to the same RSS network card receiving queue, which may cause overload of the protocol stack connected to the queue. Therefore, simple hash shunting based on packet-based triples/quintuples has the disadvantage of being unable to perform flexible load balancing distribution by sensing the real load situation of the protocol stack.

Summary of the invention

The embodiment of the invention provides a multi-protocol stack load balancing method and device, which can realize the protocol by combining the load sensing of the protocol stack and the application with the RSS network card receiving/transmitting queue and the flow table matching in the multi-protocol environment. Stack load balancing reduces CPU data distribution overhead.

The first aspect provides a multi-stack stack load balancing method, the method comprising: creating a first socket in response to a request of an application and deploying on all protocol stacks; receiving a data packet requesting connection; determining a data packet requesting connection Protocol type, if the protocol type is a transport control protocol, then: create a second socket to establish a session connection; select a protocol stack for the second socket according to the load condition of each protocol stack; in the second socket When the data packet cannot be offloaded to the receiver extended RSS network card receiving queue bound by the selected protocol stack by the default offloading rule of the network card, a matching flow table is created on the network card according to the network card's traffic off policy, and is received. After the data packet, the received second socket data packet is offloaded to the RSS network card receiving queue; the data distribution between the second socket and the selected protocol stack is performed.

In conjunction with the first aspect, in a first possible implementation manner of the first aspect, the method further includes: after the session ends, releasing the second socket, and deleting the matching flow table created on the network card.

In conjunction with the first aspect, in a second possible implementation of the first aspect, if the protocol type is a user datagram protocol, the protocol is processed by the protocol stack of the data packet requesting the connection.

In conjunction with the first aspect, in a third possible implementation of the first aspect, the network card and all protocol stacks are performed before the step of creating the first socket and deploying on all protocol stacks in response to the request of the application The initial configuration includes: reading and storing the hardware configuration information of the network card; obtaining user configuration information, forming a network card configuration policy in combination with the hardware configuration information, writing the network card; starting multiple protocol stacks, and according to the network card configuration policy, for each protocol The stack is bound to at least one RSS network card receiving queue and one RSS network card sending queue.

With reference to the first aspect, in a fourth possible implementation manner of the first aspect, the creating the first socket in response to the request of the application and deploying on all the protocol stacks includes: calling the application programming interface to create the first socket; After the first socket is created, the bind function is called to bind the first socket to a specific IP address, and the listen function is called to listen for the packet request of the specified port; when the listen method of the first socket is received, The first socket is deployed on all protocol stacks.

In conjunction with the first aspect, in a fifth possible implementation of the first aspect, the second The step of establishing a session connection by the socket includes: creating a second socket according to the actual situation of the network operation of each protocol stack.

With reference to the first aspect, in a sixth possible implementation manner of the first aspect, the step of creating a second socket to establish a session connection includes: transmitting, to the application, the data packet of the request connection sent by the received peer end; Create a second socket after applying the confirmation.

In conjunction with the first aspect, in a seventh possible implementation of the first aspect, the end of the session includes receiving and responding to the request issued by the application to release the second socket, or receiving and responding to the connection release request sent by the peer.

A second aspect provides a multi-protocol stack load balancing method, the method comprising: creating a first socket, and selecting a protocol stack for the first socket to establish a session connection according to a load condition of each protocol stack; The data packet of the first socket cannot be offloaded to the receiver extended RSS network card receiving queue bound by the protocol stack through the default offloading rule of the network card, and the matching flow table is created on the network card according to the network card's traffic off policy, and is received. After the data packet, the received data packet is offloaded to the RSS network card receiving queue; the data packet distribution between the first socket and the selected protocol stack is performed.

With reference to the second aspect, in a first possible implementation manner of the second aspect, the method further includes: after the session ends, releasing the first socket, and deleting the matching flow table created on the network card

With reference to the second aspect, in a second possible implementation manner of the second aspect, the network card and all the protocol stacks are initially configured before the first socket is created, including: reading and storing the hardware configuration information of the network card Obtain user configuration information, and combine the hardware configuration information to form a network card configuration policy, write the network card; start multiple protocol stacks, and bind at least one RSS network card receiving queue and one RSS network card to each protocol stack according to the network card configuration policy. queue.

With reference to the second aspect, in a third possible implementation manner of the second aspect, the end of the session includes receiving and responding to the request issued by the application for releasing the first socket, or receiving and responding to the connection release request sent by the peer end.

The third aspect provides a multi-instance protocol stack load balancing device, the device includes: a protocol stack module, a network card, a data distribution module, and a load balancing module, where the protocol stack module includes multiple protocol stacks, wherein: the data distribution module is configured to respond The application request creates the first socket and deploys it on all protocol stacks; the protocol stack module is configured to receive the data packet requesting the connection, determine the protocol type of the data packet requesting the connection; the data distribution module is used, if the protocol Type is the transport control protocol, then create a second socket to establish a session connection; load balancing module, For if the protocol type is a transmission control protocol, select a protocol stack for the second socket according to the load condition of each protocol stack, and the data packet of the second socket cannot be offloaded by the default traffic distribution rule of the network card. When the receiver bound to the selected protocol stack extends the RSS network card receiving queue, the matching flow table is created on the network card according to the network card's traffic distribution policy, and after receiving the data packet, the received second socket data is received. The packet is distributed to the RSS network card receiving queue; the data distribution module is further configured to perform data packet distribution between the second socket and the selected protocol stack.

With reference to the third aspect, in a first possible implementation manner of the third aspect, after the session ends, the protocol stack module is further configured to: control the selected protocol stack to release the second socket; the load balancing module is further used Delete the matching flow table created on the NIC.

With reference to the third aspect, in a second possible implementation manner of the third aspect, the protocol stack module is further configured to: if the protocol type is a user datagram protocol, control a protocol stack that receives the data packet requesting the connection to perform the protocol. deal with.

In conjunction with the third aspect, in a third possible implementation manner of the third aspect, the load balancing module is further configured to perform initial configuration on the network card and all protocol stacks, including: a hardware configuration specifically for reading and storing the network card. Information, obtain user configuration information and form a network card configuration policy in combination with hardware configuration information, and write the network card; the protocol stack module is also used to start multiple protocol stacks, and at least one RSS network card is bound to each protocol stack according to the network card configuration policy. The queue and an RSS NIC send queue.

With reference to the third aspect, in a fourth possible implementation manner of the third aspect, the data distribution module is configured to create a first socket and deploy on all protocol stacks in response to the request of the application, specifically: a data distribution module. A first socket is created in response to a notification that the application invokes the application programming interface, and receives a listen method call of the first socket. After the first socket is created, the application calls the bind function to bind the first socket. Set a specific IP address, and call the listen function to listen to the packet request of the specified port; the load balancing module is also used to notify each protocol stack to deploy the first socket on all protocol stacks.

In conjunction with the third aspect, in a fifth possible implementation manner of the third aspect, the data distribution module is configured to create a second socket to establish a session connection, specifically: a real situation for running according to a network of each protocol stack , create a second socket.

With reference to the third aspect, in a sixth possible implementation manner of the third aspect, the protocol stack module is configured to create a second socket to establish a session connection, specifically: a request for connecting the received peer to the connection The data packet is forwarded to the application; the data distribution module is used for application confirmation After creating the second socket.

With reference to the third aspect, in a seventh possible implementation manner of the third aspect, the data distribution module receives and responds to the request issued by the application for releasing the second socket, or the protocol stack module receives and responds to the connection sent by the peer end. Release the request to indicate the end of the session.

The fourth aspect provides a multi-instance protocol stack load balancing device, the device includes: a protocol stack module, a network card, a data distribution module, and a load balancing module, where the protocol stack module includes multiple protocol stacks, where: a data distribution module is used to create The first socket; the load balancing module is configured to select a protocol stack for the first socket according to the load condition of each protocol stack to establish a session connection, if the first socket data packet passes the default offload of the network card The rule cannot be offloaded to the receiver extended RSS network card receiving queue bound to the protocol stack. Then, according to the network card's traffic distribution policy, a matching flow table is created on the network card, and after receiving the data packet, the received data packet is offloaded to the RSS network card. The data distribution module is further configured to perform data packet distribution between the first socket and the selected protocol stack.

With reference to the fourth aspect, in a first possible implementation manner of the fourth aspect, after the session ends, the protocol stack module is configured to control the selected protocol stack to release the first socket; the load balancing module is further configured to delete A matching flow table created on the NIC.

With reference to the fourth aspect, in a second possible implementation manner of the fourth aspect, the load balancing module is further configured to perform initial configuration on the network card and all protocol stacks, including: a hardware configuration specifically for reading and storing the network card Information, obtain user configuration information and form a network card configuration policy in combination with hardware configuration information, and write the network card; the protocol stack module is also used to start multiple protocol stacks, and at least one RSS network card is bound to each protocol stack according to the network card configuration policy. The queue and an RSS NIC send queue.

With reference to the fourth aspect, in a third possible implementation manner of the fourth aspect, the data distribution module receives and responds to the request issued by the application for releasing the first socket, or the protocol stack module receives and responds to the connection sent by the peer end. Release the request to indicate the end of the session.

The multi-protocol stack load balancing method and apparatus provided by the embodiments of the present invention create a first socket and deploy it on all protocol stacks by responding to the request of the application; after receiving the data packet requesting the connection, if the data packet is requested to be connected The protocol type is the transport control protocol, then the second socket is created to establish a session connection; and according to the load condition of each protocol stack, a protocol stack is selected for the second socket, and the data packet of the second socket is used. When the default traffic distribution rule of the network card cannot be offloaded to the RSS network card receiving queue bound to the selected protocol stack, according to the network card The traffic policy creates a matching flow table on the network card, and offloads the received second socket data packet to the RSS network card receiving queue; thus, through the load sensing of the protocol stack and the application, and the RSS network card receiving, sending queue, and flow table The combination of matching, selecting the appropriate protocol stack for data processing, making the protocol processing fully parallel, improving the protocol processing capability, enabling load balancing of the protocol stack in a multi-protocol stack environment, and reducing the data distribution overhead of the CPU.

DRAWINGS

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly described below. It is obvious that the drawings in the following description are only some embodiments of the present invention. Other drawings may also be obtained from those of ordinary skill in the art in light of the inventive work. among them:

1 is a schematic structural diagram of a multi-protocol stack load balancing apparatus in the prior art;

2 is a schematic structural diagram of a multi-protocol stack load balancing apparatus according to a first embodiment of the present invention;

3 is a schematic structural diagram of a multi-protocol stack load balancing apparatus according to a second embodiment of the present invention;

4 is a schematic diagram of a multi-protocol stack load balancing method according to a first embodiment of the present invention;

FIG. 5 is a schematic flowchart of initialization of a multi-protocol stack load balancing method according to a first embodiment of the present invention; FIG.

6 is a schematic diagram of a multi-protocol stack load balancing method according to a second embodiment of the present invention;

FIG. 7 is still another schematic structural diagram of a multi-protocol stack load balancing apparatus according to a third embodiment of the present invention; FIG.

FIG. 8 is still another schematic structural diagram of a multi-stack stack load balancing apparatus according to a fourth embodiment of the present invention.

detailed description

The invention will now be described in detail in conjunction with the drawings and embodiments.

Referring first to FIG. 2, FIG. 2 is a schematic structural diagram of a multi-protocol stack load balancing apparatus according to a first embodiment of the present invention. As shown in FIG. 2, the multi-stack stack load balancing apparatus 10 includes: a protocol stack module 12, a data distribution module 13, a load balancing module 14, a network card 16, and a network card driver 17, wherein the protocol stack module 12 includes a plurality of protocol stacks 15 The network card 16 includes an RSS network card receiving and sending queue 18 and a matching flow table 19. The RSS network card receiving and sending queue 18 includes an RSS network card receiving queue. And the RSS network card is sent out.

In the present embodiment, the application 11 invokes the application programming interface to notify the data distribution module 13 to create the first socket. The data distribution module 13 is operative to create a first socket in response to the request of the application 11 and deploy it on all of the protocol stacks 15. The protocol stack module 12 is configured to receive the data packet requesting the connection, determine the protocol type of the data packet requesting the connection, and if the protocol type is UDP (User Datagram Protocol), control the protocol for receiving the data packet requesting the connection. The stack 15 performs protocol processing, although it may of course be handled by other protocol stacks in other embodiments of the invention. If the protocol type is TCP (Transmission Control Protocol), the data distribution module 13 is further configured to create a second socket to establish a session connection; and the load balancing module 14 is configured to load according to each protocol stack. Selecting a protocol stack 15 for the second socket, and when the data packet of the second socket cannot be offloaded to the RSS network card receiving queue bound to the selected protocol stack 15 by the default traffic distribution rule of the network card 16, according to the network card The offloading policy of 16 creates a matching flow table 19 on the network card 16, and after receiving the data packet, offloads the received data packet to the RSS network card receiving queue. In this way, through the load sensing of the protocol stack and the application, combined with the RSS network card receiving, sending queue, and flow table matching, the appropriate protocol stack is selected for data processing, so that the protocol processing is fully paralleled, and the protocol processing capability is improved. The data distribution module 13 is also used to perform packet distribution between the second socket and the selected protocol stack. After the session ends, the protocol stack module 12 is further configured to control the selected protocol stack 15 to release the second socket. The load balancing module 14 is further configured to delete the matching flow table 19 created on the network card 16. In this way, in the multi-protocol stack environment, through the load sensing of the protocol stack 15 and the application, combined with the RSS network card receiving and sending queue 18 and the flow table matching 19 of the network card 16, the load balancing of the protocol stack is realized, and the CPU is reduced. Central Processing Unit, central processor) Packet distribution overhead. The peer end may be other clients or servers in the network.

In this embodiment, the load balancing module 14 is further configured to perform initial configuration on the network card 16 and all the protocol stacks 15, including: specifically for reading and storing the hardware configuration information of the network card 16 through the network card driver 17 to obtain user configuration information. And combining the hardware configuration information to form a network card configuration policy, and writing the network card 16 through the network card driver 17; the protocol stack module 12 is further configured to start multiple protocol stacks 15, and bind at least one for each protocol stack 15 according to the network card configuration policy. The RSS network card receiving queue and an RSS network card sending queue. The hardware configuration information of the network card 16 includes the number of the RSS network card receiving and sending queues 18, and the maximum supported flow table matching number. The user configuration information includes the number of network card hardware queues to be opened, and the distribution policy of the data packets on the network card 16.

In this embodiment, the destination address of the first socket is any, indicating that this is a service. The socket on the side. After the first socket is successfully created, the application 11 calls the bind function to bind the first socket to the specified IP address, and listens for the packet request from the specified port by calling the listen function. When the bind and listen method calls are received, the data distribution module 13 notifies the load balancing module 14 that the socket is a server socket. The load balancing module 14 notifies each protocol stack 15 that the first socket is deployed on all the protocol stacks 15, and each protocol stack 15 has a first socket PCB (Protocol Control Block). . Among them, the PCB includes various variables involved in establishing the connection and processing of the data packet.

In this embodiment, the protocol stack module 12 receives the data packet of the request connection sent by the peer end, and the data distribution module 13 creates a second socket according to the actual situation of the network operation of each protocol stack 15. And notify the peer that the second socket is successfully created. If the creation is successful, the session connection is established, and the session can be performed; if the creation is unsuccessful, the establishment of the session connection fails, and the connection is interrupted. The actual situation of the network running of the protocol stack 15 includes whether the socket of the same port has been created, whether the number of sockets in the protocol stack 15 reaches the upper limit of the created socket, and the like. In other embodiments of the present invention, the protocol stack module 12 forwards the received data packet of the request connection sent by the opposite end to the application 11, and after the application 11 confirms, the data distribution module 13 creates a second socket and returns the result. Give the opposite end. When the load balancing module 14 selects a protocol stack 15 for the second socket, the protocol stack 15 is notified to create a corresponding PCB for the second socket. The data packet of the second socket is preferentially branched to the RSS network card receiving queue bound to the protocol stack 15 by the default offloading rule of the network card 16. If the data packet of the second socket cannot be offloaded to the RSS network card receiving queue bound by the protocol stack 15 through the default traffic distribution rule of the network card 16, the load balancing module 14 creates a match on the network card 16 according to the traffic distribution policy of the network card 16. The flow table 19, and after receiving the data packet, offloads the data packet that receives the second socket to the RSS network card receiving queue for processing the data packet, that is, the session with the peer end. In an embodiment of the present invention, packet splitting is preferably performed based on a quintuple/triple, and the default offloading rule is preferably a hash rule. In other embodiments of the present invention, other tuples may also be based on other tuples. For packet offloading, such as binary or quad. The ternary group information includes a destination port, a destination IP address, and a protocol content, and the quintuple information includes a source port, a destination port, a source IP address, a destination IP address, and a protocol content. In this embodiment, the data distribution module 13 further receives the data transmission request of the second socket and distributes it to the corresponding protocol stack 15; after the second socket is created, combined with the load balancing information, selects a protocol stack 15 The processing of the data packet is performed, and the processed network data packet is distributed to the second socket.

In this embodiment, the data distribution module 13 receives and responds to the release issued by the application 11. The request for the second socket, or the protocol stack 15 receives and responds to the connection release request sent by the opposite end, indicating that the session ends. If the data distribution module 13 receives and responds to the request for releasing the second socket issued by the application 11, notifying the corresponding protocol stack 15 to release the second socket and its associated PCB, and notifying the load balancing module 14 of the second The socket has been released; after receiving the second socket release notification of the data distribution module 13, the load balancing module 14 confirms whether the matching flow table 19 is created on the network card for the second socket, and if so, passes The NIC driver 17 is called to delete the matching stream table 19. If the protocol stack 15 receives and responds to the connection release request sent by the peer, the corresponding protocol stack 15 releases the second socket, and the data distribution module 13 notifies the application 11 and the load balancing module 14 that the second socket has been released. The load balancing module 14 reconfirms whether the matching flow table 19 has been created on the network card for the second socket, and if so, the matching flow table 19 is deleted by calling the network card driver 17.

Referring to FIG. 3, FIG. 3 is a schematic structural diagram of a multi-stack stack load balancing apparatus according to a second embodiment of the present invention. As shown in FIG. 3, the multi-stack stack load balancing device includes: a protocol stack module 22, a data distribution module 23, a load balancing module 24, a network card 26, and a network card driver 27. The protocol stack module 22 includes a plurality of protocol stacks 25, The network card 26 includes an RSS network card receiving and sending queue 28 and a matching flow table 29, and the RSS network card receiving and sending queue 28 includes an RSS network card receiving queue and an RSS network card sending queue.

In the present embodiment, the data distribution module 23 is configured to create a first socket in response to the notification that the application 21 invokes the application interface, each application 21 including at least one first socket. The load balancing module 24 is configured to select a protocol stack 25 for the first socket according to the load condition of each protocol stack 25, to establish a session connection with the peer end, if the first socket data packet passes the default of the network card 26 The offloading rule cannot be offloaded to the RSS network card receiving queue bound to the protocol stack 25. Then, the matching flow table 29 is created on the network card 26 according to the splitting policy of the network card 26, and after receiving the data packet, the received data packet is offloaded to the The RSS network card is on the queue. The data issuance module 23 is also used to perform packet distribution between the first socket and the selected protocol stack 25. After the session ends, the protocol stack module 22 is configured to control the selected protocol stack 25 to release the first socket, and the load balancing module 24 is further configured to delete the matching flow table 29 created on the network card 26. The peer end may be a server in the network.

In this embodiment, the load balancing module is further configured to initialize the network card and all the protocol stacks, including: specifically for reading and storing the hardware configuration information of the network card 26, acquiring user configuration information, and forming the hardware configuration information. The network card configuration policy is written into the network card 26 through the network card driver 27; the protocol stack module 22 is also used to start multiple protocol stacks 25, and is configured according to the network card. The policy is to bind at least one RSS network card receiving queue and one RSS network card sending queue to each protocol stack 25. The hardware configuration information of the network card 26 includes the number of the RSS network card receiving queues and the maximum supported flow table matching number, and the user configuration information includes the number of network card hardware queues to be opened and the data packet distribution policy on the network card 26.

In this embodiment, the protocol stack module 22 receives the data packet of the request connection sent by the peer end, and the data distribution module 23 returns a false result to the application 21 according to the actual situation of the network operation of each protocol stack 25, and notifies the peer end of the first result. Whether the socket is created successfully. If the creation is successful, a session connection is established and the session can be performed. If the creation is unsuccessful, the establishment of the session connection fails and the connection is broken. In other embodiments of the present invention, the protocol stack module 22 forwards the received data packet of the request connection sent by the opposite end to the application 21. After the application 21 confirms, the data distribution module 23 creates the first socket and returns the result. Give the opposite end. The data distribution module 23 simultaneously creates a corresponding PCB when creating the first socket. The actual situation of the network operation of the protocol stack 25 includes whether the socket of the same port has been created, whether the number of sockets in the protocol stack 25 reaches the upper limit of the created socket, and the like. The PCB includes the various variables involved in establishing the connection and the processing of the packet.

In this embodiment, after the first socket is successfully created, the application 21 calls the connect function to connect the IP address of a server to establish a connection with the port, which is the application of the client. After establishing a session connection with the peer end and receiving the data packet, the data packet of the first socket preferentially branches the data packet to the RSS network card receiving queue bound by the protocol stack 25 through the default traffic distribution rule of the network card 26. If the hashing rule of the network card 26 cannot be used to offload the data packet to the RSS network card receiving queue bound to the protocol stack 25, the matching flow table 29 is created on the network card 26 by the load balancing module 24 according to the traffic distribution policy of the network card 26. The received data packet is offloaded to the RSS network card receiving queue for processing the data packet, that is, the session is performed with the peer end. In other embodiments of the present invention, packet shunting is preferably performed based on a quintuple/triple, and the default shunting rule is preferably a hash rule. In other embodiments of the present invention, other elements may be based on other elements. Groups are used for packet offloading, such as binary or quad. The ternary group information includes a destination port, a destination IP address, and a protocol content, and the quintuple information includes a source port, a destination port, a source IP address, a destination IP address, and a protocol content. In this embodiment, the data distribution module 23 further receives the data transmission request of the first socket and distributes it to the corresponding protocol stack 25; after the first socket is created, combined with the load balancing information, selects a protocol stack 25 The processing of the data packet is performed, and the processed network data packet is distributed to the first socket.

In this embodiment, the data distribution module 23 receives and responds to the release issued by the application 21. A socket request, or the protocol stack 25 receives and responds to the connection release request sent by the peer, indicating that the session ends. If the data distribution module 23 receives and responds to the request for releasing the first socket issued by the application 21, notifying the selected protocol stack 25 to release the first socket and its associated PCB, and notifying the load balancing module 24 of the first The socket has been released; after receiving the first socket release notification of the data distribution module 23, the load balancing module 24 confirms whether the matching flow table 29 has been created on the network card 26 for the first socket, and if so, The matching flow table 29 is deleted by calling the network card driver 27. If the protocol stack 25 receives and responds to the connection release request sent by the peer, the protocol stack 25 releases the first socket, and the data distribution module 23 notifies the application 21 and the load balancing module 24 that the second socket has been released. The load balancing module 24 reconfirms whether a matching flow table 29 has been created on the network card for the second socket, and if so, the matching flow table 29 is deleted by invoking the network card driver 27.

In this embodiment, the data distribution module 23 creates a first socket to establish a session connection; the load balancing module 24 selects a protocol stack 25 for the first socket according to the load condition of each protocol stack 25; When the data packet of the socket cannot be offloaded to the RSS network card receiving queue bound to the protocol stack 25 by the default traffic sharing rule of the network card 26, the load balancing module 24 creates a matching flow table 29 on the network card 26 according to the traffic distribution policy of the network card 26. The received data packet is offloaded to the RSS network card receiving queue for packet processing. In this way, through the load sensing of the protocol stack and the application, combined with the RSS network card receiving, sending queue, and flow table matching, the appropriate protocol stack is selected for data processing, the protocol processing is fully paralleled, the protocol processing capability is improved, and the protocol can be multi-protocol. In the stack environment, load balancing of the protocol stack is implemented, which reduces the data distribution overhead of the CPU.

Referring to FIG. 4, FIG. 4 is a schematic diagram of a multi-protocol stack load balancing method according to a first embodiment of the present invention. As shown in FIG. 4, the multi-protocol stack load balancing method includes:

S10: Create a first socket in response to the application's request and deploy it on all protocol stacks.

Before performing S10, you need to initialize the NIC and all protocol stacks, as shown in Figure 5, including:

S101: Read and store hardware configuration information of the network card. The hardware configuration information includes the number of RSS queues and the maximum number of flow table matches that can be supported. The hardware configuration information needs to be read by the network card driver.

S102: Acquire user configuration information, and form a network card configuration policy according to the hardware configuration information, and write the network card. The user configuration information includes the number of network card hardware queues to be opened, and the distribution policy of the data packets on the network card. The network card configuration information is also written into the network card through the network card driver.

S103: Start multiple protocol stacks, and bind at least one RSS network card receiving queue and one RSS network card sending queue to each protocol stack according to the network card configuration policy.

After the first socket is successfully created, the application calls the bind function to bind the first socket to the specified IP address, and listens to the packet request from the specified port by calling the listen function.

When the listener method call of the first socket is received, the first socket is deployed on all protocol stacks, and each protocol stack has a first socket PCB. Among them, the PCB includes various variables involved in establishing the connection and processing of the data packet.

S11: Receive a data packet requesting connection.

S12: Determine the protocol type of the data packet requesting the connection. If the protocol type is the UDP protocol, S13 is performed; if the protocol type is the TCP protocol, S14 is performed.

S13: Perform protocol processing by the protocol stack that receives the data packet requesting the connection. In other embodiments of the invention, if the protocol type is the UDP protocol, it may also be handled by other protocol stacks.

S14: Create a second socket to establish a session connection.

In S14, the data packet of the request connection sent by the peer end is received, and the second socket is created according to the actual situation of the network operation of each protocol stack. And notify the peer that the second socket is successfully created. If the creation is successful, the session connection is established, and the session can be performed; if the creation is unsuccessful, the establishment of the session connection fails, and the connection is interrupted. In other embodiments of the present invention, the received data packet of the request connection sent by the peer end is forwarded to the application, and after the application is confirmed, the second socket is created, and the result is returned to the peer end.

S15: Select a protocol stack for the second socket according to the load condition of each protocol stack. At the same time, the protocol stack is notified to create a corresponding PCB for the second socket, thereby establishing a session connection with the peer.

S16: When the data packet of the second socket cannot be offloaded to the RSS network card receiving queue bound by the selected protocol stack by using the default traffic distribution rule of the network card, the matching flow table is created on the network card according to the network card's traffic distribution policy, and After receiving the data packet, the received second socket data packet is offloaded to the RSS network card receiving queue. In an embodiment of the present invention, packet splitting is preferably performed based on a quintuple/triple, and the default offloading rule is preferably a hash rule. In other embodiments of the present invention, other tuples may also be based on other tuples. For packet offloading, such as binary or quad. The ternary group information includes a destination port, a destination IP address, and a protocol content, and the quintuple information includes a source port, a destination port, a source IP address, a destination IP address, and a protocol content.

In S16, the data packet of the second socket is preferentially branched to the RSS network card receiving queue bound by the protocol stack by using the default offloading rule of the network card. If the default packet distribution rule of the network card cannot be used to offload the data packet of the second socket to the RSS network card receiving queue bound to the selected protocol stack, create a matching flow table on the network card according to the network card's traffic distribution policy, and receive the data packet. The second socket data packet is offloaded to the RSS network card receiving queue for processing the data packet, that is, the session with the peer end. In this way, in the multi-protocol stack environment, through the load sensing of the protocol stack and the application, combined with the RSS network card receiving, sending queue, and matching flow table, the appropriate protocol stack is selected for data processing, so that the protocol processing is fully paralleled and improved. The protocol processing capability enables load balancing of the protocol stack and reduces the data distribution overhead of the CPU.

S17: Perform packet distribution between the second socket and the selected protocol stack. In S17, the correspondence between the second socket and the selected protocol stack is also recorded.

S18: After the session ends, release the second socket and delete the matching flow table created on the network card.

In S18, receiving and responding to the request issued by the application to release the second socket, or receiving and responding to the connection release request sent by the peer end through the selected protocol stack indicates that the session ends. If receiving and responding to the request issued by the application to release the second socket, notifying the protocol stack to release the second socket and its associated PCB; confirming whether a matching flow table is created on the network card for the second socket, If there is, delete the matching flow table. If the connection release request sent by the peer end is received through the selected protocol stack, the selected protocol stack releases the second socket, and notifies the application that the second socket has been released, confirming whether the second socket is in the second socket. A matching flow table has been created on the NIC, and if there is, the matching flow table is deleted. The first socket is released only when there is no longer any communication connection between the client and the peer.

Referring to FIG. 6, FIG. 6 is a schematic diagram of a multi-protocol stack load balancing method according to a second embodiment of the present invention. As shown in FIG. 6, the multi-protocol stack load balancing method includes:

S21: Create a first socket, and select a protocol stack for the first socket to establish a session connection according to the load condition of each protocol stack.

Before performing S21, initial configuration of the network card and all protocol stacks, including: reading and storing the hardware configuration information of the network card through the network card driver; obtaining user configuration information, and forming a network card configuration policy by combining the hardware configuration information, and writing through the network card driver Incoming network card; starting multiple protocol stacks, and binding at least one RSS network card receiving queue and one RSS network card sending queue for each protocol stack according to the network card configuration policy.

The application calls the application programming interface to create the first socket and create the corresponding PCB. PCB This includes establishing connections and various variables involved in packet processing. After the first socket is successfully created, the application calls the connect function to connect to the IP address of a server and establish a connection with the port. This is the application as the client.

S22: If the data packet of the first socket cannot be offloaded to the RSS network card receiving queue bound by the protocol stack by using the default traffic distribution rule of the network card, create a matching flow table on the network card according to the network card's traffic distribution policy, and receive the matching flow table. After the data packet, the received data packet is offloaded to the RSS network card receiving queue. In an embodiment of the present invention, packet splitting is preferably performed based on a quintuple/triple, and the default offloading rule is preferably a hash rule. In other embodiments of the present invention, other tuples may also be based on other tuples. For packet offloading, such as binary or quad. The ternary group information includes a destination port, a destination IP address, and a protocol content, and the quintuple information includes a source port, a destination port, a source IP address, a destination IP address, and a protocol content.

In S22, the data packet of the first socket is preferentially branched to the RSS network card receiving queue bound by the protocol stack by using the default offloading rule of the network card. If the data of the first socket cannot be offloaded to the RSS network card receiving queue bound by the protocol stack through the hash rule of the network card, a matching flow table is created on the network card according to the network card's traffic distribution policy, and the received data packet is received. It is distributed to the RSS network card receiving queue for processing the data packet, that is, the session with the peer end. In this way, in the multi-protocol stack environment, through the load sensing of the protocol stack and the application, combined with the RSS network card receiving, sending queue, and matching flow table, the appropriate protocol stack is selected for data processing, so that the protocol processing is fully paralleled and improved. The protocol processing capability enables load balancing of the protocol stack and reduces the data distribution overhead of the CPU.

S23: Perform packet distribution between the first socket and the selected protocol stack. In S23, the correspondence between the first socket and the selected protocol stack is also recorded.

S24: After the session ends, release the first socket and delete the matching flow table created on the network card.

In S24, receiving and responding to the request issued by the application to release the second socket, or the protocol stack receiving and responding to the connection release request sent by the peer end indicates that the session ends. If the request for releasing the second socket issued by the application is received and responded, the protocol stack is notified to release the first socket and its associated protocol control block; and it is confirmed whether the matching stream is created on the network card for the first socket. Table, if any, deletes the matching flow table. If the protocol stack receives and responds to the connection release request sent by the peer, releases the first socket and notifies the application that the first socket has been released; and confirms whether the first socket has created a matching flow table on the network card. If there is, delete the matching flow table.

Please refer to FIG. 7. FIG. 7 is another embodiment of a multi-stack stack load balancing apparatus according to a third embodiment of the present invention. A schematic diagram of the structure. As shown in FIG. 7, the multi-stack stack load balancing apparatus 30 includes a processor 301, a memory 302, a receiver 303, and a bus 304. The processor 301, the memory 302, and the receiver 303 are connected by a bus 304. among them:

The processor 301 creates a first socket in response to the application's request and deploys the first socket on all of the protocol stacks. The receiver 303 receives the data packet requesting the connection. The processor 301 determines the protocol type of the data packet requesting the connection. If the protocol type is the TCP protocol, the processor 301 creates a second socket to establish a session connection; the processor 301 is configured according to the load condition of each protocol stack. The second socket selects a protocol stack; when the data packet of the second socket cannot be offloaded to the RSS network card receiving queue bound by the selected protocol stack by the default offloading rule of the network card, the processor 301 divides the traffic according to the network card. A matching flow table is created on the network card and the received second socket data packet is offloaded to the RSS network card receiving queue. The memory 302 records the correspondence between the second socket and the selected protocol stack. The processor 301 performs data packet distribution between the second socket and the selected protocol stack; after the session is completed, the protocol stack releases the second socket, and the processor 301 deletes the matching flow table created on the network card.

In this embodiment, the network card and all the protocol stacks need to be initialized. The memory 302 reads and stores the hardware configuration information of the network card, including the number of RSS queues and the maximum number of flow table matches that can be supported. The processor 301 acquires user configuration information, and forms a network card configuration policy in combination with the hardware configuration information, and writes the network card. The processor 301 starts a plurality of protocol stacks, and according to the network card configuration policy, at least one RSS network card receiving queue and one RSS network card sending queue are bound to each protocol stack. The user configuration information includes the number of network card hardware queues to be opened, and the distribution policy of data packets on the network card.

In this embodiment, when the processor 301 creates the first socket, a corresponding PCB is also created, wherein the PCB includes various variables involved in establishing the connection and processing the data packet. If the processor 301 determines that the protocol type is the UDP protocol, the protocol processing is performed by the protocol stack that receives the data packet requesting the connection, and in other embodiments of the present invention, it may also be processed by other protocol stacks.

The receiver 303 receives the data packet of the request connection sent by the peer end, and the processor 301 creates a second socket according to the actual situation of the network operation of each protocol stack. And notify the peer that the second socket is successfully created. If the creation is successful, the session connection is established, and the session can be performed; if the creation is unsuccessful, the establishment of the session connection fails, and the connection is interrupted. In other embodiments of the present invention, the receiver 303 forwards the data packet of the request connection sent by the received peer to the application, and after the application is confirmed, creates a second socket, and returns the result to the peer. Second socket data The packet priority is offloaded to the RSS network card receiving queue bound to the selected protocol stack by the default offloading rule of the network card; if the data of the second socket is passed the default offloading rule, the data cannot be offloaded to the RSS card bound to the selected protocol stack. On the queue, the processor 301 creates a matching flow table on the network card according to the traffic offloading policy of the network card, and after receiving the data packet, the receiver 301 offloads the received data packet of the second socket to the RSS network card receiving queue. In an embodiment of the present invention, packet splitting is preferably performed based on a quintuple/triple, and the default offloading rule is preferably a hash rule. In other embodiments of the present invention, other tuples may also be based on other tuples. For packet offloading, such as binary or quad.

In this embodiment, the receiver 303 receives the request for releasing the second socket issued by the application, or receives and responds to the connection release request sent by the peer end through the selected protocol stack, indicating that the session ends. If the receiver 303 receives the request issued by the application to release the second socket, the processor 301 responds to the request, and notifies the protocol stack to release the second socket; the processor 301 confirms whether the second socket is on the network card. A matching flow table has been created, and if so, the matching flow table is deleted. If the connection release request sent by the peer is received and responded to by the selected protocol stack, the selected protocol stack releases the second socket, and notifies the application that the second socket has been released, and the processor 301 confirms whether it is the second set. The connection creates a matching flow table on the NIC, and if so, deletes the matching flow table.

The method disclosed in the foregoing embodiments of the present invention may be applied to the processor 301 or implemented by the processor 301. Processor 301 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the foregoing method may be completed by an integrated logic circuit of hardware in the processor 301 or an instruction in a form of software. The processor 301 may be a general-purpose processor, a digital singal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or Other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps, and structural block diagrams disclosed in the embodiments of the present invention may be implemented or executed. The general purpose processor may be a microprocessor or the processor or any conventional processor or the like. The steps of the method disclosed in the embodiments of the present invention may be directly implemented by the hardware decoding processor, or may be performed by a combination of hardware and software modules in the decoding processor. The software module can be located in a conventional storage medium such as random access memory, flash memory, read only memory, programmable read only memory or electrically erasable programmable memory, registers, and the like. The storage medium is located in the memory 302, and the processor 301 reads the information in the memory 302 and completes the above with its hardware. The steps of the method.

Processor 301 may also be referred to as a CPU. Memory 302 can include read only memory and random access memory and provides instructions and data packets to processor 301. A portion of the memory 302 may also include a Non-Volatile Random Access Memory (NVRAM). The various components of device 30 are coupled together by a bus 304, which may include, in addition to the data bus, a power bus, a control bus, a status signal bus, and the like. The various buses are labeled as bus 304 in the figure.

Please refer to FIG. 8. FIG. 8 is still another schematic structural diagram of a multi-stack stack load balancing apparatus according to a fourth embodiment of the present invention. As shown in FIG. 8, the multi-stack stack load balancing device 40 includes a processor 401, a memory 402, a receiver 403, a bus 404, and a transmitter 405. The processor 401, the memory 402 and the receiver 403, and the transmitter 405 pass through a bus 404. Connected.

In this embodiment, the processor 401 creates a first socket and selects a protocol stack for the first socket to establish a session connection according to the load condition of each protocol stack. If the data packet of the first socket cannot be offloaded to the RSS network card receiving queue bound by the protocol stack by using the default traffic distribution rule of the network card, the processor 401 creates a matching flow table on the network card according to the network card's traffic distribution policy, and receives the matching flow table. After receiving the data packet, the device 403 offloads the received data packet to the RSS network card receiving queue. The memory 402 records the correspondence between the first socket and the selected protocol stack. The processor 401 performs packet distribution between the first socket and the selected protocol stack. After the session ends, the selected protocol stack releases the first socket, and the processor 401 deletes the matching flow table created on the network card.

In this embodiment, the network card and all protocol stacks need to be initialized. The memory 402 reads and stores the hardware configuration information of the network card, including the number of RSS queues and the maximum number of flow table matches that can be supported. The processor 401 acquires user configuration information, and forms a network card configuration policy in combination with the hardware configuration information, and writes the network card. The processor 401 starts a plurality of protocol stacks, and according to the network card configuration policy, at least one RSS network card receiving queue and one RSS network card sending queue are bound to each protocol stack. The user configuration information includes the number of network card hardware queues to be opened, and the distribution policy of data packets on the network card.

When the processor 401 creates the first socket, it also creates a corresponding PCB, which includes various connections involved in establishing the connection and processing of the data packet. Specifically, the receiver 403 receives the data packet of the request connection sent by the peer end, and the processor 401 returns a false result according to the actual situation of the network operation of each protocol stack, and notifies whether the first socket of the opposite end is successfully created. In other embodiments of the present invention, the receiver 403 converts the received data packet of the request sent by the opposite end to Give the application, create a first socket after the application is confirmed, and return the result to the peer. After the receiver 403 receives the data packet, the data packet of the first socket is preferentially branched to the RSS network card receiving queue bound by the selected protocol stack by using the default offloading rule of the network card; if the data packet of the first socket passes After the default offloading rule of the network card, the network card cannot be offloaded to the RSS network card receiving queue bound to the selected protocol stack, and the processor 401 creates a matching flow table for the data packet on the network card, and offloads the data packet to the RSS network card receiving queue. In an embodiment of the present invention, packet splitting is preferably performed based on a quintuple/triple, and the default offloading rule is preferably a hash rule. In other embodiments of the present invention, other tuples may also be based on other tuples. For packet offloading, such as binary or quad.

In this embodiment, the transmitter 405 is used to send connection requests and data packets. The receiver 403 is configured to receive a data packet. The receiver 403 receives the request issued by the application to release the second socket, or the protocol stack receives and responds to the connection release request sent by the opposite end, indicating that the session ends. If the receiver 403 receives the request issued by the application to release the second socket, the processor 401 responds to the request, and notifies the protocol stack to release the second socket; the processor 401 confirms whether the second socket is on the network card. A matching flow table has been created, and if so, the matching flow table is deleted. If the protocol stack receives and responds to the connection release request sent by the peer, the protocol stack releases the second socket and notifies the application that the second socket has been released, and the processor 401 confirms whether the second socket is created on the network card. Matches the flow table, if any, deletes the matching flow table.

The method disclosed in the foregoing embodiments of the present invention may be applied to the processor 401 or implemented by the processor 401. Processor 401 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the foregoing method may be completed by an integrated logic circuit of hardware in the processor 401 or an instruction in a form of software. The processor 401 described above may be a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, or discrete hardware. Component. The methods, steps, and logical block diagrams disclosed in the embodiments of the present invention may be implemented or carried out. The general purpose processor may be a microprocessor or the processor or any conventional processor or the like. The steps of the method disclosed in the embodiments of the present invention may be directly implemented by the hardware decoding processor, or may be performed by a combination of hardware and software modules in the decoding processor. The software module can be located in a conventional storage medium such as random access memory, flash memory, read only memory, programmable read only memory or electrically erasable programmable memory, registers, and the like. The storage medium is located in the memory 402, and the processor 401 reads the information in the memory 402 and performs the steps of the above method in combination with its hardware.

The processor 401 may also be referred to as a Central Processing Unit (CPU). Memory 402 can include read only memory and random access memory and provides instructions and data packets to processor 401. A portion of memory 402 may also include non-volatile random access memory (NVRAM). The various components of device 40 are coupled together by a bus 404, which may include, in addition to the data bus, a power bus, a control bus, a status signal bus, and the like. The various buses are labeled as bus 404 in the figure.

In summary, the present invention creates a first socket by responding to an application request and deploys it on all protocol stacks; after receiving a data packet requesting connection, if the protocol type of the data packet requesting the connection is a transmission control protocol, Then: create a second socket to establish a session connection; and select a protocol stack for the second socket according to the load condition of each protocol stack, and the data packet of the second socket cannot pass the default traffic distribution rule of the network card. When the flow is offloaded to the RSS network card receiving queue bound to the selected protocol stack, a matching flow table is created on the network card according to the network card's traffic distribution policy, and the received second socket data packet is offloaded to the RSS network card receiving queue; Through the load sensing of the protocol stack and the application, combined with the RSS network card receiving, sending queue, and flow table matching, the appropriate protocol stack is selected for data processing, the protocol processing is fully paralleled, the protocol processing capability is improved, and the multi-protocol stack can be In the environment, load balancing of the protocol stack is implemented, which reduces the data distribution overhead of the CPU.

The above is only the embodiment of the present invention, and is not intended to limit the scope of the invention, and the equivalent structure or equivalent process transformation of the present invention and the contents of the drawings may be directly or indirectly applied to other related technologies. The fields are all included in the scope of patent protection of the present invention.

Claims

A multi-stack stack load balancing method, the method comprising:

Create a first socket in response to the application's request and deploy it on all protocol stacks;

Receiving a data packet requesting connection;

Determining a protocol type of the data packet requesting the connection, if the protocol type is a transmission control protocol, then:

Create a second socket to establish a session connection;

Selecting a protocol stack for the second socket according to the load condition of each protocol stack;

When the data packet of the second socket cannot be offloaded to the receiver extended RSS network card receiving queue bound by the selected protocol stack by the default offloading rule of the network card, according to the traffic off policy of the network card Creating a matching flow table on the network card, and after receiving the data packet, offloading the received data packet of the second socket to the RSS network card receiving queue;

Performing packet distribution between the second socket and the selected protocol stack.
The method of claim 1 further comprising:

After the session ends, the second socket is released, and the matching flow table created on the network card is deleted.
The method of claim 1 wherein if the protocol type is a user datagram protocol:

The protocol is processed by the protocol stack that receives the data packet to which the request is connected.
The method according to claim 1, wherein the network card and all protocol stacks are initially configured before the step of responding to the request to create a first socket and deploying on all protocol stacks ,include:

Reading and storing hardware configuration information of the network card;

Obtaining user configuration information, and forming a network card configuration policy according to the hardware configuration information, and writing the network card;

A plurality of protocol stacks are started, and at least one RSS network card receiving queue and one RSS network card sending queue are bound to each protocol stack according to the network card configuration policy.
The method of claim 1, wherein the requesting the application to create the first socket and deploying on all of the protocol stacks comprises:

Calling an application programming interface to create the first socket;

After the first socket is created, the bind function is called to bind the first socket to a specific IP address, and the listen function is called to listen for a data packet request of the specified port;

When the listener method call of the first socket is received, the first socket is deployed on all protocol stacks.
The method of claim 1 wherein said step of creating a second socket to establish a session connection comprises:

The second socket is created according to the actual situation of the network operation of each protocol stack.
The method of claim 1 wherein said step of creating a second socket to establish a session connection comprises:

Transmitting, by the receiving peer, the data packet of the request connection to the application;

The second socket is created after the application is confirmed.
The method according to claim 1, wherein the ending of the session comprises receiving and responding to a request issued by the application to release the second socket, or receiving and responding to a connection release request sent by the opposite end.
A multi-stack stack load balancing method, the method comprising:

Creating a first socket, and selecting a protocol stack for the first socket to establish a session connection according to a load condition of each protocol stack;

And if the data packet of the first socket cannot be offloaded to the receiver extended RSS network card receiving queue bound by the selected protocol stack by using a default offloading rule of the network card, according to the splitting policy of the network card, Creating a matching flow table on the network card, and after receiving the data packet, offloading the received data packet to the RSS network card receiving queue;

Data packet distribution between the first socket and the selected protocol stack is performed.
The method of claim 9 further comprising:

After the session ends, the first socket is released, and the matching flow table created on the network card is deleted.
The method according to claim 9, wherein the initial configuration of the network card and all protocol stacks before the creating the first socket comprises:

Reading and storing hardware configuration information of the network card;

Obtaining user configuration information, and forming a network card configuration policy according to the hardware configuration information, and writing the network card;

A plurality of protocol stacks are started, and at least one RSS network card receiving queue and one RSS network card sending queue are bound to each protocol stack according to the network card configuration policy.
The method according to claim 9, wherein the end of the session comprises receiving and responding to a request issued by the application to release the first socket, or receiving and responding to the pair The connection release request sent by the terminal.
A multi-instance protocol stack load balancing device is characterized in that: the device comprises: a protocol stack module, a network card, a data distribution module and a load balancing module, wherein the protocol stack module comprises a plurality of protocol stacks, wherein:

The data distribution module is configured to create a first socket and deploy it on all protocol stacks in response to an application request;

The protocol stack module is configured to receive a data packet requesting connection, and determine a protocol type of the data packet requesting the connection;

The data distribution module is configured to: if the protocol type is a transmission control protocol, create a second socket to establish a session connection;

The load balancing module is configured to: if the protocol type is a transmission control protocol, select a protocol stack for the second socket according to a load condition of each protocol stack, and select the second socket in the second socket When the data packet of the word cannot be offloaded to the receiver extended RSS network card receiving queue bound to the selected protocol stack by using the default offloading rule of the network card, a matching flow is created on the network card according to the traffic off policy of the network card. a table, and after receiving the data packet, offloading the received data packet of the second socket to the RSS network card receiving queue;

The data distribution module is further configured to perform data packet distribution between the second socket and the selected protocol stack.
The apparatus according to claim 13, wherein after said session ends,

The protocol stack module is further configured to: control the selected protocol stack to release the second socket;

The load balancing module is further configured to delete the matching flow table created on the network card.
The device according to claim 13, wherein the protocol stack module is further configured to: if the protocol type is a user datagram protocol, control to receive the protocol stack of the data packet requesting the connection for protocol deal with.
The device according to claim 13, wherein the load balancing module is further configured to perform initial configuration on the network card and all protocol stacks, including: a hardware configuration specifically for reading and storing the network card. Obtaining user configuration information and forming a network card configuration policy in combination with the hardware configuration information, and writing the network card;

The protocol stack module is further configured to start multiple protocol stacks, and according to the network card configuration policy, at least one RSS network card receiving queue and one RSS network card binding are configured for each protocol stack. queue.
The device according to claim 13, wherein the data distribution module is configured to create a first socket in response to a request of the application and deploy it on all protocol stacks, specifically: the data distribution module is used for The first socket is created in response to a notification that the application invokes the application programming interface, and receives a listen method call of the first socket, wherein after the first socket is created, the application calls the bind function The first socket is bound to a specific IP address, and the listen function is called to listen to a data packet request of the specified port. The load balancing module is further configured to notify each protocol stack to deploy the first socket. All on the protocol stack.
The device according to claim 13, wherein the data distribution module is configured to create a second socket to establish a session connection, specifically, the method is: creating the foregoing according to actual conditions of network operation of each protocol stack. The second socket.
The device according to claim 13, wherein the protocol stack module is configured to create a second socket to establish a session connection, specifically: a data packet for connecting the request sent by the receiving peer end. Forwarding to the application; the data distribution module is configured to create the second socket after the application is confirmed.
The device according to claim 13, wherein the data distribution module receives and responds to a request issued by the application to release the second socket, or the protocol stack module receives and responds to the peer sending The connection release request indicates that the session ends.
A multi-instance protocol stack load balancing device is characterized in that: the device comprises: a protocol stack module, a network card, a data distribution module and a load balancing module, wherein the protocol stack module comprises a plurality of protocol stacks, wherein:

The data distribution module is configured to create a first socket;

The load balancing module is configured to select a protocol stack for the first socket to establish a session connection according to a load condition of each of the protocol stacks, if the data packet of the first socket passes the The default traffic distribution rule of the network card cannot be offloaded to the receiver extended RSS network card receiving queue bound to the selected protocol stack, and a matching flow table is created on the network card according to the network card's traffic distribution policy, and the data is received. After the packet, the received data packet is offloaded to the RSS network card receiving queue;

The data distribution module is further configured to perform data packet distribution between the first socket and the selected protocol stack.
The device of claim 21, wherein said session ends Rear,

The protocol stack module is configured to control the selected protocol stack to release the first socket;

The load balancing module is further configured to delete the matching flow table created on the network card.
The device according to claim 21, wherein the load balancing module is further configured to perform initial configuration on the network card and all protocol stacks, including: a hardware configuration specifically for reading and storing the network card. Obtaining user configuration information and forming a network card configuration policy in combination with the hardware configuration information, and writing the network card;

The protocol stack module is further configured to start multiple protocol stacks, and according to the network card configuration policy, at least one RSS network card receiving queue and one RSS network card sending queue are bound to each protocol stack.
The device according to claim 21, wherein the data distribution module receives and responds to a request issued by the application to release the first socket, or the protocol stack module receives and responds to the pair The connection release request sent by the terminal indicates that the session ends.