WO2015143904A1

WO2015143904A1 - Method for managing parallel user mode protocol stacks and protocol stack system

Info

Publication number: WO2015143904A1
Application number: PCT/CN2014/095248
Authority: WO
Inventors: 戴芬
Original assignee: 华为技术有限公司
Priority date: 2014-03-28
Filing date: 2014-12-29
Publication date: 2015-10-01
Also published as: CN104951357A; CN104951357B

Abstract

Embodiments of the present invention provide a method for managing parallel user mode protocol stacks and a protocol stack system, and the method comprises: monitoring the running state of the instance corresponding to each protocol stack of the user mode protocol stacks, one instance corresponding to one protocol stack of the user mode protocol stacks; determining a first instance and a second instance, wherein the first instance is the instance in an abnormal running state, and the second instance has the capability of moving into at least one load to be migrated in the first instance; and re-establishing the at least one load to be migrated in the second instance according to a PCB in a shared resource pool, wherein the PCB corresponds to the at least one load to be migrated in the first instance. In the embodiments of the present invention, as the load to be migrated is reestablished in the instance with the capacity of moving into the load according to the PCB in the shared resource pool, wherein the PCB corresponds to the load to be migrated in the abnormal instance, the system distributing bottleneck caused by the protocol stacks sharing one distributing module is overcome, and the load balance and failure recovery are quickly performed, and therefore the performance of the protocol stack system is improved.

Description

Parallel user state protocol stack management method and protocol stack system

Technical field

Embodiments of the present invention relate to the field of computers, and, more particularly, to a management method and a protocol stack system for a parallel user state protocol stack.

Background technique

With the development of Ethernet technology, the emergence and popularity of 10G and 40G network cards, the traditional single-core based protocol stack has been unable to meet the needs of network card speed. In addition, the processor architecture has evolved from emphasizing high-frequency single-processors to multi-core multi-processors, and the parallel processing power of computers is growing.

In the prior art, when a data packet is distributed among multiple protocol stack instances, a public distribution module is used to distribute data as a granularity. The distribution module may become a distribution bottleneck of the system, and needs maintenance during load balancing and load failure recovery. A large amount of data consumes a lot of system time, which is not conducive to the rapid recovery of the connection data of the load. How to quickly perform load balancing and fault recovery in the parallel protocol stack is a problem that needs to be considered.

Summary of the invention

The embodiment of the invention provides a management method and a protocol stack system for a parallel user state protocol stack, which can overcome the system distribution bottleneck caused by a distribution module sharing a distribution module, quickly perform load balancing and fault recovery, and improve performance of the protocol stack system.

In a first aspect, a method for managing a parallel user state protocol stack is provided. The method includes: monitoring an operating state of an instance corresponding to each protocol stack in a user state protocol stack, where the instance corresponds to the user state protocol stack. a protocol stack; the first instance and the second instance are determined, wherein the first instance is an instance of an abnormal running state, and the second instance has the capability of migrating to at least one load to be migrated in the first instance, and the load to be migrated Corresponding to a protocol control block PCB in the protocol stack corresponding to the first instance, the PCB corresponds to a PCB storing the load connection parameters to be migrated in the shared resource pool, and the connection parameter of the load to be migrated can be used for Rebuilding the load to be migrated; and reconstructing the at least one load to be migrated in the second instance according to the PCB corresponding to the at least one load to be migrated in the shared resource pool in the first instance.

With reference to the first aspect, in a first possible implementation, the protocol control block PCB corresponding to the at least one load to be migrated in the shared resource pool according to the first instance rebuilds the at least one in the second instance Before the load is to be migrated, the method further includes: determining at least one load to be migrated in the first instance.

With reference to the first possible implementation manner of the first aspect, in a second possible implementation manner, the running state of the instance includes a load state and a survival state of the instance, where each protocol stack in the monitoring user state protocol stack corresponds to The running state of the instance includes: sending a heartbeat message to the instance corresponding to each protocol stack in the user state protocol stack, and monitoring the heartbeat message response delay, and monitoring an instance corresponding to each protocol stack in the user state protocol stack. An instance load average value for a predetermined time period to determine an operation state of an instance corresponding to each protocol stack in the user mode protocol stack according to the response delay of the heartbeat message and the instance load average value, wherein one heartbeat message corresponds to one An instance identifier of the instance corresponding to each protocol stack in the user-mode protocol stack is separately polled, and an instance load average of the instance corresponding to each protocol stack in the user-mode protocol stack in the first predetermined time is monitored. Determining, according to the instance identifier and the instance load average, an operation state of an instance corresponding to each protocol stack in the user state protocol stack, In the instance identifier is used to represent instances of a viable state, the instance identifier is stored in the shared memory region or a shared file, an identifier which corresponds to one example of the instance.

With reference to the second possible implementation manner of the first aspect, in a third possible implementation manner, determining that the first instance is specifically implemented as: determining an example that the heartbeat response is not fed back after the second predetermined time is reached after the heartbeat message is sent. For the first instance; or, determining that the instance identifier indicates a dead or dead state in the first predetermined time is the first instance.

In conjunction with the third possible implementation of the first aspect, in a fourth possible implementation, determining that the second instance is specifically implemented to create and determine that the new instance is the second instance; The protocol control block PCB corresponding to the at least one load to be migrated in the shared resource pool rebuilds the at least one load to be migrated in the second instance, and is implemented as: according to the first load of the at least one load to be migrated in the shared resource pool The first PCB corresponding to the first PCB implements the docking of the first load with the upper layer service of the user state protocol stack in the second instance, and expands the first load end of the first load bound in the first instance. The RSS queue is rebinded into the first load of the second instance, wherein the at least one load to be migrated includes all loads of the first instance.

In conjunction with the fourth possible implementation of the first aspect, in a fifth possible implementation, the method further includes: terminating the first instance.

In conjunction with the second possible implementation of the first aspect, in a sixth possible implementation, Determining that the first instance is specifically implemented is: determining that the instance total load average value in the first predetermined time is greater than the first predetermined threshold is the first instance.

With reference to the sixth possible implementation manner of the first aspect, in a seventh possible implementation manner, determining that the second instance is specifically implemented as: if there is an instance that the average total load of the instance is lower than the second predetermined threshold in the first predetermined time And determining, as the second instance, one or more instances in which the average total load of the instance in the first predetermined time is lower than a second predetermined threshold, wherein a load value of all loads moved into the second instance is related to the second predetermined The sum of the thresholds is less than the first predetermined threshold.

In conjunction with the seventh possible implementation of the first aspect, in an eighth possible implementation, the protocol control block PCB corresponding to the at least one load to be migrated in the shared resource pool in the first instance is in the second The rebuilding the at least one load to be migrated in the example is implemented as follows: the second load corresponding to the second load of the at least one load to be migrated in the first instance is in the second PCB corresponding to the shared resource pool, and the second load is in the first The binding rule of the second RSS queue bound in the instance is modified to be bound to the second load of the second instance, so that the second instance implements a process of receiving and processing data packets from the second RSS queue; Or, according to the second PCB corresponding to the second load of the at least one load to be migrated in the first instance, the second load is bound in the first instance in the first instance. a second RSS queue, and binding the second RSS queue to the second payload in the second instance, such that the second instance implements a process of receiving and processing data packets from the second RSS queue.

With reference to the seventh possible implementation manner of the first aspect or the eighth possible implementation manner of the first aspect, in a ninth possible implementation manner, determining that the at least one to-be-migrated load in the first instance is specifically implemented as Determining that the third load in the first instance is the load to be migrated of the first instance, where the third RSS queue bound by the third load in the first instance satisfies the following condition: when the third RSS queue When the second instance is bound to the second instance, at least two of the three parameters of the number of connections, the number of received bytes, and the number of transmitted bytes are not greater than the corresponding parameters of the first instance.

With reference to the sixth possible implementation manner of the first aspect, in the tenth possible implementation manner, determining that the second instance is specifically implemented is: if there is no instance in which the total instance load average value is lower than the second predetermined threshold in a predetermined time, Then create and determine the new instance as the second instance.

With reference to the tenth possible implementation manner of the first aspect, in an eleventh possible implementation manner, the protocol control block PCB corresponding to the at least one load to be migrated in the shared resource pool in the first instance is in the first Rebuilding the at least one load to be migrated in the second instance is implemented as: the second PCB corresponding to the second load of the load to be migrated according to the first instance in the shared resource pool In the second instance, the second load is connected to the upper layer service of the user state protocol stack to enable the second instance to implement the interaction of the application app corresponding to the second load, and the first instance is released in the first instance. The second load is bound to the second RSS queue bound in the first instance, and the second RSS queue is bound to the second load in the second instance, such that the second instance is implemented from the second RSS The process of receiving and processing data packets by the queue.

With reference to the tenth possible implementation manner of the first aspect, or the eleventh possible implementation manner of the first aspect, in the twelfth possible implementation manner, determining that at least one load to be migrated in the first instance is specific The implementation is as follows: determining that the third load in the first instance is the load to be migrated of the first instance, and the third RSS queue bound by the third load in the first instance satisfies the following condition: the third RSS queue The average of the corresponding parameters among all the loads of the first instance is reached in the three parameters of the number of connections, the number of received bytes, and the number of bytes sent.

In a second aspect, a protocol stack system is provided, the system includes: a monitoring unit, configured to monitor an operating state of each protocol stack in a user state protocol stack of the protocol stack system, and the instance corresponds to the user state protocol a protocol stack in the stack, the determining unit, configured to determine the first instance and the second instance, where the first instance is an instance of a running state exception, and the second instance has at least one load to be migrated into the first instance Capabilities, a load to be migrated corresponds to a protocol control block PCB in a protocol stack corresponding to the first instance, and the PCB corresponds to a connection parameter storing the load to be migrated in a shared resource pool of the protocol stack system. The PCB, the connection parameter of the load to be migrated can be used to reconstruct the load to be migrated; the load migration unit is configured to: according to the PCB in the first instance, the corresponding PCB in the shared resource pool is in the second Rebuilding the at least one load to be migrated in the instance.

In conjunction with the second aspect, in a first possible implementation, the determining unit is further configured to determine at least one load to be migrated in the first instance.

With reference to the first possible implementation manner of the second aspect, in a second possible implementation manner, the running state of the instance includes a load state and a survival state of the instance, where the monitoring unit is specifically configured to: respectively: to the user state protocol The instance corresponding to each protocol stack in the stack sends a heartbeat message and monitors the heartbeat message response delay, and monitors an instance load average of the instance corresponding to each protocol stack in the user state protocol stack in the first predetermined time, according to the The response delay of the heartbeat message and the average value of the instance load determine the running state of the instance corresponding to each protocol stack in the user state protocol stack, where one heartbeat message corresponds to one instance; or, the user state protocol stack is polled separately An instance identifier of an instance corresponding to each protocol stack, and monitoring an instance corresponding to each protocol stack in the user state protocol stack in the first pre- An instance load average value for determining the running state of the instance corresponding to each protocol stack in the user mode protocol stack according to the instance identifier and the instance load average value, where the instance identifier is used to indicate the survival state of the instance, The instance identifier is stored in a shared memory area or a shared file, and one instance identifier corresponds to one instance.

With reference to the second possible implementation of the second aspect, in a third possible implementation, in the process for determining the first instance, the determining unit is specifically configured to: determine that the distance to send the heartbeat message reaches the second time An example in which the heartbeat response is still not fed back after the predetermined time is the first instance; or an instance in which the instance identifier indicates a dead or dead state in the first predetermined time is the first instance.

In conjunction with the third possible implementation of the second aspect, in a fourth possible implementation, in the process for determining the second instance, the determining unit is specifically configured to create and determine a new instance as the second The load migration unit is configured to implement, in the second instance, the first load and the upper layer of the user state protocol stack according to the first PCB corresponding to the first load of the at least one load to be migrated in the shared resource pool. Interfacing the service, and rebinding the first receiver extended RSS queue bound by the first load in the first instance to the first load of the second instance, where the at least one load to be migrated includes All loads of this first instance.

In conjunction with the fourth possible implementation of the second aspect, in a fifth possible implementation, the system further includes: an instance stopping unit, configured to terminate the first instance.

With reference to the second possible implementation of the second aspect, in a sixth possible implementation, in the process for determining the first instance, the determining unit is specifically configured to: determine the total load of the instance in the first predetermined time An example where the mean is greater than the first predetermined threshold is the first instance.

With reference to the sixth possible implementation of the second aspect, in a seventh possible implementation, in the process for determining the second instance, the determining unit is specifically configured to: if there is an instance in the first predetermined time The instance in which the total load average is lower than the second predetermined threshold determines one or more instances in which the instance total load average is lower than the second predetermined threshold within the predetermined time as the second instance, wherein all loads moved into the second instance The sum of the load value and the second predetermined threshold is less than the first predetermined threshold.

With reference to the seventh possible implementation of the second aspect, in an eighth possible implementation, the load migration unit is specifically configured to: use the second load of the at least one load to be migrated according to the first instance in the shared resource The second PCB corresponding to the pool, the binding rule of the second RSS queue bound by the second load in the first instance is modified to be bound to the second load of the second instance, so that the first The second instance implements a process of receiving and processing data packets from the second RSS queue; or According to the second load of the at least one load to be migrated of the first instance in the shared resource pool, in the first instance, the second load is bound in the second instance. An RSS queue, and binding the second RSS queue to the second payload in the second instance, such that the second instance implements a process of receiving and processing data packets from the second RSS queue.

With reference to the seventh possible implementation of the second aspect or the eighth possible implementation manner of the second aspect, in the ninth possible implementation manner, at least one load to be migrated is determined in the first instance The determining unit is specifically configured to: determine that the third load in the first instance is the to-be-migrated load of the first instance, where the third load is satisfied in the third RSS queue bound in the first instance. The following condition: when the third RSS queue is bound to the second instance, at least two parameters of the connection number, the number of received bytes, and the number of bytes sent by the second instance are not greater than the first instance. Corresponding parameters. Determining that the at least one load to be migrated in the first instance is specifically implemented as: determining that the third load in the first instance is the load to be migrated of the first instance, where the third load is bound in the first instance The third RSS queue satisfies the following condition: when the third RSS queue is bound to the second instance, at least two parameters of the connection number, the number of received bytes, and the number of bytes sent by the second instance are not Greater than the corresponding parameter of the first instance.

In conjunction with the sixth possible implementation of the second aspect, in a tenth possible implementation, in the process for determining the second instance, the determining unit is specifically configured to: if there is no total load of the instance within a predetermined time If the mean is below the second predetermined threshold, then a new instance is created and determined to be the second instance.

With reference to the tenth possible implementation manner of the second aspect, in the eleventh possible implementation, the load migration unit is specifically configured to: use the second load of the at least one load to be migrated according to the first instance in the sharing The second PCB corresponding to the resource pool in the second instance implements the docking of the second load with the upper layer service of the user state protocol stack to enable the second instance to implement the interaction of the application app corresponding to the second load. And in the first instance, the second RSS queue bound by the second load in the first instance is released, and the second RSS queue is bound to the second load in the second instance, so that the The second example implements a process of receiving and processing data packets from the second RSS queue. Reconstructing the at least one load to be migrated in the second instance according to the protocol control block PCB corresponding to the at least one load to be migrated in the shared resource pool is implemented as follows: at least one to be migrated according to the first instance The second PCB corresponding to the load in the shared resource pool in the second instance implements the docking of the second load with the upper layer service of the user state protocol stack to enable the second instance to implement the second Load the interaction of the app app and solve it in the first instance In addition to the second RSS queue bound by the second payload in the first instance, the second RSS queue is bound to the second payload in the second instance, such that the second instance is implemented from the first The process of receiving and processing data packets by the second RSS queue.

With reference to the tenth possible implementation manner of the second aspect or the eleventh possible implementation manner of the second aspect, in the twelfth possible implementation manner, at least one to be used in determining the first instance In the process of migrating the load, the determining unit is specifically used to:

Determining that the third load in the first instance is the load to be migrated of the first instance, and the third RSS queue bound by the third load in the first instance satisfies the following condition: the number of connections of the third RSS queue The average of the corresponding parameters in all the loads of the first instance is reached in the three parameters of the number of received bytes and the number of transmitted bytes. Determining that the at least one load to be migrated in the first instance is specifically implemented as: determining that the third load in the first instance is a load to be migrated of the first instance, where the third load is bound in the first instance The third RSS queue satisfies the following conditions: the number of connections, the number of received bytes, and the number of transmitted bytes of the third RSS queue reach the mean of the corresponding parameters in all the loads of the first instance.

Based on the foregoing technical solution, the management method and the protocol stack system of the parallel user state protocol stack in the embodiment of the present invention rebuild the migration to be performed in the instance with the load-bearing capability according to the PCB corresponding to the shared resource pool according to the load to be migrated in the abnormal instance. The load can overcome the system distribution bottleneck caused by the protocol stack sharing a distribution module, and quickly perform load balancing and fault recovery, thereby improving the performance of the protocol stack system.

DRAWINGS

In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments or the prior art description will be briefly described below. Obviously, the drawings in the following description are only some of the present invention. For the embodiments, those skilled in the art can obtain other drawings according to the drawings without any creative work.

FIG. 1 is a flowchart of a method for managing a parallel user state protocol stack according to an embodiment of the present invention.

2 is a flow chart of another management method of a parallel user state protocol stack according to an embodiment of the present invention.

FIG. 3 is a schematic flowchart of fault thread recovery according to an embodiment of the present invention.

4 is a schematic flow chart of thread load balancing according to an embodiment of the present invention.

FIG. 5 is another schematic flowchart of thread load balancing according to an embodiment of the present invention.

FIG. 6 is a schematic structural diagram of a protocol stack system according to an embodiment of the present invention.

FIG. 7 is another schematic structural diagram of a protocol stack system according to an embodiment of the present invention.

FIG. 8 is a schematic diagram of still another structure of a protocol stack system according to an embodiment of the present invention.

detailed description

The technical solutions in the embodiments of the present invention are clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the present invention. It is obvious that the described embodiments are a part of the embodiments of the present invention, but not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative efforts are within the scope of the present invention.

In order to facilitate the understanding of the embodiments of the present invention, several elements introduced in the description of the embodiments of the present invention are first described herein.

User Stack and Kernel Stack: When the kernel creates a process/thread, it creates a stack for the process/thread. Each process/thread has two stacks, a user stack, which exists in user space, and a kernel stack that exists in kernel space. When the process/thread runs in user space, the contents of the cpu stack pointer register are the user stack address, using the user stack; when the process/thread is in kernel space, the contents of the cpu stack pointer register are the kernel stack space address, using the kernel Stack.

User State Protocol Stack: A protocol stack is a module that is usually included in the network processing part of the operating system. When the process/thread associated with the network processing part is running in the user space, the protocol stack pointed to by the cpu stack pointer register is the user mode protocol stack. In the embodiment of the present invention, the user mode protocol stack refers to all protocol stacks running in the user space. Collection.

Number of connections: The number of connections. The connection is the ultimate carrier of the CPU load and is intuitive. Moreover, when the receiving end (Recv) receives the data, it needs to perform connection lookup and then transfer to the connection state processing. Therefore, it is meaningful to balance the number of thread connections of each protocol stack to optimize the search speed.

Recv Bytes: Receive Side Scaling (RSS) itself is mainly for Packet transmission of Recv. Therefore, the amount of data received by the packet can reflect the impact on the protocol stack thread load.

Send Bytes: Send Packets are affected by the relationship between the Recv data and the connection affinity, and also affect the Send load of the protocol stack processing related connections.

1 is a flowchart of a processing method of a parallel protocol stack according to an embodiment of the present invention, and the method of FIG. 1 is executed by a protocol stack system.

101. Monitor an operating state of an instance corresponding to each protocol stack in the user state protocol stack.

One of the instances corresponds to a protocol stack in the user state protocol stack.

It should be understood that in an embodiment of the present invention, an instance may be a process or a thread within a protocol stack system. When the kernel creates a process/thread, it creates a stack for the process/thread. Each process/thread has two stacks, a user stack, which exists in user space, and a kernel stack that exists in kernel space.

It should be understood that in the embodiment of the present invention, the user state protocol stack is used to represent all protocol stacks existing in the user space. In the user state protocol stack, one or more protocol stacks may be included, and each protocol stack forms a one-to-one correspondence with an instance of the protocol stack system.

It should be understood that, in the embodiment of the present invention, the running state of the instance includes the load state and the survival state of the instance.

It should be understood that the load status of the instance refers to the occupancy of the system resources by the current instance, and generally refers to the resource utilization of the CPU by the instance.

102. Determine a first instance and a second instance.

The first instance is an instance of a running state abnormality, and the second instance has a capability of moving into at least one load to be migrated in the first instance.

In addition, a load to be migrated corresponds to a protocol control block PCB in the protocol stack corresponding to the first instance, and the PCB corresponds to a PCB storing the connection parameters of the load to be migrated in the shared resource pool. The connection parameters of the migration load can be used to reconstruct the load to be migrated.

It should be understood that, in the embodiment of the present invention, one load corresponds to one PCB, and one load is equal in data processing to the data processing amount of the connection corresponding to one PCB.

When an instance is created and initialized, a protocol stack is generated accordingly. If there is no load in the instance, there will be no PCB information in the protocol stack. There are several loads in the instance, and there will be the same number of PCBs in the corresponding protocol stack.

In addition, in the embodiment of the present invention, the protocol stack only stores some basic information of the PCB, such as a PCB identifier. The shared resource pool stores the key data structure of the PCB, mainly including the connection structure information, which has a key role for quick response recovery connection.

It should be understood that instances of operational state anomalies may generally include instances of surviving state anomalies or instances of load state anomalies.

Examples of abnormal state of survival may include instances of zombie or failure.

An instance of a load state exception can include an instance of a load high bit operation. In judging whether the instance is When the load is running high, the relationship between the instance total load average and the predetermined threshold can be compared to determine whether the instance is in the load high operating state.

103. The protocol control block PCB corresponding to the at least one load to be migrated in the shared resource pool in the first instance rebuilds the at least one to be migrated load in the second instance.

In the embodiment of the present invention, according to the load to be migrated in the abnormal instance, the PCB corresponding to the shared resource pool rebuilds the load to be migrated in the instance with the load-bearing capability, which can overcome the system distribution bottleneck caused by the protocol stack sharing a distribution module. Perform load balancing and fault recovery to improve the performance of the protocol stack system.

2 is a flow chart of another management method of a parallel user state protocol stack according to an embodiment of the present invention. Optionally, as shown in FIG. 2, before step 103, the method may further include step 104: determining at least one load to be migrated in the first instance.

Optionally, the step 101 is specifically implemented to: send a heartbeat message to the instance corresponding to each protocol stack in the user state protocol stack, monitor the heartbeat message response delay, and monitor each protocol stack in the user state protocol stack. The instance load average of the corresponding instance in the first predetermined time, to determine the running state of the instance corresponding to each protocol stack in the user state protocol stack according to the response delay of the heartbeat message and the average value of the instance load, wherein a heartbeat The message corresponds to one instance; or, respectively, the instance identifier of the instance corresponding to each protocol stack in the user state protocol stack is polled, and the instance corresponding to each protocol stack in the user state protocol stack is monitored in the first predetermined time. The instance load average value is used to determine an running state of an instance corresponding to each protocol stack in the user mode protocol stack according to the instance identifier and the instance load average value, where the instance identifier is used to indicate a survival state of the instance, and the instance identifier is stored. For a shared memory area or shared file, one instance ID corresponds to one instance.

Optionally, as an embodiment, determining, in step 102, the first instance is specifically implemented as: determining that an instance of the heartbeat response is not fed back after the second predetermined time is sent after the time when the heartbeat message is sent is the first instance; or determining the first An instance of the instance identifier indicating a dead or dead state within a predetermined time is the first instance.

In this embodiment, the step 102 determines that the process of the second instance is specifically implemented as: creating and determining that the new instance is the second instance. In this case, the step 103 is implemented as follows: the first PCB corresponding to the first load in the shared resource pool according to the first load of the at least one load to be migrated implements the first load and the upper layer of the user state protocol stack in the second instance. Interfacing the service, and rebinding the first receiver extended RSS queue bound by the first load in the first instance to the first load of the second instance, where the at least one load to be migrated includes All loads of this first instance.

Optionally, as another embodiment, the process of determining the first instance in step 102 is specifically implemented as: determining that the instance total load average value in the first predetermined time is greater than the first predetermined threshold is the first instance.

Optionally, in a specific implementation manner of the embodiment, determining the second instance in step 102 may be specifically implemented as: if there is an instance in which the average total load of the instance is lower than the second predetermined threshold in the first predetermined time, then determining As the second instance, one or more instances in which the instance total load average is lower than a second predetermined threshold within a predetermined time period, wherein a sum of a load value of all loads moved into the second instance and the second predetermined threshold is less than the first A predetermined threshold.

Further, in the current specific implementation, the step 103 may be specifically implemented as: according to the second load of the at least one load to be migrated in the first instance, the second PCB corresponding to the shared resource pool, the second The binding rule of the second RSS queue bound in the first instance is modified to be bound to the second load of the second instance, so that the second instance implements data packet reception from the second RSS queue. And the process of processing; or, according to the second load of the at least one load to be migrated of the first instance in the shared resource pool, the second load is released in the first instance in the first a second RSS queue bound in the instance, and binding the second RSS queue to the second load in the second instance, so that the second instance implements data packet reception from the second RSS queue and The process of processing.

In addition, in the current specific implementation, the step 104 is specifically implemented as: determining that the third load in the first instance is the to-be-migrated load of the first instance, where the third load is bound in the first instance. The third RSS queue satisfies the following condition: when the third RSS queue is bound to the second instance, at least two parameters of the connection number, the number of received bytes, and the number of bytes sent by the second instance are not Greater than the corresponding parameter of the first instance.

Optionally, in a specific implementation manner of the embodiment, determining the second instance in step 102 may be specifically implemented as: if there is no instance in which the total instance load average value is lower than the second predetermined threshold in the predetermined time, then Determine the new instance as the second instance.

Further, in the current specific implementation, the step 103 is specifically implemented as: the second PCB corresponding to the second load of the at least one load to be migrated according to the first instance in the shared resource pool is in the second instance. Interacting the second load with an upper layer service of the user state protocol stack to enable the second instance to implement an interaction of an application app corresponding to the second load, and releasing the second load in the first instance a second RSS queue bound in the first instance, in which the second RSS queue is bound to the second payload, such that the second instance is implemented from the second RSS The process of receiving and processing data packets by the queue.

In addition, in the current specific implementation, the step 104 is specifically implemented as follows: determining that the third load in the first instance is the to-be-migrated load of the first instance, where the third load is bound in the first instance. The third RSS queue satisfies the following conditions: the number of connections, the number of received bytes, and the number of transmitted bytes of the third RSS queue reach the mean of the corresponding parameters in all the loads of the first instance.

Hereinafter, the method of the embodiment of the present invention will be further described in conjunction with specific embodiments. In the following specific embodiments, the protocol stack thread is described as an example of a user state protocol stack.

In the scenario shown in Figure 3, the user mode protocol stack contains multiple protocol stacks corresponding to the running application. The key data structures of the Protocol Control Block (PCB) in the protocol stack are stored in a shared resource pool of system memory. The shared resource pool is shown in Figure 3 as a protocol control block allocation pool (PCB Alloc), which stores the key data structure of the PCB, mainly including the connection structure information, which can be used to quickly respond to the recovery connection. In the protocol stack, the PCB serves as the main data structure for the connection, so it can be used as the main metric for the protocol stack workload. As shown in FIG. 3, the user mode protocol stack may include protocol stacks stack1, stack2, and stack3. The thread corresponding to stack1 includes 2 loads, and the corresponding PCBs are PCB1 and PCB4 respectively; the thread corresponding to stack2 includes 1 load, and the corresponding PCB is PCB3; the thread corresponding to stack3 includes 1 load, The corresponding PCB is PCB2.

S301. The protocol stack system monitors an running state of an instance corresponding to each protocol stack in the user state protocol stack.

The protocol stack system can monitor the running status of the instance corresponding to each protocol stack in the user state protocol stack in multiple ways. The running state of the instance may include a load state and a live state of the instance.

The surviving state of an instance includes whether the instance is dead (or invalid). For a dead (or failed) instance, the stack system should initiate an instance recovery process.

The load status of an instance includes whether the instance is running at a high level, running at a low level, or otherwise. Among them, the example of low-level operation has the ability to move into the load. For an instance running at a high level, the load balancing process should be initiated to move out some of the load within the instance.

In the embodiment of the present invention, the protocol stack system sends a heartbeat message to the instance corresponding to each protocol stack, monitors the response delay of the instance corresponding to each protocol stack to the respective heartbeat message, and monitors the average load of the instance in the first predetermined time. To monitor the running status of the instance. Among them, a heartbeat message pair Should be one of the examples.

As shown in Figure 3, the protocol stack system monitors threads through a common thread (Common Thread). In the embodiment of the present invention, the Common Thread may include a Watch Dog module for implementing timing monitoring of threads. The Common Thread can send a keep alive message to the thread corresponding to each protocol stack of the user mode protocol stack by Watch Dog. After receiving the heartbeat message, the thread corresponding to each protocol stack of the user state protocol stack can feedback the heartbeat response. In addition, the Common Thread can also monitor the load of the thread, and can be monitored by the Watch Dog, or can be obtained by accessing the load parameter of the thread. For the specific implementation, reference may be made to the prior art, and details are not described herein again.

Common Thread monitors the survival of threads. The Common Thread can send a heartbeat message to the thread corresponding to each protocol stack of the user mode protocol stack and monitor the response delay of each protocol stack corresponding to the respective heartbeat message. If the Common Thread receives the heartbeat response of the thread feedback within the second predetermined time after sending the heartbeat message to the thread, the Common Thread may consider the thread's survival state to be in a valid state (or active state); conversely, if the Common Thread is in the direction After the thread does not receive the heartbeat response of the thread feedback within the second predetermined time after the thread sends the heartbeat message, the Common Thread may consider the thread's survival state to be a dead or dead state. The second predetermined time is determined by the protocol stack system.

In addition, Common Thread can also monitor the load status of threads. It should be understood that in order to avoid the false alarm of the load state caused by the instantaneous peak and the instantaneous low value, the thread load average value for a period of time may be taken as the criterion for determining the thread load state. The Common Thread may determine that the thread whose total load average value of the thread is greater than the first predetermined threshold in the first predetermined time is a thread running at a high level, and the Common Thread may also determine that the thread whose total thread load average is lower than the second predetermined threshold in the first predetermined time is Run the thread low. The first predetermined time, the first predetermined threshold, and the second predetermined threshold may all be determined by the protocol stack system.

S302. The protocol stack system instructs to create a new instance as the second instance.

After the stack system monitors the dead (or failed) instance, a new instance can be created and the new instance determined to be the second instance for recovering the dead (or failed) instance.

It may be assumed that the thread corresponding to the stack1 in FIG. 3 does not feed back the heartbeat response within the second predetermined time, then the Common Thread can confirm that the thread corresponding to the stack1 is a dead (or invalid) thread.

At this point, Common Thread can create a new thread and establish a corresponding in the user state protocol stack. The stack element stack4, completes the initialization of the thread. For a specific process of thread initialization, reference may be made to the prior art, and details are not described herein again.

S303. The second instance binds the RSS queue.

The second instance may obtain the identification information of the PCB corresponding to all the loads in the first instance, obtain the corresponding PCB information from the shared resource pool, and bind the original first instance based on the corresponding PCB information in the shared resource pool. The RSS queue is bound to the second instance.

In Figure 3, the shared resource pool is a protocol control block allocation pool (PCB Alloc) that stores the PCBs of all the loads in the instance of the protocol stack. The main data structure of the connection is included in the PCB.

According to the load corresponding to the PCB in the first example

The second instance may acquire the RSS queue bound by the load in the first instance according to the PCB corresponding to the load in the first instance, and bind the RSS queue bound by the load in the first instance to the second instance. .

As shown in Figure 3, the thread corresponding to stack4 obtains the protocol control blocks PCB1 and PCB4 corresponding to the load from the thread corresponding to stack1 or stack1, and obtains the RSS bound to the thread corresponding to stack1 from PCB1 and PCB4. Queue information and re-binding the RSS queue to the thread corresponding to stack4.

S304. The second instance interfaces with an upper layer service of the user state protocol stack.

The second instance may also establish a docking with an upper layer service of the user mode protocol stack according to the PCB corresponding to the load in the first instance.

Specifically, as shown in FIG. 3, the thread corresponding to stack4 can re-bind the thread corresponding to stack4 and the message box in the upper socket application interface layer (Socket API) according to PCB1 and PCB4 in the PCB Alloc (msg). Box), complete the re-docking of the thread and the upper layer of the protocol stack, thereby restoring the interaction between the thread and the application (app).

In addition, it should be understood that there is no relationship between the step S303 and the step S304. After the initialization is completed, the newly created instance may be bound to the RSS queue first, or may be re-connected with the upper layer service of the protocol stack. This is not a limitation.

S305. The protocol stack system destroys the first instance.

After the second instance completes the recovery process for the first instance, the first instance can be destroyed.

Based on system stability considerations, after the recovery process is completed, the original dead (or failed) instances need to be destroyed.

As shown in Figure 3, when the load of the thread corresponding to stack1 is heavy in the thread corresponding to stack4 After the build, the thread corresponding to stack1 should be destroyed, and the corresponding stack stack1 will be released.

In the embodiment of the present invention, the protocol stack system rebuilds the load in the newly established instance in the PCB of the shared resource pool based on the load of the dead (or failed) instance, and can quickly take over the connection information responsible for the invalid protocol stack, and quickly recover, From the network card information, the information that interacts with the application (app) can be quickly recovered with little loss.

In addition, in the embodiment of the present invention, the protocol control block information maintains a global shared storage mechanism, which is very useful for recovering the connection in the processing, especially for the Transmission Control Protocol (TCP) Listening (Listen), UDP connection, The Hypertext Transfer Protocol (HTTP) 1.1 protocol, such as long connections, is not sensitive to transient interruptions, and can achieve non-destructive recovery. For other types of TCP connections, etc., it may be timed out due to interruption or The TCP window enters the slow start mode, but these are all correctly processed by the protocol stack to restore the correct state, and have no effect on the overall state of the system.

In addition, in the embodiment of FIG. 3, one or more of the existing low-level running threads may be selected as the second instance, and the load of the first instance is reconstructed in the second instance, and then the first instance is destroyed. Operation.

In the scenario shown in Figure 4, the user mode protocol stack contains multiple protocol stacks corresponding to the running application. The key data structures of the Protocol Control Block (PCB) in the protocol stack are stored in a shared resource pool of system memory. The shared resource pool is shown in Figure 4 as a protocol control block allocation pool (PCB Alloc), which stores the key data structure of the PCB, mainly including the connection structure information, which can be used to quickly respond to the recovery connection. In the protocol stack, the PCB serves as the main data structure for the connection, so it can be used as the main metric for the protocol stack workload. As shown in FIG. 4, the user mode protocol stack may include protocol stacks stack1, stack2, stack3, and stack4. Among them, the thread corresponding to stack1 has 2 loads, and the corresponding PCBs are PCB1 and PCB4 respectively; the corresponding thread of stack2 has 1 load, and the corresponding PCB is PCB3; the corresponding thread of stack3 has 1 memory. The load, the corresponding PCB is PCB2; the corresponding thread of stack4 has 1 load, and the corresponding PCB is PCB5.

S401. The protocol stack system monitors an operation state of an instance corresponding to each protocol stack in the user state protocol stack.

The step S401 is similar to the step S301 of FIG. 3, and details are not described herein again.

S402. The protocol stack system sends an indication message to the first instance and the second instance, respectively.

Based on the results of the monitoring, the protocol stack system can determine which instances need to be moved out of the load and instances that can move into the load.

If there is at least one instance of the high-level operation in the plurality of instances of the user-mode protocol stack, it may be determined that the instance of the at least one high-order operation is the first instance.

Meanwhile, if there is at least one instance of low-level operation in multiple instances of the user-mode protocol stack, it may be determined that one or more instances of the at least one low-level running instance are the second instance.

As shown in FIG. 4, it is assumed that in step S401, the protocol stack system monitors the thread high bit corresponding to stack1 through the common thread (Common Thread), and the thread corresponding to stack4 and stack2 runs low, that is, the thread corresponding to stack1. The load needs to be moved out, and the thread corresponding to stack4 and stack2 has the ability to move into the load.

At this time, Common Thread can determine that the thread corresponding to stack1 is the first instance, and determine that the thread corresponding to stack4 or stack2 is the second instance, or that the thread corresponding to stack4 and stack2 is the second instance. Since the thread corresponding to stack1 has only two loads corresponding to PCB1 and PCB4, it is obvious that only one second instance is needed as long as one load is moved out. In the embodiment of the present invention, the thread corresponding to stack4 is selected as the second instance.

First, the Common Thread may send a first notification (notify) message to the thread corresponding to the stack1, indicating that the thread corresponding to the stack1 determines the migration load and unbinds the RSS queue corresponding to the migrated load.

After the thread corresponding to stack1 receives the first indication message, it first determines the load to be moved out.

In order to achieve load balancing, it is necessary to carefully choose the problem of rebinding: the thread that has moved out of the load has achieved the purpose of effectively reducing the burden; the thread that is moved in can not excessively cause the unilateral load to be high, so it needs to be moved in and moved. A balance is reached between threads.

In the upper layer, the impact of each queue on the RSS queue load can be sorted, so that the load is evenly distributed. And comprehensive consideration of the impact of all aspects of transmission and reception.

TCP/UDP connections, as well as other types of protocols to be processed, have their own characteristics. The bidirectional load of each connection is variable, and the lifetime is also uncertain. Very fine partitioning and matching are expensive for the system.

Therefore, considering this, we hope to achieve the best load balancing effect with the least overhead, and use the following dimensions to measure the rebinding selection process: number of connections, number of received bytes (Recv Bytes) and number of bytes sent ( Send Bytes).

Number of connections: the number of connections, the connection as the final carrier of the CPU load, has an intuitive meaning; Moreover, when Recv arrives at the data, it needs to perform connection lookup and then transfer to the connection state processing. Therefore, it is meaningful to balance the number of thread connections of each protocol stack.

Recv Bytes: rss itself is mainly for Packets Dispatch on the Recv side, so the amount of data received by the packet can reflect the impact on the protocol stack thread load.

Send Bytes: Send Packets are affected by the relationship between the Recv end data and the connection affinity, and also affect the Send load of the protocol stack processing related connections.

In the embodiment of the present invention, load balancing is performed between original threads. Therefore, the migrated load should satisfy: the load-loaded thread before migration (second instance), the total load after migration should not be higher than the total load before the migration thread (first instance) is not migrated; pre-migration load Light thread (second instance), the number of connections of all RSS queues bound after migration, the value of at least 2 of the 3 parameters of Recv Bytes and Send Bytes should not exceed the value of the migration thread (first instance). The corresponding parameter value before.

It may be assumed that the load corresponding to PCB4 in the thread corresponding to stack1 satisfies the determination condition of the outbound load, and the first instance may determine that the load corresponding to PCB4 is the load to be moved out.

The thread corresponding to the stack1 can feed back the identifier of the PCB 4 or the identifier of the load corresponding to the PCB 4 to the Common Thread, and step S403 is performed.

In addition, after receiving the feedback of the thread corresponding to the stack1, the Common Thread may send a second indication message to the thread corresponding to the stack4, indicating that the thread corresponding to the stack4 is ready to move into the load. The second indication message may carry information to be moved into the load.

S403. The first instance unbinds the queue of the migrated load.

As shown in FIG. 4, after the thread corresponding to the stack1 determines that the load corresponding to the PCB4 is the load to be moved out, the load corresponding to the PCB4 can be unbound to the RSS queue bound by the thread corresponding to the stack1.

S404. The second instance binds the queue of the load to be migrated.

After receiving the second indication message, the second instance may bind the RSS queue to which the load to be migrated is bound to the second instance to the second instance according to the PCB to be migrated in the shared resource pool, and receive the The process of receiving a packet from the RSS queue, and the resulting packet processing.

In the embodiment of the present invention, the thread corresponding to the stack4 may obtain the information of the PCB4 from the protocol control block allocation pool PCB Alloc according to the identification information of the PCB4 in the second indication message or the identification information of the load corresponding to the PCB4, and based on the information of the PCB4. The load corresponding to the stack4 rebuilds the load, and the RSS queue bound by the load corresponding to the PCB4 is bound to the load corresponding to the thread PCB4 corresponding to the stack4.

In the embodiment of the present invention, load balancing between the original instances is performed on the PCB of the shared resource pool through the load to be migrated, thereby avoiding unnecessary data transmission during load balancing, and improving the efficiency of load balancing.

In addition, in the embodiment of the present invention, the binding rule of the RSS queue bound to the load to be migrated can be directly modified, and the binding rule of the RSS queue bound to the migration load is directly modified to be bound to the second instance. On the load, avoid the operation of the first instance unbinding and the second instance binding. For the steps of monitoring the instance status and determining the load to be migrated of the high-level running instance, reference may be made to the related process in the embodiment of the present invention, and details are not described herein again.

In the scenario shown in Figure 5, the user mode protocol stack contains multiple protocol stacks corresponding to the running application. The key data structures of the Protocol Control Block (PCB) in the protocol stack are stored in a shared resource pool of system memory. The shared resource pool is shown in Figure 5 as a protocol control block allocation pool (PCB Alloc), which stores the key data structure of the PCB, mainly including the connection structure information, which can be used to quickly respond to the recovery connection. In the protocol stack, the PCB serves as the main data structure for the connection, so it can be used as the main metric for the protocol stack workload. As shown in FIG. 5, the user mode protocol stack may include protocol stacks stack1, stack2, and stack3. The thread corresponding to stack1 includes 2 loads, and the corresponding PCBs are PCB1 and PCB4 respectively; the thread corresponding to stack2 includes 1 load, and the corresponding PCB is PCB3; the thread corresponding to stack3 includes 1 load, The corresponding PCB is PCB2.

S501. The protocol stack system monitors an running state of an instance corresponding to each protocol stack in the user state protocol stack.

Step S501 is similar to step S301 of FIG. 3, and details are not described herein again.

S502. The protocol stack system sends an indication message to the first instance.

If there is at least one instance of the high-bit operation in the instance corresponding to each protocol stack in the user-mode protocol stack, it may be determined that the instance of the at least one high-order operation is the first instance.

As shown in FIG. 5, it is assumed that in step S501, the protocol stack system monitors the high-order running of the thread corresponding to stack1 through the common thread (Common Thread), and the thread corresponding to stack2 and stack3 does not have the ability to move into the load.

First, the Common Thread may send a first notification (notify) message to the thread corresponding to the stack1, indicating that the thread corresponding to the stack1 determines the migration load and releases the binding to the migration load. Binding of the RSS queue.

Similarly, in order to achieve the best load balancing effect with the least overhead, the following dimensions can be used to measure the rebinding selection process: connection number, Recv Bytes and Send Bytes.

In the embodiment of the present invention, the load balancing is moved from the original thread to the newly created thread. When selecting the migrating load, you should select the number of connections, and the three parameters of Recv Bytes and Send Bytes migrate to the load corresponding to the average RSS queue. Alternatively, three predetermined parameter thresholds may be set for the three parameters of the connection number, the Recv Bytes and the Send Bytes, and the load whose three parameters reach the corresponding predetermined parameter threshold as a whole is selected as the to-be-migrated load.

It may be assumed that the RSS bound to the load corresponding to PCB4 satisfies the determination condition of the outbound load, and the thread corresponding to stack1 can feed back the identifier of PCB4 or the load corresponding to PCB4 to Common Thread, and unbind the corresponding PCB4. The load is in the RSS queue bound to the thread corresponding to stack1.

After the thread corresponding to the stack1 determines the load to be migrated, the information about the load to be migrated, such as the identifier of the load to be migrated, or the identifier of the PCB corresponding to the load to be migrated, is sent to the Common Thread, and so on, and step S504 is performed.

Meanwhile, if at least one instance of the low-level operation does not exist in the plurality of instances of the user-mode protocol stack, the protocol stack system may instruct to create a new instance as the second instance, that is, perform step S503.

S503. The protocol stack system instructs to create a new instance as the second instance.

When the protocol stack system monitors the high-level running instance and there is no low-level running instance in the existing instance, the protocol stack system can create a new instance and determine that the newly created instance is the second instance, and is used to move into the load to implement the load. balanced.

As shown in Figure 5, the protocol stack system sends a new thread instruction via Common Thread, creates a new thread, that is, the thread corresponding to stack4, and determines that the thread corresponding to stack4 is the second instance, and completes the pair. The initialization operation of the new thread. For a specific process of thread initialization, reference may be made to the prior art, and details are not described herein again.

S504. The first instance unbinds the queue of the migrated load.

As shown in FIG. 5, after the thread corresponding to the stack1 determines that the load corresponding to the PCB4 is the load to be moved out, the load corresponding to the PCB4 can be unbound to the RSS queue bound by the thread corresponding to the stack1.

S505. The second instance binds the queue of the load to be migrated.

The thread corresponding to the stack4 can control the information of the PCB4 in the block allocation pool (PCB Alloc) according to the protocol, and bind the RSS queue bound by the load corresponding to the PCB4 to the second instance in the thread queue bound to the thread corresponding to the stack1. At this point, the thread corresponding to stack4 will receive the process of receiving packets from this queue, and the resulting packet processing.

S506. The second instance is connected to the upper layer service of the protocol stack.

The second instance is to create a new instance, and the interface with the upper layer service of the user state protocol stack is also required to implement the interaction of the application corresponding to the load.

In the embodiment of the present invention, the thread corresponding to the stack4 can control the information of the PCB4 in the block allocation pool according to the protocol, and re-bind the message box corresponding to the stack4 and the message box in the upper socket application interface layer (Socket API) (msg). Box), complete the re-docking of the thread and the upper layer of the protocol stack, thereby restoring the interaction between the thread and the application (app).

It should be understood that there is no temporal relationship between step S505 and step S506.

In the embodiment of the present invention, load balancing is performed on the PCB of the shared resource pool in the shared resource pool, thereby implementing load balancing, avoiding unnecessary data transmission during load balancing, and improving load balancing efficiency.

In addition to the above-described methods for monitoring the running state of the embodiment of the embodiment shown in FIG. 3 to FIG. 5, the protocol stack system can also monitor the running state of the instance by other means. In another monitoring mode of the present invention, the protocol stack system can use the instance identifier to represent the surviving state of the instance, and monitor the survival state of the instance by monitoring the instance ID of the instance, and monitor the load status of the instance by the total load average of the instance within a predetermined time. To achieve monitoring of the running state of the instance. Each instance identifier corresponds to an instance of the protocol stack, and the instance identifier can be stored in a memory shared space or a shared file, and the protocol stack system can poll the instance identifier of the instance by using a polling timer. The protocol stack system can use the polling timer instead of the Watch Dog in FIG. 3 to FIG. 5 to poll the thread's survival identifier by polling the timer to monitor the survival state of the thread. The thread's survival identifier can be stored in the memory shared space, or shared files, and one-to-one correspondence with the thread. In addition, for the specific implementation of the load monitoring and the instance load migration and the load reconstruction of the example, reference may be made to the embodiments shown in FIG. 3 to FIG. 5 , and details are not described herein again. Certainly, there may be other ways of monitoring the running state of the instance, which is not limited by the embodiment of the present invention.

FIG. 6 is a schematic structural diagram of a protocol stack system 600 according to an embodiment of the present invention. The protocol stack system 600 can include a monitoring unit 601, a determining unit 602, and a load migration unit 603.

The monitoring unit 601 is configured to monitor an running state of an instance corresponding to each protocol stack in the user state protocol stack.

The determining unit 602 is configured to determine the first instance and the second instance.

An instance of a load state exception can include an instance of a load high bit operation. When judging whether the instance is running at a high load, the relationship between the average total load of the instance and the predetermined threshold can be compared by comparing the time period. To determine if the instance is in a high load state.

The load migration unit 603 is configured to rebuild the at least one load to be migrated in the second instance according to the protocol control block PCB corresponding to the at least one load to be migrated in the shared resource pool.

In the embodiment of the present invention, the protocol stack system 600 rebuilds the load to be migrated in the instance with the load-bearing capability in the PCB corresponding to the shared resource pool according to the load to be migrated in the abnormal instance, and can overcome the system brought by the protocol stack sharing a distribution module. Distribution bottlenecks, rapid load balancing and failure recovery improve the performance of the protocol stack system.

Optionally, the determining unit 602 is further configured to determine at least one load to be migrated in the first instance.

Optionally, the monitoring unit 601 is configured to: separately send a heartbeat message to the instance corresponding to each protocol stack in the user state protocol stack, and monitor the heartbeat message response delay, and monitor each protocol stack in the user state protocol stack. The instance load average of the corresponding instance in the first predetermined time, to determine the running state of the instance corresponding to each protocol stack in the user state protocol stack according to the response delay of the heartbeat message and the average value of the instance load, wherein a heartbeat The message corresponds to one instance; or, respectively, the instance identifier of the instance corresponding to each protocol stack in the user state protocol stack is polled, and the instance corresponding to each protocol stack in the user state protocol stack is monitored in the first predetermined time. The instance load average value is used to determine an running state of an instance corresponding to each protocol stack in the user mode protocol stack according to the instance identifier and the instance load average value, where the instance identifier is used to indicate a survival state of the instance, and the instance identifier is stored. For a shared memory area or shared file, one instance ID corresponds to one instance.

Optionally, as an embodiment, in the process for determining the first instance, the determining unit 602 is specifically configured to: determine, by the first time after the sending of the heartbeat message, that the heartbeat response is not fed back after the second predetermined time is the first An instance; or, determining that the instance identifier indicates a dead or dead state in the first predetermined time is the first instance.

In this embodiment, in the process for determining the second instance, the determining unit 602 is specifically configured to create and determine that the new instance is the second instance; the load migration unit 603 is specifically configured to use the at least one load to be migrated The first PCB corresponding to the load in the shared resource pool implements the docking of the first load with the upper layer service of the user state protocol stack in the second instance, and binds the first load in the first instance. The first receiving end extended RSS queue is rebinded into the first load of the second instance, wherein the at least one load to be migrated includes all loads of the first instance.

FIG. 7 is another schematic structural diagram of a protocol stack system 600 according to an embodiment of the present invention. As shown in Figure 7, The protocol stack system 600 can also include an instance stop unit 604 for terminating the first instance.

Optionally, in another process, in the process for determining the first instance, the determining unit 602 is specifically configured to: determine that the instance total load average value is greater than the first predetermined threshold in the first predetermined time is the first instance .

Optionally, in a scenario of the specific implementation, in the process for determining the second instance, the determining unit 602 is specifically configured to: if there is an instance total load average value lower than a second predetermined threshold in the first predetermined time And determining, as the second instance, one or more instances in which the average total load of the instance is lower than a second predetermined threshold within a predetermined time, wherein a load value of all loads moved into the second instance and the second predetermined threshold The sum is less than the first predetermined threshold.

Further, in the current specific implementation, the load migration unit 603 is specifically configured to: according to the second load corresponding to the second load of the at least one load to be migrated in the first instance, the second PCB corresponding to the shared resource pool Binding rules of the second RSS queue bound by the second load in the first instance are modified to be bound to the second load of the second instance, so that the second instance implements data packet from the second RSS queue. a process of receiving and processing; or, according to the second load corresponding to the second load of the at least one load to be migrated in the shared resource, the second load is released in the first instance in the first instance a second RSS queue bound in an instance, and binding the second RSS queue to the second payload in the second instance, so that the second instance implements data packet reception from the second RSS queue And the process of processing.

In addition, in the current specific implementation, in the process for determining the at least one load to be migrated in the first instance, the determining unit 602 is specifically configured to: determine that the third load in the first instance is the first The load to be migrated of the instance, the third RSS queue bound by the third load in the first instance satisfies the following condition: the number of connections of the second instance when the third RSS queue is bound to the second instance, At least two of the three parameters of the number of received bytes and the number of transmitted bytes are not greater than the corresponding parameters of the first instance.

Optionally, in a specific implementation manner of the embodiment, in the process for determining the second instance, the determining unit 602 is specifically configured to: if there is no instance time, the total load average value is lower than the second predetermined threshold. For an instance, create and determine a new instance for the second instance.

Further, in the current specific implementation, the load migration unit 603 is specifically configured to: the second PCB corresponding to the second load of the at least one load to be migrated according to the first instance in the shared resource pool is in the second In the example, the second load is implemented to be connected to the upper layer service of the user state protocol stack, so that the second instance implements the interaction of the application app corresponding to the second load, and in the Dissolving, in an instance, the second RSS queue bound by the second payload in the first instance, and binding the second RSS queue to the second payload in the second instance, so that the second instance is implemented The process of receiving and processing data packets from the second RSS queue.

In addition, in the current specific implementation, in the process for determining the at least one load to be migrated in the first instance, the determining unit 602 is specifically configured to: determine that the third load in the first instance is the first The load of the instance to be migrated, the third RSS queue bound by the third load in the first instance satisfies the following conditions: the number of connections, the number of received bytes, and the number of bytes sent in the third RSS queue are three parameters. Both reach the mean of the corresponding parameters in all loads of the first instance.

The protocol stack system 600 can also perform the functions of the embodiment shown in FIG. 1 and FIG. 2, and can implement the functions of the protocol stack system in the embodiment shown in FIG. 1 to FIG. 5, and the specific implementation can refer to the embodiment shown in FIG. 1 to FIG. The embodiments of the present invention are not described herein again.

FIG. 8 is a schematic structural diagram of a protocol stack system 800 according to an embodiment of the present invention. The protocol stack system can include an IO channel 801, a processor 802, and a memory 803.

The IO channel 801, the processor 802, and the memory 803 are interconnected by a bus 804 system; the bus 804 may be an ISA bus, a PCI bus, or an EISA bus. The bus can be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, only one thick line is shown in Figure 8, but it does not mean that there is only one bus or one type of bus.

The memory 803 is configured to store a program. In particular, the program can include program code, the program code including computer operating instructions. The memory 803 may include a high speed RAM memory and may also include a non-volatile memory such as at least one disk memory.

The processor 802 executes a program stored in the memory 803, and is configured to monitor an operation state of an instance corresponding to each protocol stack in the user mode protocol stack, determine the first instance and the second instance, and perform at least one to be migrated according to the first instance. The protocol control block PCB corresponding to the shared resource pool of the memory 803 rebuilds the at least one load to be migrated in the second instance. The one instance corresponds to a protocol stack in the user state protocol stack, the first instance is an instance of an abnormal running state, and the second instance has the capability of moving into at least one load to be migrated in the first instance, and one The to-be-migrated load corresponds to a protocol control block PCB in the protocol stack corresponding to the first instance, and the PCB corresponds to a PCB storing the connection parameters of the load to be migrated in the shared resource pool, and the load to be migrated The connection parameters can be used to reconstruct the load to be migrated.

It should be understood that in the embodiment of the present invention, the user state protocol stack is used to represent all protocol stacks existing in the user space. In the user state protocol stack, one or more protocol stacks may be included, and each protocol stack and protocol An example of a stacking system forms a one-to-one correspondence.

Memory 803 can include read only memory and random access memory and provides instructions and data to processor 802. A portion of the memory 803 may also include non-volatile random access memory (NVRAM).

The method disclosed in any of the embodiments of FIG. 1 to FIG. 5 of the present invention may be applied to the processor 802 or implemented by the processor 802. Processor 802 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 802 or an instruction in a form of software. The processor 802 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP Processor, etc.), or a digital signal processor (DSP), an application specific integrated circuit. (ASIC), off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, 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 803, and the processor 802 reads the information in the memory 803 and completes the steps of the above method in combination with its hardware.

Optionally, the processor 802 is further configured to determine at least one load to be migrated in the first instance.

Optionally, in the process of monitoring the running status of multiple instances in the user-mode protocol stack, the processor 802 is specifically configured to: separately send a heartbeat message to the instance corresponding to each protocol stack in the user-mode protocol stack, and monitor The heartbeat message responds to the delay, and monitors an instance load average of the instance corresponding to each protocol stack in the user state protocol stack in the first predetermined time to determine the user according to the response delay of the heartbeat message and the average value of the instance load. An operation state of an instance corresponding to each protocol stack in the protocol stack, wherein one heartbeat message corresponds to one instance; or, respectively, polling instance identifiers of instances corresponding to each protocol stack in the user state protocol stack, and monitoring The instance load average of the instance corresponding to each protocol stack in the user-mode protocol stack in the first predetermined time, to determine the running of the instance corresponding to each protocol stack in the user-mode protocol stack according to the instance identifier and the instance load average State, where The instance identifier is used to indicate the survival state of the instance, and the instance identifier is stored in a shared memory area or a shared file, and one instance identifier corresponds to one instance.

Optionally, as an embodiment, in the process for determining the first instance, the processor 802 is specifically configured to: determine that the first time after the sending of the heartbeat message time reaches the second predetermined time, the instance that still does not feed back the heartbeat response is the first An instance; or, determining that the instance identifier indicates a dead or dead state in the first predetermined time is the first instance.

In this embodiment, in the process for determining the second instance, the processor 802 is specifically configured to create and determine a new instance as the second instance; in the memory for at least one load to be migrated according to the first instance In the process of rebuilding the at least one load to be migrated in the second instance, the processor 802 is specifically configured to share the resource according to the first load of the at least one load to be migrated. The first PCB corresponding to the pool implements the connection between the first load and the upper layer service of the user state protocol stack in the second instance, and binds the first load to the first receiving end bound in the first instance. The extended RSS queue is rebinded into the first load of the second instance, wherein the at least one load to be migrated includes all loads of the first instance. At this time, the processor 802 can also be used to terminate the first instance.

Optionally, in another process, in the process for determining the first instance, the processor 802 is specifically configured to: determine that the instance total load average value is greater than the first predetermined threshold in the first predetermined time is the first instance .

Optionally, in a scenario of the specific implementation, in the process for determining the second instance, the processor 802 is specifically configured to: if there is an instance total load average value lower than a second predetermined threshold in the first predetermined time And determining, as the second instance, one or more instances in which the average total load of the instance is lower than a second predetermined threshold within a predetermined time, wherein a load value of all loads moved into the second instance and the second predetermined threshold The sum is less than the first predetermined threshold.

Further, in the current specific implementation, the at least one protocol is reconstructed in the second instance in a shared resource pool corresponding to the at least one load to be migrated in the shared resource pool in the first instance. The processor 802 is specifically configured to: in the second PCB corresponding to the second load of the at least one load to be migrated according to the first instance, the second load is in the first The binding rule of the second RSS queue bound in an instance is modified to be bound to the second load of the second instance, so that the second instance implements the process of receiving and processing data packets from the second RSS queue. Or the second PCB corresponding to the second load of the load to be migrated according to the first instance in the shared resource pool is released in the first instance. The second load is bound to the second RSS queue in the first instance, and the second RSS queue is bound to the second load in the second instance, such that the second instance is implemented from the first The process of receiving and processing data packets by the second RSS queue.

In addition, in the current specific implementation, in the process for determining the at least one load to be migrated in the first instance, the processor 802 is specifically configured to: determine that the third load in the first instance is the first The load to be migrated of the instance, the third RSS queue bound by the third load in the first instance satisfies the following condition: the number of connections of the second instance when the third RSS queue is bound to the second instance, At least two of the three parameters of the number of received bytes and the number of transmitted bytes are not greater than the corresponding parameters of the first instance.

Optionally, in a specific implementation manner of this embodiment, in the process for determining the second instance, the processor 802 is specifically configured to: if there is no predetermined time, the total load average of the instance is lower than a second predetermined threshold. For an instance, create and determine a new instance for the second instance.

Further, in the current specific implementation, the at least one protocol is reconstructed in the second instance in a shared resource pool corresponding to the at least one load to be migrated in the shared resource pool in the first instance. The processor 802 is specifically configured to: implement, according to the second PCB corresponding to the second load of the at least one load to be migrated in the shared resource pool, the second PCB in the second instance according to the first instance Interfacing the upper load with the upper layer service of the user mode protocol stack to enable the second instance to implement the interaction of the application app corresponding to the second load, and releasing the second load in the first instance in the first instance Binding a second RSS queue, in the second instance, binding the second RSS queue to the second load, so that the second instance implements a process of receiving and processing data packets from the second RSS queue .

In addition, in the current specific implementation, in the process for determining the at least one load to be migrated in the first instance, the processor 802 is specifically configured to: determine that the third load in the first instance is the first The load of the instance to be migrated, the third RSS queue bound by the third load in the first instance satisfies the following conditions: the number of connections, the number of received bytes, and the number of bytes sent in the third RSS queue are three parameters. Both reach the mean of the corresponding parameters in all loads of the first instance.

The protocol stack system 800 can also perform the functions of the embodiment shown in FIG. 1 and FIG. 2, and can implement the functions of the protocol stack system in the embodiment shown in FIG. 1 to FIG. 5, and the specific implementation can refer to the embodiment shown in FIG. 1 to FIG. The embodiments of the present invention are not described herein again.

Those of ordinary skill in the art will appreciate that the elements and algorithm steps of the various examples described in connection with the embodiments disclosed herein can be implemented in electronic hardware, or in computer software and electronic hardware. Come together to achieve. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the solution. A person skilled in the art can use different methods for implementing the described functions for each particular application, but such implementation should not be considered to be beyond the scope of the present invention.

A person skilled in the art can clearly understand that for the convenience and brevity of the description, the specific working process of the system, the device and the unit described above can refer to the corresponding process in the foregoing method embodiment, and details are not described herein again.

In the several embodiments provided by the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the device embodiments described above are merely illustrative. For example, the division of the unit is only a logical function division. In actual implementation, there may be another division manner, for example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, and may be in an electrical, mechanical or other form.

The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

The functions may be stored in a computer readable storage medium if implemented in the form of a software functional unit and sold or used as a standalone product. Based on such understanding, the technical solution of the present invention, which is essential or contributes to the prior art, or a part of the technical solution, may be embodied in the form of a software product, which is stored in a storage medium, including The instructions are used to cause a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present invention. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and the like. .

The above is only a specific embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily within the technical scope disclosed by the present invention. Any changes or substitutions are contemplated as being within the scope of the invention. Therefore, the scope of the invention should be determined by the scope of the claims.

Claims

A method for managing a parallel user state protocol stack, comprising:

Monitoring an operating state of an instance corresponding to each protocol stack in the user mode protocol stack, where the instance corresponds to a protocol stack in the user state protocol stack;

Determining a first instance and a second instance, wherein the first instance is an instance of a running state abnormality, and the second instance has a capability of migrating to at least one load to be migrated in the first instance, and the load to be migrated Corresponding to a protocol control block PCB in the protocol stack corresponding to the first instance, the PCB corresponds to a PCB storing the load connection parameters to be migrated in the shared resource pool, and the connection of the load to be migrated The parameter can be used to reconstruct the load to be migrated;

The at least one to-be-migrated load is reconstructed in the second instance according to the PCB corresponding to the at least one load to be migrated in the shared resource pool in the first instance.
The method of claim 1, wherein the at least one to be rebuilt in the second instance in the PCB corresponding to the at least one load to be migrated in the shared resource pool according to the first instance Before the load is migrated, the method further includes:

Determining at least one load to be migrated in the first instance.
The method of claim 2, wherein the running state of the instance comprises a load state and a surviving state of the instance, and the running states of the instance corresponding to each protocol stack in the monitoring user mode protocol stack include:

Sending a heartbeat message to the instance corresponding to each protocol stack in the user-mode protocol stack, and monitoring the heartbeat message response delay, and monitoring the instance corresponding to each protocol stack in the user-mode protocol stack at the first predetermined time. An instance load average value to determine an operation state of an instance corresponding to each protocol stack in the user mode protocol stack according to a response delay of the heartbeat message and the instance load average value, where a heartbeat message corresponds to a location An example; or

Detecting, respectively, an instance identifier of an instance corresponding to each protocol stack in the user-mode protocol stack, and monitoring an instance load average of the instance corresponding to each protocol stack in the user-mode protocol stack in a first predetermined time, according to The instance identifier and the instance load average determine an operational state of an instance corresponding to each protocol stack in the user state protocol stack, where the instance identifier is used to indicate a survival state of the instance, and the instance identifier is stored in the share A memory area or shared file, one of the instance identifiers corresponding to one of the instances.
The method of claim 3 wherein said determining the first instance comprises:

An example of determining that the heartbeat response has not been fed back after the time when the heartbeat message is sent for a second predetermined time is the first instance; or

An example of determining that the instance identifier represents a dead or dead state during the first predetermined time is the first instance.
The method of claim 4 wherein:

The determining the second instance includes: creating and determining that the new instance is the second instance;

Reconstructing the at least one to-be-migrated load in the second instance according to the PCB corresponding to the at least one load to be migrated in the shared resource pool in the first instance includes:

The first PCB corresponding to the first load in the shared resource pool according to the first load of the at least one load to be migrated implements the docking of the first load and the upper layer service of the user state protocol stack in the second instance, and Rebinding the first receiver extended RSS queue bound by the first load in the first instance to the first load of the second instance, where the at least one load to be migrated includes All loads of the first instance.
The method of claim 5 further comprising terminating said first instance.
The method of claim 3 wherein:

The determining the first instance includes: determining that the instance total load average value is greater than the first predetermined threshold in the first predetermined time period is the first instance.
The method of claim 7 wherein said determining the second instance comprises:

Determining, as the second, one or more instances in which the instance total load mean is lower than a second predetermined threshold in the first predetermined time if there is an instance in which the instance total load mean is lower than a second predetermined threshold in the first predetermined time An example wherein a sum of a load value of all loads moved into the second instance and the second predetermined threshold is less than the first predetermined threshold.
The method according to claim 8, wherein the PCB corresponding to the at least one load to be migrated in the shared resource pool in the first instance reconstructs the at least one to be migrated in the second instance The load includes:

And the second RSS that is bound to the second load in the first instance according to the second PCB corresponding to the at least one load to be migrated of the first instance in the shared resource pool Modifying the binding rule to be bound to the second load of the second instance, such that the second instance implements a process of receiving and processing data packets from the second RSS queue; or

Deactivating the second load in the first instance in the first instance according to the second PCB corresponding to the second load of the at least one load to be migrated in the first instance Binding a second RSS queue, and binding the second RSS queue to the second payload in the second instance, such that the second instance implements data from the second RSS queue The process of receiving and processing packets.
The method according to claim 8 or 9, wherein the determining the at least one load to be migrated in the first instance comprises:

Determining that the third load in the first instance is the load to be migrated of the first instance, and the third RSS queue bound by the third load in the first instance satisfies the following condition: when the When the three RSS queues are bound to the second instance, at least two of the three parameters of the connection number, the number of received bytes, and the number of transmitted bytes of the second instance are not greater than corresponding parameters of the first instance.
The method of claim 7, wherein the determining the second instance comprises: if there is no instance in which the instance total load mean is lower than a second predetermined threshold within a predetermined time, creating and determining that the new instance is the Second example.
The method according to claim 11, wherein the PCB corresponding to the at least one load to be migrated in the shared resource pool in the first instance reconstructs the at least one to be migrated in the second instance The load includes:

The second PCB corresponding to the second load of the at least one load to be migrated according to the first instance in the shared resource pool implements the second load and the user state protocol stack in the second instance. Interfacing of an upper layer service such that the second instance implements an interaction of an application app corresponding to the second load, and in the first instance, disengages the second load bound in the first instance a second RSS queue, in the second instance, binding the second RSS queue to the second load, so that the second instance implements data packet reception and processing from the second RSS queue. process.
The method according to claim 11 or 12, wherein the determining the at least one load to be migrated in the first instance comprises:

Determining that the third load in the first instance is the load to be migrated of the first instance, and the third RSS queue bound by the third load in the first instance satisfies the following condition: the third The average number of corresponding parameters among all the loads of the first instance is reached in the three parameters of the number of connections, the number of received bytes, and the number of bytes sent by the RSS queue.
A protocol stack system, comprising:

a monitoring unit, configured to monitor an operating state of each protocol stack in the user state protocol stack of the protocol stack system, where the instance corresponds to a protocol stack in the user state protocol stack;

a determining unit, configured to determine a first instance and a second instance, where the first instance is an instance of a running state abnormality, and the second instance has an ability to move into at least one load to be migrated in the first instance, The migration load is corresponding to a protocol control block PCB in the protocol stack corresponding to the first instance, and the PCB corresponds to a connection storing the load to be migrated in the shared resource pool of the protocol stack system. a PCB of the parameter, the connection parameter of the load to be migrated can be used to reconstruct the load to be migrated;

And a load migration unit, configured to rebuild the at least one to-be-migrated load in the second instance according to the PCB corresponding to the at least one load to be migrated in the shared resource pool in the first instance.
The system of claim 14, wherein the determining unit is further configured to determine at least one load to be migrated in the first instance.
The system according to claim 15, wherein the operating state of the instance comprises a load state and a survival state of the instance, and the monitoring unit is specifically configured to:

Sending a heartbeat message to the instance corresponding to each protocol stack in the user-mode protocol stack, and monitoring the heartbeat message response delay, and monitoring the instance corresponding to each protocol stack in the user-mode protocol stack at the first predetermined time. An instance load average value to determine an operation state of an instance corresponding to each protocol stack in the user mode protocol stack according to a response delay of the heartbeat message and the instance load average value, where a heartbeat message corresponds to a location An example; or

Detecting, respectively, an instance identifier of an instance corresponding to each protocol stack in the user-mode protocol stack, and monitoring an instance load average of the instance corresponding to each protocol stack in the user-mode protocol stack in a first predetermined time, according to The instance identifier and the instance load average determine an operational state of an instance corresponding to each protocol stack in the user state protocol stack, where the instance identifier is used to indicate a survival state of the instance, and the instance identifier is stored in the share A memory area or shared file, one of the instance identifiers corresponding to one of the instances.
The system according to claim 16, wherein in the process for determining the first instance, the determining unit is specifically configured to:

An example of determining that the heartbeat response has not been fed back after the time when the heartbeat message is sent for a second predetermined time is the first instance; or

An example of determining that the instance identifier indicates a dead or dead state during the first predetermined time is the first instance.
The system of claim 17 wherein:

In the process for determining the second instance, the determining unit is specifically configured to create and determine that the new instance is the second instance;

The load migration unit is configured to implement the first load and the user in the second instance according to the first PCB corresponding to the first load of the at least one load to be migrated in the shared resource pool. Interfacing the upper layer service of the state protocol stack, and rebinding the first receiver extended RSS queue bound by the first load in the first instance to the first load of the second instance, The at least one load to be migrated includes all loads of the first instance.
The system of claim 18, wherein the system further comprises: an instance stop unit for terminating the first instance.
The system of claim 16 wherein:

In the process for determining the first instance, the determining unit is specifically configured to determine that the instance total load average value is greater than the first predetermined threshold in the first predetermined time is the first instance.
The system of claim 20 wherein:

In the process for determining the second instance, if there is an instance that the instance total load average is lower than the second predetermined threshold in the first predetermined time, the determining unit is specifically configured to determine the first predetermined time instance One or more instances in which the total load average is lower than a second predetermined threshold, wherein the sum of the load value of all loads moved into the second instance and the second predetermined threshold is less than the first A predetermined threshold.
The system of claim 21, wherein the load migration unit is specifically configured to:

And the second RSS that is bound to the second load in the first instance according to the second PCB corresponding to the at least one load to be migrated of the first instance in the shared resource pool Modifying the binding rule to be bound to the second load of the second instance, such that the second instance implements a process of receiving and processing data packets from the second RSS queue; or

Deactivating the second load in the first instance in the first instance according to the second PCB corresponding to the second load of the at least one load to be migrated in the first instance Binding a second RSS queue, and binding the second RSS queue to the second payload in the second instance, such that the second instance implements data from the second RSS queue The process of receiving and processing packets.
A system according to claim 21 or 22, wherein In the process of at least one load to be migrated, the determining unit is specifically configured to: determine that the third load in the first instance is the load to be migrated in the first instance, and the third load is in the The third RSS queue bound in the first instance satisfies the condition that the number of connections, the number of received bytes, and the transmission byte of the second instance when the third RSS queue is bound to the second instance At least two of the three parameters are not greater than the corresponding parameters of the first instance.
The system according to claim 20, wherein in the process for determining the second instance, if there is no instance in which the instance total load mean is lower than a second predetermined threshold within a predetermined time, the determining unit Specifically, it is used to create and determine a new instance as the second instance.
The system of claim 25, wherein the load migration unit is specifically configured to:

The second PCB corresponding to the second load of the at least one load to be migrated according to the first instance in the shared resource pool implements the second load and the user state protocol stack in the second instance. Interfacing of an upper layer service such that the second instance implements an interaction of an application app corresponding to the second load, and in the first instance, disengages the second load bound in the first instance a second RSS queue, in the second instance, binding the second RSS queue to the second load, so that the second instance implements data packet reception and processing from the second RSS queue. process.
The system according to claim 24 or 25, wherein in the process for determining at least one load to be migrated in the first instance, the determining unit is specifically configured to:

Determining that the third load in the first instance is the load to be migrated of the first instance, and the third RSS queue bound by the third load in the first instance satisfies the following condition: the third The average number of corresponding parameters among all the loads of the first instance is reached in the three parameters of the number of connections, the number of received bytes, and the number of bytes sent by the RSS queue.