Intelligent traffic distribution method and system based on session affinity

Abstract

The application discloses an intelligent traffic distribution method and system based on session affinity, and comprises the following steps: receiving a data packet, searching for a session according to five-tuple information; if the session is not found, obtaining the load state of each CPU core and selecting the CPU core with the lowest load to bind to the newly created session; if the session is found, judging whether the current CPU core is consistent with the CPU core bound to the session; if not, putting the data packet into the FDM queue corresponding to the bound CPU core, so that the bound CPU core takes out and processes it. The application improves the session affinity and cache hit rate, realizes dynamic self-adaptive intelligent traffic distribution, and improves the overall performance of a multi-core network device.

Description

Technical Field

[0001] This invention belongs to the field of computer network communication technology, and in particular relates to an intelligent traffic distribution method and system based on session affinity. Background Technology

[0002] In multi-core network devices, efficiently and evenly distributing incoming network packets across multiple CPU cores for processing is one of the core technologies determining the overall performance of the device. Maintaining "session affinity" (ensuring that all packets belonging to the same session are distributed to the same CPU core for processing) is crucial for avoiding cross-core access to session state, improving CPU cache hit rate, and reducing processing latency. For example, in typical application scenarios such as firewall session processing that requires maintaining session state consistency, load balancers that need to bind client sessions to backend servers, and routers that pursue high-speed forwarding efficiency, the quality of session affinity directly affects the device's processing capacity and service quality.

[0003] The common traffic distribution solutions mainly include the following, each with its own technical shortcomings.

[0004] Firstly, a common approach is hardware hash distribution based on Receive Side Scaling (RSS). This approach involves the network interface card (NIC) hardware calculating a hash value based on the packet's five-tuple (source IP, destination IP, source port, destination port, and protocol type) and then distributing the packet to a fixed number of CPU cores based on this hash value. The advantage of this approach is that the distribution decision is made in hardware, resulting in relatively fast speed. However, its disadvantages are equally significant: it cannot perceive the real-time state of the session or the dynamic load of each CPU core. Hash collisions can easily lead to some CPU cores being overloaded while others are idle, causing severe load imbalance (30-50%), thus creating a performance bottleneck. Furthermore, the fixed distribution strategy results in poor caching and low processing efficiency.

[0005] Secondly, a simple software load balancing scheme, such as using a round-robin algorithm, distributes data packets sequentially to different CPU cores. This scheme is simple to implement and can achieve good load balancing results. However, its fatal flaw is that it completely destroys session affinity, causing different data packets from the same session to be distributed to different CPU cores for processing. This incurs significant cross-core cache coherence protocol (MESI) overhead, resulting in a significant decrease in L3 cache hit rate (by as much as 40-60%), a several-fold increase in memory access latency, and severely dragging down overall performance.

[0006] Secondly, there are connection-based intelligent distribution solutions, exemplified by Intel's DPDK (Data Plane Development Kit). This solution maintains a global connection table, recording the mapping between each data stream and CPU cores, and distributes streams based on this table, offering good performance. However, the main drawbacks of this solution are: the global connection table consumes a significant amount of valuable memory resources, table lookup overhead is substantial, and its distribution strategy is not aware of the complete lifecycle of a session, limiting its flexibility.

[0007] Finally, there's the dynamic load balancing distribution scheme used in commercial products like F5 BIG-IP. This scheme monitors the load of each CPU core in real time and dynamically distributes newly arriving data packets to the CPU core with the lowest current load, resulting in good load balancing. However, its drawbacks include the significant system overhead introduced by dynamic monitoring and decision-making, and this real-time load-based distribution method can also disrupt session affinity, requiring session state to be shared or frequently migrated across multiple CPU cores, leading to high implementation complexity and poor cache friendliness.

[0008] In summary, existing traffic distribution schemes generally suffer from performance losses due to unbalanced loads, low cache hit rates and high memory access latency due to frequent cross-core accesses, high management overhead and maintenance costs due to complex implementation schemes, and poor scalability that makes them difficult to adapt to dynamic changes in the number of CPU cores or traffic patterns. Therefore, how to achieve dynamic and adaptive intelligent traffic distribution while ensuring session affinity and cache friendliness, and simultaneously considering implementation simplicity and system scalability, has become a pressing technical problem to be solved in the field of multi-core network devices. Summary of the Invention

[0009] To address the aforementioned technical problems, this invention proposes an intelligent traffic distribution method and system based on session affinity, thereby resolving the issues present in the prior art.

[0010] To achieve the above objectives, the present invention provides an intelligent traffic distribution method based on session affinity, comprising: Receive data packets and check whether a matching session exists based on the five-tuple information of the data packets; If no matching session is found, the load status of each CPU core is obtained, the CPU core with the lowest load is selected as the target CPU core, a new session is created for the data packet based on the five-tuple information, and the ID of the target CPU core is bound to the new session. If a matching session is found, the ID of the bound CPU core is obtained, and it is determined whether the ID of the CPU core currently processing the data packet is consistent with the ID of the bound CPU core. If they match, the data packet is processed by the current CPU core. If there is a discrepancy, the data packet is placed in the FDM queue corresponding to the bound CPU core, so that the bound CPU core can retrieve the data packet from the FDM queue for processing.

[0011] Optionally, the 5-tuple information includes the source IP address, destination IP address, source port number, destination port number, and protocol type; the structure of the session contains forward and reverse 5-tuple hash index information and a field for storing the CPU core ID.

[0012] Optionally, the process of placing the data packet into the FDM queue corresponding to the bound CPU core includes: retrieving the CPU core ID bound in the session, finding the corresponding FDM queue based on the CPU core ID, determining whether the available space of the FDM queue is sufficient, and if sufficient, enqueuing the data packet through an atomic operation; wherein, the FDM queue is a circular queue, and each CPU core independently sets up one FDM queue; each circular queue contains a fixed number of queue nodes, and each node stores a data packet pointer and a function pointer for processing the data packet.

[0013] Optionally, the atomic operations include: When enqueuing, the atomic write pointer moves forward and performs a bitwise AND operation on the value after subtracting one from the total number of nodes in the queue to achieve indexing cycle. When dequeuing, the atomic read pointer moves forward and performs a bitwise AND operation on the value after subtracting one from the total number of nodes in the queue to achieve indexing cycle.

[0014] Optionally, the process of determining whether the available space in the FDM queue is sufficient includes: The total number of nodes in the queue is calculated by subtracting the number of nodes occupied by the atomic write pointer and adding the number of nodes taken away by the atomic read pointer. If the result is less than the preset minimum number of remaining nodes, it is determined that there is insufficient available space.

[0015] Optionally, the process of the bound CPU core retrieving the data packet from the FDM queue for processing includes: each CPU core cyclically detecting its corresponding FDM queue; when the queue is not empty, atomically obtaining the index position of the atomic read pointer; obtaining the queue node information based on the index position; reading the data packet pointer and processing function pointer stored in the node; atomically incrementing the index value of the atomic read pointer; and calling the processing function to process the data packet.

[0016] Optionally, the process of the bound CPU core retrieving the data packets from the FDM queue for processing also includes batch processing: A reference count is set up, and the reference count is incremented by 1 for each data packet retrieved from the FDM queue. When the reference count reaches a preset batch threshold, the network interface card is triggered to continue receiving packets, and the reference count is cleared to zero. When the reference count has not reached the batch threshold, data packets are retrieved from the current FDM queue for processing.

[0017] Optionally, the process of obtaining the load status of each CPU core includes: A timer is set for each CPU core, with a preset period. Within each period, the total number of data packets received by the current CPU core from the network interface card (NIC) is counted. The maximum number of packets received by the current CPU core from the NIC driver interface each time is obtained, as is the number of times the current CPU core calls the NIC driver interface within the period. The maximum receiving capacity is obtained by multiplying the maximum number of packets by the number of calls. The total number of data packets is multiplied by 100 and compared with the maximum receiving capacity. If the product is less than the maximum receiving capacity, the load rate is 0; if the product is greater than or equal to 100 times the maximum receiving capacity, the load rate is 100. Otherwise, the load rate is calculated by iterative subtraction: the maximum receiving capacity is repeatedly subtracted from the product, with an incrementing count for each subtraction, until the remaining value is less than the maximum receiving capacity. The incremented count is the load rate.

[0018] Optional features also include dynamic load balancing: The load rate of each CPU core is periodically calculated, and the CPU core with the highest load rate and the CPU core with the lowest load rate are selected. The difference between the two is calculated. If the difference exceeds a preset imbalance threshold, session migration is triggered. The session migration includes: within the period, counting the number of times each session is matched, selecting the M sessions with the fewest matches from the sessions processed by the CPU core with the highest load rate, and modifying the CPU core ID bound to the M sessions to the CPU core ID with the lowest load rate, wherein the value of M is determined according to the difference.

[0019] The present invention also provides an intelligent traffic distribution system based on session affinity for performing the above method, comprising: The slow path session binding module is used to create a new session based on the five-tuple information of the data packet when no matching session is found, and bind the selected CPU core ID to the new session; The load monitoring and decision unit is used to obtain the load status of each CPU core when creating a new session and select the CPU core ID with the lowest load as the selected CPU core ID, and to periodically trigger dynamic load balancing. The CPU affinity binding module is used to determine whether the ID of the CPU core currently processing the data packet is consistent with the ID of the CPU core bound in the session when a matching session is found. The fast path distribution module is used to have the current CPU core process the data packet when the current CPU core ID matches the CPU core ID bound in the session; The queue management module is used to independently set up an FDM queue for each CPU core. When the current CPU core ID is inconsistent with the CPU core ID bound in the session, the data packet is placed into the FDM queue corresponding to the bound CPU core, so that the bound CPU core can retrieve the data packet from the FDM queue for processing.

[0020] Compared with the prior art, the present invention has the following advantages and technical effects: This invention significantly improves session affinity by binding data packets to the least loaded CPU core during session creation and prioritizing the distribution of subsequent data packets from the same session to that bound CPU core for processing. This avoids cross-core access to session state, thereby reducing cache coherency protocol overhead, increasing CPU cache hit rate, and lowering memory access latency. By independently setting up an FDM queue for each CPU core and employing atomic operations for lock-free enqueueing and dequeueing, lock contention is avoided. Combined with a batch processing mechanism, function call overhead is further reduced, improving distribution efficiency. Adaptive load balancing is achieved by periodically monitoring CPU load and dynamically migrating inactive sessions, avoiding hot CPUs and improving overall CPU utilization and system throughput. Furthermore, this invention is simple to implement, requires no dedicated hardware support, is highly scalable, and can flexibly adapt to changes in the number of CPU cores and traffic patterns. Attached Figure Description

[0021] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating the session creation process in an embodiment of the present invention; Figure 2 This is a schematic diagram of the FMD queue structure according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the data packet queuing process according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the data packet dequeueing process according to an embodiment of the present invention; Figure 5 This is a flowchart illustrating the intelligent distribution decision-making process according to an embodiment of the present invention. Figure 6This is a flowchart of the dynamic load balancing process according to an embodiment of the present invention. Detailed Implementation

[0022] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0023] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0024] Example 1 This embodiment provides an intelligent traffic distribution method based on session affinity, including: (1) CPU affinity binding during session creation; When a network session is created, the system automatically obtains the CPU core ID currently processing the packet and binds it to the session structure. Subsequent packets matching the session's five-tuple (source IP, destination IP, source port, destination port, protocol) will be preferentially distributed to that CPU core for processing. If the CPU ID processing the packet is not equal to the CPU ID stored in the session, the packet is re-placed in the FDM queue corresponding to the stored CPU ID and re-entered into the protocol stack for processing by the specified CPU, ensuring that packets with the same five-tuple are processed on the same CPU core.

[0025] The session structure st_session contains the CPU ID field, the five-tuple information of the forward and reverse packets, and the Layer 2 header information required for fast forwarding.

[0026] The data packet structure `st_pkb` contains pointers to Ethernet Layer 2, Layer 3, and Layer 4 headers and session information for matching. Specifically, it includes a `pstSession` pointer, a pointer to the receiving device `pstDev`, a pointer to the sending device `pstOutDev`, the packet length `ulLen`, a pointer to the header of the packet buffer `pucHead`, a pointer to the tail of the packet buffer `pucEnd`, a pointer to the beginning of valid information in the packet buffer `pucData`, and a pointer to the packet's routing information `pstRt`. The five-tuple information used for matching sessions is stored in the Layer 3 and Layer 4 header pointers (source and destination IP addresses and protocol fields are in the Layer 3 header pointer, and source and destination port numbers are in the Layer 4 header pointer).

[0027] Session creation process as follows Figure 1 As shown, a detailed description follows: Step 1: The data packet arrives at the network protocol stack.

[0028] Step 2: Check if a matching session exists. Compare the 5-tuple information in the data packet with the 5-tuple information stored in the session. If they match completely, the data packet is considered to have matched this session, indicating that the session for this data packet exists. If it exists, proceed to Step 3. If no match is found, it means that the session information for the data packet does not exist. If it does not exist, proceed to Step 4.

[0029] Step 3: Determine whether the CPU ID saved in the session is consistent with the CPU ID currently processing the data packet. If they are consistent, proceed to step 6; otherwise, proceed to step 5.

[0030] Step 4: Create a new session and save the current CPU ID to the ulCpuId field in the session structure. Proceed to Step 6.

[0031] Step 5: Add this data packet to the FDM queue corresponding to the CPU ID saved in the session, re-enter the protocol stack, and re-enter Step 1.

[0032] Step 6: Continue processing data packets using the current CPU core.

[0033] The above process improves session affinity, increases cache hit rate, reduces memory access latency, and avoids cross-core access to session state.

[0034] (2) A fast distribution mechanism based on FDM queues; The system creates an independent FDM (Flow Distribution Manager) queue for each CPU core. Each FDM queue is a circular queue containing a fixed number of queue nodes (e.g., 4096 nodes). Packets are enqueued and dequeued atomically without locks, achieving high-performance distribution. The FDM queue structure is as follows: Figure 2 As shown.

[0035] For an 8-core CPU, there are 8 such queues in the system; for a 16-core CPU, there are 16 such core queues. Each queue has 4096 nodes, containing packet pointers and function pointers for processing packets. At system startup, both the atomic write and read pointers point to node 0. As the system runs, if the CPU core currently processing a packet is not one of the CPU cores saved in its session, the `EnQueue` function is called to add the current packet to this circular queue. Each time a packet is added, the write pointer atomically moves one position forward (atomic_inc(FdmQueue->atWrite)&4095). When it reaches a relatively late position, such as greater than 4000, when a new packet needs to be added to the queue, it checks if the available space in the queue meets the storage requirements. If not, it refuses to add the packet. The available space in the queue is the number of remaining available nodes, which is 4096 - write&4095 + read&4095, where 4096 is the number of nodes occupied by the write pointer and the number of nodes removed by the read pointer. When the write pointer points to 4095, moving it one more bit will return it to position 0. This is achieved using a bitwise AND operation, which is more efficient than a modulo operation.

[0036] Each CPU core in the system continuously loops and checks its corresponding FDM queue. If the number of available nodes is not equal to 4096, data is retrieved from the queue according to the position of the read pointer and re-sent to the network protocol stack for processing. Simultaneously, the read pointer is atomically moved one position forward (atomic_inc(FdmQueue->atRead)&4095), pointing to the next position. When it points to 4095, moving it one position forward again points to position 0, also implemented using a bitwise AND operation with 4095, which is more efficient than modulo operations. In this way, the FDM queue is constantly adding and removing data. However, in most cases, the queue is empty because firewall devices typically have 8, 16, or 32 CPU cores, with higher-performance devices possibly having 64 cores. Compared to the number of packets being processed, the number of CPU cores is negligible. Therefore, the situation where the number of CPU cores processing the current packet is not equal to the number of CPU cores stored in the session is not particularly frequent. This queue is mainly used to handle such inequalities, so adding this FDM queue has a very small and negligible increase in CPU performance. However, without such an FDM queue, although the number of CPU cores processing packets is not equal to the number of CPU cores stored in the session is not particularly frequent, the back-and-forth cross-core access and synchronization of session state, as well as frequent CPU cache misses, will lead to a significant performance reduction.

[0037] The joining process is as follows Figure 3 As shown, a detailed description follows: Referring to step 3 of the CPU affinity binding during session creation above, this process begins with step 3.

[0038] Step 1: Check if the CPU ID saved in the session matches the CPU ID currently processing the packet. If they don't match, retrieve the CPU ID saved in the session. (core_id=session->ulCpuId) Step 2: Based on the CPU ID retrieved in Step 1, find its corresponding FDM queue. (pstFdmQueue = g_pstFdmQueue + core_id, where g_pstFdmQueue is a global FDM queue pointer, pointing to the FDM queue corresponding to core 0, and g_pstFdmQueue + n points to the FDM queue corresponding to the nth core).

[0039] Step 3: Determine if the FDM queue has enough available space. If not, return failure directly. If it does, proceed to Step 4.

[0040] Step 4: Obtain the index position of the write pointer using atomic operations.

[0041] Step 5: Retrieve the node pointer from this position.

[0042] Step 6: Populate queue node pointers (data packet PKB pointers, and the data packet processing functions). Step 7: Move the pointer atom one position to the right.

[0043] The departure process is as follows Figure 4 As shown, a detailed description follows: Step 1: Obtain the current CPU ID and find the FDM queue corresponding to the current CPU ID.

[0044] Step 2: Check if the queue is empty. If it is empty, return 0 directly. If it is not empty, proceed to Step 3.

[0045] Step 3: Atomically obtain the index position of the read pointer.

[0046] Step 4: Obtain the node information of the FDM queue based on the position of the read pointer.

[0047] Step 5: Read node data (including packet PKB pointers and function pointers for processing packets).

[0048] Step 6: Increase the index value of the read pointer of the atom so that it points to the next position.

[0049] Step 7: Call the processing function to process the data packet PKB.

[0050] Step 8: Increment the reference count by 1, because the count represents the number of data packets retrieved.

[0051] Step 9: Check if the reference count is greater than or equal to 32. If it is, the network card continues to receive packets. Otherwise, proceed directly to Step 2 until the reference count equals 32, at which point the network card continues to receive packets, and the reference count is reset to zero. Otherwise, only process the data in the current FDM queue.

[0052] Batch processing mechanism: Each time data packets are dequeued, the system processes multiple packets consecutively, reducing function call overhead and context switching.

[0053] The above process enables each CPU to have its own independent queue, avoiding lock contention; atomic operation lock-free design for high-performance enqueue / dequeue; batch processing to reduce function call overhead; and circular queue design for contiguous memory and cache-friendly operation.

[0054] (3) Intelligent distribution decision-making mechanism; The system intelligently selects the distribution path based on the current load. Data packets for which a session is found are distributed according to the fast distribution mechanism of the FDM queue described above (traffic traffic for a found session uses the fast path and is directly distributed to the bound CPU). Data packets for which no session is found are dynamically distributed based on the current load of each CPU core to balance and improve the utilization of each CPU core (traffic traffic for which no session is found uses the slow path, and dynamic load balancing decisions are made to determine which CPU core it is bound to based on the current load). The specific scheme is as follows: Step 1: The data packet arrives at the network protocol stack, and the 5-tuple in the packet cannot find a matching session.

[0055] Step 2: Calculate the load of each CPU core and find the CPU core ID with the lowest load rate.

[0056] Step 3: Create a session using the 5-tuple in the current data packet, and save the CPU ID obtained in Step 2 in the ulCpuId field of the session. The current packet is processed directly using the current CPU core, even though the current CPU core may not be the one with the lowest load, because this is the first packet, and processing a packet slowly has little impact on performance.

[0057] Step 4: When subsequent packets with the same 5-tuple arrive at the protocol stack in either the forward or reverse direction, a matching session is found. The CPU ID stored in the session is checked against the CPU ID currently processing the packet. If they do not match, the fast distribution mechanism of the FDM queue described above is initiated. If they match, the current CPU core is used directly for processing.

[0058] The core of this mechanism is how to find the CPU core ID with the lowest load rate. Since the calculation method for the usage rate of all CPU cores is the same, the calculation method for one CPU core is taken as an example for description as follows: Each CPU core periodically counts the number of data packets received within a period of time. For example, if the timer period is 2 seconds, the total number of data packets received by this CPU core within this time period is recorded as count, and the usage rate of this CPU core is obtained by dividing count by data x and multiplying by 100%. The calculation method of x is as follows: Different burst values are set respectively according to different platforms and CPU models.

[0059] burst is the maximum number of packets that each CPU core can receive from the DPDK driver interface each time, and this value is a fixed value for a fixed platform and CPU model.

[0060] Let times be the number of times the CPU core calls the DPDK packet receiving driver interface within one timer period, then x=burst*times.

[0061] The calculation formula of count is as follows: Within one timer period, it is assumed that r1 packets are actually received when the DPDK packet receiving driver interface is called for the first time, r2 packets are received for the second time, ..., and rn packets are received for the nth time. Therefore, the total number of packets received in this period is count=r1+r2+...+rn, where n=times. r1, r2, ..., rn are all less than or equal to burst.

[0062] Therefore, the usage rate of this CPU core is use_rate=count / x*100%. This algorithm can reflect the current situation of data packets processed by each CPU core. A larger use_rate indicates that the core processes more data packets and has a higher load; conversely, a smaller use_rate indicates that the core processes fewer data packets and has a lower load.

[0063] However, when calculating the CPU usage rate in this embodiment, for performance considerations, floating-point numbers, division and multiplication operations are not used, but integers, addition and subtraction operations are used instead. The specific replacement method is as follows: Let the dividend be dividend and the divisor be divisor.

[0064] dividend=count*100 divisor=x If dividend<divisor, then use_rate=0.

[0065] If dividend>=divisor*100, then use_rate=100.

[0066] Under normal circumstances, divisor<=dividend<divisor*100. Using divisor<=dividend as the loop control condition, the value of use_rate is calculated multiple times in the loop control block, so that dividend=dividend-divisor; then let use_rate=use_rate+1; After a certain number of loops, the condition divisor<=dividend will definitely no longer hold. At this time, the loop is exited, the calculation is ended, and then the value of use_rate is returned, which is the usage rate of this CPU core.

[0067] Calculate the usage rates of all CPU cores according to the above method, find the core ID with the lowest load, and the newly created session will use this CPU core for processing.

[0068] The intelligent distribution decision process is as Figure 5 shown.

[0069] Through the above process, the traffic of the session in matching is made to take the fast path to avoid repeated decision-making; and the session is dynamically migrated according to the load condition.

[0070] (4) Dynamic load balancing mechanism; The system periodically (e.g. every 2 seconds) checks the load status of each CPU core. When the load imbalance degree exceeds a threshold (e.g. 20%), session migration is triggered, and some sessions are migrated from CPUs with high load to CPUs with low load.

[0071] The timer periodically checks the load status of each CPU core. According to the calculation method of CPU core usage rate, the CPU core with the highest load and the CPU core with the lowest load are found. If the imbalance degree reaches the threshold (e.g. 20%), session migration is triggered, and some inactive sessions are migrated from the high-load CPU core to the low-load CPU core. The threshold calculation method is: high-load CPU core usage rate minus low-load CPU core usage rate. For example, the usage rate of core 1 is 80%, and the usage rate of core 2 is 50%, then the imbalance degree between them is 80%-50%=30%. If it is greater than the threshold, session migration is triggered. Migration is to modify the ulCpuId of the session, whose original value is the high-load CPU core ID, and change it to the low-load CPU core ID. According to the "fast distribution mechanism based on FDM queue" introduced above, subsequent data packets with the same five-tuple as this session will be distributed to the CPU core with relatively low load.

[0072] Then, the system finds the second highest and second lowest CPU core load rates. If their imbalance exceeds a threshold, session migration is triggered. This process continues, finding the third highest and third lowest, fourth highest and fourth lowest, and so on, up to the Nth highest and Nth lowest CPU core load rates. If their imbalance exceeds a threshold, session migration is also triggered. N depends on the total number of CPU cores and the overall imbalance. For example, for an 8-core CPU, N <= 4; for a 16-core CPU, N <= 8. The value of N is also highly dependent on the overall imbalance. If the difference between the highest and lowest utilization rates does not exceed the threshold, session migration is unnecessary. If the difference between the second highest and second lowest utilization rates does not exceed the threshold, the search continues. This process continues until two CPU core IDs with imbalances less than the threshold are found, or all CPU cores have been traversed. After migration, the utilization rates of each CPU core will reach a more balanced state, preventing situations where a single CPU core is overloaded and unable to process packets, resulting in packet loss. It also reduces instances where low-loaded CPU cores remain idle for extended periods. This improves overall CPU utilization and efficiency.

[0073] The criterion for identifying inactive sessions is based on the number of packets from a particular session that are matched within a given timer period. The M sessions that are matched the fewest times within this timer period are then migrated to CPU cores with lower load rates. The value of M depends on the degree of load imbalance between the two CPU cores; the greater the imbalance, the larger the value of M, and vice versa. The overall goal is to reduce the imbalance between the two CPU cores to below a threshold, ideally approaching zero.

[0074] Dynamic load balancing process as follows Figure 6 As shown, a detailed description follows: Step 1: Start the timer.

[0075] Step 2: Periodically calculate the utilization rate of each CPU core.

[0076] Step 3: Find the CPU cores with the highest and lowest usage rates, and calculate whether their imbalance exceeds a threshold (e.g., 20%). If it does, trigger session migration to move some inactive sessions to CPU cores with lower load rates.

[0077] Step 4: Continue to find the CPU cores with the second highest and second lowest usage rates, and calculate whether their imbalance exceeds the threshold. If it does, trigger session migration to migrate some inactive sessions to CPU cores with lower load rates.

[0078] Step 5: Similarly, find the CPU core load rates with the third highest and third lowest utilization, the fourth highest and fourth lowest utilization, ... the Nth highest and Nth lowest utilization, calculate whether their imbalance is greater than the threshold, and if it is greater than the threshold, trigger session migration.

[0079] The migration strategy is as follows: 1. Periodic checks: For example, checking the load every 2 seconds; 2. Threshold triggering: Migration is triggered only when the imbalance exceeds 20%; 3. Gradual migration: Migrate a small number of sessions at a time to avoid drastic fluctuations; 4. Prioritize inactive sessions: Only migrate sessions that are not currently processing packets or are processing a small number of packets.

[0080] This embodiment also provides an intelligent traffic distribution system based on session affinity for performing the above method, including: The slow path session binding module is used to create a new session based on the five-tuple information of the data packet when no matching session is found, and bind the selected CPU core ID to the new session; The load monitoring and decision unit is used to obtain the load status of each CPU core when creating a new session and select the CPU core ID with the lowest load as the selected CPU core ID, and to periodically trigger dynamic load balancing. The CPU affinity binding module is used to determine whether the ID of the CPU core currently processing the data packet is consistent with the ID of the CPU core bound in the session when a matching session is found. The fast path distribution module is used to have the current CPU core process the data packet when the current CPU core ID matches the CPU core ID bound in the session; The queue management module is used to independently set up an FDM queue for each CPU core. When the current CPU core ID is inconsistent with the CPU core ID bound in the session, the data packet is placed into the FDM queue corresponding to the bound CPU core, so that the bound CPU core can retrieve the data packet from the FDM queue for processing.

[0081] This invention improves session affinity, avoids cross-core access to session state, and enhances session management efficiency. It reduces cross-core access, increases cache hit rate, lowers memory access latency, and improves network forwarding performance. A dynamic traffic adjustment strategy avoids hot CPUs, improving CPU load balancing and utilization. The code is minimal, simple to implement, easy to maintain and extend, and requires no dedicated hardware support. It is highly scalable, adaptable to different CPU core counts, adapts to changes in traffic patterns, and supports dynamic expansion.

[0082] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A smart traffic distribution method based on session affinity, characterized in that, Includes the following steps: Receive data packets and check whether a matching session exists based on the five-tuple information of the data packets; If no matching session is found, the load status of each CPU core is obtained, the CPU core with the lowest load is selected as the target CPU core, a new session is created for the data packet based on the five-tuple information, and the ID of the target CPU core is bound to the new session. If a matching session is found, the ID of the bound CPU core is obtained, and it is determined whether the ID of the CPU core currently processing the data packet is consistent with the ID of the bound CPU core. If they match, the data packet is processed by the current CPU core. If there is a discrepancy, the data packet is placed in the FDM queue corresponding to the bound CPU core, so that the bound CPU core can retrieve the data packet from the FDM queue for processing.

2. The intelligent traffic distribution method based on session affinity according to claim 1, characterized in that, The quintuple information includes the source IP address, destination IP address, source port number, destination port number, and protocol type; the session structure contains forward and reverse quintuple hash index information and a field for storing the CPU core ID.

3. The intelligent traffic distribution method based on session affinity according to claim 1, characterized in that, The process of placing the data packet into the FDM queue corresponding to the bound CPU core includes: retrieving the CPU core ID bound in the session, finding the corresponding FDM queue based on the CPU core ID, determining whether the available space of the FDM queue is sufficient, and if sufficient, enqueuing the data packet through an atomic operation; wherein, the FDM queue is a circular queue, and each CPU core independently sets up one FDM queue; each circular queue contains a fixed number of queue nodes, and each node stores a data packet pointer and a function pointer for processing the data packet.

4. The intelligent traffic distribution method based on session affinity according to claim 3, characterized in that, The atomic operations include: When enqueuing, the atomic write pointer moves forward and performs a bitwise AND operation on the value after subtracting one from the total number of nodes in the queue to achieve indexing cycle. When dequeuing, the atomic read pointer moves forward and performs a bitwise AND operation on the value after subtracting one from the total number of nodes in the queue to achieve indexing cycle.

5. The intelligent traffic distribution method based on session affinity according to claim 4, characterized in that, The process of determining whether the available space in the FDM queue is sufficient includes: The total number of nodes in the queue is calculated by subtracting the number of nodes occupied by the atomic write pointer and adding the number of nodes taken away by the atomic read pointer. If the result is less than the preset minimum number of remaining nodes, it is determined that there is insufficient available space.

6. The intelligent traffic distribution method based on session affinity according to claim 1, characterized in that, The process of the bound CPU core retrieving the data packet from the FDM queue for processing includes: each CPU core cyclically checks its corresponding FDM queue; when the queue is not empty, it atomically obtains the index position of the atomic read pointer, obtains the queue node information based on the index position, reads the data packet pointer and processing function pointer stored in the node, atomically increments the index value of the atomic read pointer, and calls the processing function to process the data packet.

7. The intelligent traffic distribution method based on session affinity according to claim 6, characterized in that, The process of the bound CPU core retrieving the data packets from the FDM queue for processing also includes batch processing: A reference count is set up, and the reference count is incremented by 1 for each data packet retrieved from the FDM queue. When the reference count reaches a preset batch threshold, the network interface card is triggered to continue receiving packets, and the reference count is cleared to zero. When the reference count has not reached the batch threshold, data packets are retrieved from the current FDM queue for processing.

8. The intelligent traffic distribution method based on session affinity according to claim 1, characterized in that, The process of obtaining the load status of each CPU core includes: A timer is set for each CPU core, with a preset period. Within each period, the total number of data packets received by the current CPU core from the network interface card (NIC) is counted. The maximum number of packets received by the current CPU core from the NIC driver interface each time is obtained, as is the number of times the current CPU core calls the NIC driver interface within the period. The maximum receiving capacity is obtained by multiplying the maximum number of packets by the number of calls. The total number of data packets is multiplied by 100 and compared with the maximum receiving capacity. If the product is less than the maximum receiving capacity, the load rate is 0; if the product is greater than or equal to 100 times the maximum receiving capacity, the load rate is 100. Otherwise, the load rate is calculated by iterative subtraction: the maximum receiving capacity is repeatedly subtracted from the product, with an incrementing count for each subtraction, until the remaining value is less than the maximum receiving capacity. The incremented count is the load rate.

9. The intelligent traffic distribution method based on session affinity according to claim 1, characterized in that, It also includes dynamic load balancing: Periodically calculate the load rate of each CPU core, select the CPU core with the highest load rate and the CPU core with the lowest load rate, and calculate the difference between the two. If the difference exceeds a preset imbalance threshold, a session migration is triggered; The session migration includes: within the period, counting the number of times each session is matched, selecting the M sessions with the fewest matches from the sessions processed by the CPU core with the highest load rate, and modifying the CPU core ID bound to the M sessions to the CPU core ID with the lowest load rate, wherein the value of M is determined according to the difference.

10. A smart traffic distribution system based on session affinity, characterized in that, For performing the method according to any one of claims 1 to 9, comprising: The slow path session binding module is used to create a new session based on the five-tuple information of the data packet when no matching session is found, and bind the selected CPU core ID to the new session; The load monitoring and decision unit is used to obtain the load status of each CPU core when creating a new session and select the CPU core ID with the lowest load as the selected CPU core ID, and to periodically trigger dynamic load balancing. The CPU affinity binding module is used to determine whether the ID of the CPU core currently processing the data packet is consistent with the ID of the CPU core bound in the session when a matching session is found. The fast path distribution module is used to have the current CPU core process the data packet when the current CPU core ID matches the CPU core ID bound in the session; The queue management module is used to independently set up an FDM queue for each CPU core. When the current CPU core ID is inconsistent with the CPU core ID bound in the session, the data packet is placed into the FDM queue corresponding to the bound CPU core, so that the bound CPU core can retrieve the data packet from the FDM queue for processing.

Images