Method and apparatus for restoring a session data set

Abstract

This invention relates to a method and apparatus for restoring session data packets. The method includes using a hardware acceleration module to process session data, calculate hash values, and split the data into session data fragments. A default core in an underloaded state within a central processing unit (CPU) is allocated to each session data fragment. The hardware acceleration module then allocates traffic buckets to the session data fragments based on the hash values ​​of the session data, binding unbound traffic buckets to the default core. A software platform receives the session data fragments and sends them to the CPU core bound to the traffic bucket according to the traffic bucket. The method provided by this invention achieves high-speed processing, low-latency transmission, and load balancing through hardware, avoiding CPU resource overload and processing bottlenecks. Furthermore, the CPU affinity-based flow allocation strategy ensures that the same session data is processed by a fixed core, achieving high performance, low latency, and stable reliability for restoring session data packets in high-speed networks.

Description

Technical Field

[0001] This invention belongs to the field of data transmission and data reconstruction technology, specifically relating to a method and apparatus for restoring session data packets. Background Technology

[0002] With the rapid growth of network traffic, session data packet reconstruction in high-speed networks has become a core requirement for network security monitoring. Session data packet reconstruction refers to the process of reconstructing complete session-level business data by identifying protocols, classifying flows, and reassembling data packets that are transmitted discretely and arrive out of order in the network according to network sessions.

[0003] Traditional session packet reassembly is implemented purely in software, relying on the operating system kernel or user-space processing framework. This involves multiple data copies and context switches, resulting in limited processing performance, high latency, high CPU (Central Processing Unit) resource consumption, and poor scalability, making it difficult to meet the line-speed processing and real-time detection requirements of high-speed networks. To alleviate these bottlenecks, related technologies implement some network processing functions on additional hardware, offloading some computational tasks from the CPU to hardware execution. However, these technologies lack dedicated hardware support for session-level packet reassembly and do not fully consider the flexibility requirements of programmable session reassembly systems. Other technologies achieve high-performance packet processing through dedicated hardware circuits, but suffer from insufficient flexibility and struggle to adapt to evolving network protocols and service requirements. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention provides a method and apparatus for restoring session data packets.

[0005] The present invention includes a method for restoring session data packets, comprising: receiving session data using a hardware acceleration module; processing the session data and calculating hash values ​​using the hardware acceleration module, splitting the session data into session data fragments, and allocating a default core in an underloaded state in a central processing unit (CPU) to the session data; wherein the hash value is calculated based on the source IP address, destination IP address, source port, destination port, and protocol type of the session data; allocating traffic buckets to the session data fragments using the hardware acceleration module based on the hash values ​​of the session data, and binding the traffic buckets to the default cores in response to the allocated traffic buckets not being bound to cores; transmitting the session data fragments to the software platform of the CPU using the hardware acceleration module through the traffic buckets; receiving the session data fragments using the software platform, and sending the session data fragments to the CPU core bound to the traffic bucket according to the traffic bucket from which the session data fragments were sent; and reassembling the session data fragments using the cores to obtain reconstructed session data.

[0006] Optionally, the hardware acceleration module is a programmable gate array (PGA), the software platform is a data plane development kit, and the PGA and the data plane development kit transmit data through a high-speed serial computer expansion bus.

[0007] Optionally, the method further includes: monitoring the traffic of all traffic buckets using the aforementioned software platform; in response to detecting that the traffic of a traffic bucket exceeds a preset traffic threshold, moving the session data fragment in the traffic bucket to a preset high-flow traffic bucket using the aforementioned hardware acceleration module; wherein the aforementioned high-flow traffic bucket is bound to a preset high-flow core; the method further includes: monitoring the load of all cores using the aforementioned software platform, and modifying the binding relationship between traffic buckets other than the aforementioned high-flow traffic bucket and cores other than the aforementioned high-flow core using the aforementioned hardware acceleration module and the aforementioned software platform based on the aforementioned load.

[0008] Optionally, the aforementioned hardware acceleration module stores an indirect table, the entries of which include the current bound core, migration status, and target bound core for each traffic bucket; the aforementioned monitoring of the load of all cores using the aforementioned software platform, and modifying the binding relationship between traffic buckets other than the aforementioned high-flow traffic buckets and cores other than the aforementioned high-flow cores using the aforementioned hardware acceleration module and the aforementioned software platform based on the aforementioned load, includes: monitoring the aforementioned load of all cores using the aforementioned software platform; in response to the current core's maximum load exceeding a preset load threshold or the load difference between the current core and another core exceeding a preset balancing threshold, determining at least one traffic bucket bound to the current core as a target traffic bucket; using the aforementioned software platform to write another target core other than the current core into the target bound core of the aforementioned target traffic bucket in the aforementioned indirect table, and writing the first status into the migration status of the aforementioned target traffic bucket in the aforementioned indirect table; in response to the aforementioned hardware acceleration... When the module allocates session data to the target traffic bucket, it reads the first state, allocates the currently received session data to the current core, writes the target core into the indirect table as the currently bound core of the target traffic bucket, and writes the second state into the indirect table as the migration state of the target traffic bucket. In response to the hardware acceleration module reading the second state when allocating session data to the target traffic bucket, and allocating the received session data to the target core, it writes the third state into the indirect table as the migration state of the target traffic bucket. Simultaneously, in response to the software platform reading the second state when receiving session data fragments from the target traffic bucket, it sends the currently received session data fragments to the buffer queue. In response to the software platform reading the third state when receiving session data fragments from the target traffic bucket, it prioritizes sending the session data fragments in the buffer queue to the target core.

[0009] Optionally, it also includes: using the hardware acceleration module to start timing after binding a traffic bucket to the default core, and in response to the traffic bucket not receiving session data fragments during the time from the start of timing to the time reaching a preset time threshold, unbinding the traffic bucket from the current core.

[0010] Optionally, the above session data is processed and hash value is calculated, including: extracting the first 1024 bits of the header vector of the above session data; parsing the header vector to obtain action instructions; extracting the source IP address, destination IP address, source port, destination port, and protocol type of the above session data from the header vector according to the action instructions; calculating the hash value of the above session data according to the source IP address, destination IP address, source port, destination port, and protocol type of the above session data; and replacing at least a portion of the header vector with the hash value.

[0011] Optionally, the above-mentioned use of the core to reassemble the above-mentioned session data fragments to obtain reassembled session data includes: using the core to obtain the hash value of the above-mentioned session data fragments, and determining the session node of the above-mentioned session data fragments based on the hash value and the red-black tree embedded in each of the above-mentioned traffic buckets; and reassembling the above-mentioned session data fragments of the same session node to obtain reassembled session data for each session node.

[0012] Based on the same inventive concept, the present invention also provides a session data grouping and reconstruction device, including a hardware acceleration module, a central processing unit (CPU), and a software platform within the CPU, wherein: the hardware acceleration module is used to receive session data; the hardware acceleration module is also used to process the session data, calculate hash values, and split the session data into session data fragments, and allocate a default core in the CPU that is in an underloaded state to the session data; wherein the hash value is calculated based on the source IP address, destination IP address, source port, destination port, and protocol type of the session data; the hardware acceleration module is also used to allocate traffic buckets to the session data fragments based on the hash value of the session data, and in response to the allocated traffic bucket not being bound to a core, bind the traffic bucket to the default core; the hardware acceleration module is also used to transmit the session data fragments to the software platform of the CPU through the traffic buckets; the software platform is used to receive the session data fragments and, according to the traffic bucket from which the session data fragments were sent, send the session data fragments to the core of the CPU bound to the traffic bucket; the CPU is used to reassemble the session data fragments using the core to obtain reconstructed session data.

[0013] Based on the same inventive concept, the present invention also provides an electronic device, comprising: a processor; a memory for storing executable instructions; wherein the processor is configured to read the executable instructions from the memory and execute the executable instructions to implement any of the methods described above.

[0014] Based on the same inventive concept, the present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the processor performs any of the above-described methods.

[0015] The beneficial effects of this invention are as follows: This invention provides a session data metagram restoration method that deeply integrates hardware acceleration and software processing. It can achieve high-speed processing, low-latency transmission and load balancing by relying on hardware, avoiding CPU resource overload and processing bottlenecks. The CPU affinity-based flow allocation strategy can also ensure that the same session data is processed by a fixed core, improving cache hit rate and multi-core parallel efficiency. Ultimately, it achieves high performance, low latency and stable reliability of session data metagram restoration under high-speed networks. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a session data packet recovery method provided in an embodiment of the present invention; Figure 2 A schematic diagram of a module architecture for implementing a session data group report restoration method is provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the top-level module architecture in a hardware acceleration module provided in an embodiment of the present invention; Figure 4 A flowchart illustrating a session query method provided in an embodiment of the present invention; Figure 5 A flowchart illustrating a method for reassembling session data fragments provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of a session data packet recovery device provided in an embodiment of the present invention; Figure 7This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0019] To better understand the above-mentioned objectives, features, and advantages of the embodiments of the present invention, the solutions of the embodiments of the present invention will be further described below. It should be noted that, unless otherwise specified, the embodiments of the present invention and the features thereof can be combined with each other.

[0020] Many specific details are set forth in the following description in order to provide a full understanding of the embodiments of the present invention, but the embodiments of the present invention may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some embodiments of the embodiments of the present invention, and not all embodiments.

[0021] One embodiment of the present invention provides a method for restoring session data packets, such as... Figure 1 As shown, it includes: S1. Receive session data using the hardware acceleration module.

[0022] Session data refers to the collection of all interactive data packets generated by a complete network connection (session) established by the same user and the same application in the network, including all messages and service content transmitted bidirectionally from the establishment to the closure of the connection. In some embodiments, the above-mentioned hardware acceleration module is a Field Programmable Gate Array (FPGA). An FPGA is a semi-custom programmable integrated circuit. Users can freely configure a large number of logic blocks, interconnect resources, and I / O units inside the chip using hardware description languages ​​such as Verilog / VHDL, and repeatedly "build" arbitrary digital circuits (such as processors, accelerators, and interface controllers) after leaving the factory, combining hardware-level parallel performance with software-level flexible reconfigurability. In other embodiments, any programmable hardware acceleration module that can implement the embodiments of the present invention in related technologies can be used as the above-mentioned hardware acceleration module, such as ASIC (Application Specific Integrated Circuit), smart network card, etc. At the same time, for ease of understanding, some embodiments of the present invention will use FPGA to refer to the hardware acceleration module, which does not limit the methods in the embodiments to be implemented only by FPGA.

[0023] S2. The hardware acceleration module is used to process the session data and calculate the hash value, and split it into session data fragments. A default core in the CPU that is underloaded is allocated to the session data. The hash value is calculated based on the source IP address, destination IP address, source port, destination port and protocol type of the session data.

[0024] Network data packets have a maximum length limit. Complete session data exceeding this limit must be broken down into smaller data fragments for normal transmission. Fragmentation also improves link utilization, avoids congestion, adapts to the processing capabilities of different network devices, and ensures stable data delivery. A hash value is a fixed-length, unique identifier calculated using a hash algorithm on input data of arbitrary length (such as a network 5-tuple). It is used to quickly locate, match, and index sessions or data, improving search and processing efficiency. Session data fragments belonging to the same session have the same hash value. An underloaded core refers to a CPU core with a low current task load and remaining processing power.

[0025] S3. The hardware acceleration module allocates traffic buckets to session data fragments based on the hash value of the session data. In response to the fact that the allocated traffic bucket is not bound to a core, the traffic bucket is bound to the default core.

[0026] Assigning traffic buckets based on hash values ​​ensures that data from the same session is consistently allocated to the same bucket, guaranteeing flow integrity. Simultaneously, each traffic bucket is bound to a core, ensuring affinity between the same session data and the same CPU core, improving cache hit rate, and reducing context switching overhead. Furthermore, based on the above method, the following embodiments of the present invention support load balancing and dynamic flow migration by traffic bucket, avoiding large-scale flow interference and achieving efficient multi-core parallel processing. In specific implementation, when allocating traffic buckets, if the allocated traffic bucket is already bound to a core, the binding phase is skipped, and the session data fragment is directly sent to the bound core via the allocated traffic bucket in step S4 below.

[0027] S4. A software platform that uses hardware acceleration modules to transmit session data fragments to the central processing unit via a traffic bucket.

[0028] In some embodiments, the software platform described above is a Data Plane Development Kit (DPDK). DPDK is a high-performance user-space network processing framework that achieves zero-copy and batch packet sending and receiving by bypassing the operating system kernel and directly accessing the network card hardware, significantly reducing packet processing latency and CPU consumption. It is commonly used in high-speed network scenarios for packet forwarding, traffic processing, and parallel computing. In other embodiments, any software capable of implementing the embodiments of the present invention in related technologies can serve as the aforementioned software platform, such as XDP (eXpress Data Path), Netmap, etc. For ease of understanding, some embodiments of the present invention will use DPDK to refer to the software platform, which does not limit the methods in the embodiments to be implemented only by DPDK.

[0029] In some embodiments, the aforementioned programmable gate array and planar development kit transmit data via a high-speed serial computer expansion bus (Peripheral Component Interconnect express, PCIe). PCIe enables high-bandwidth, low-latency data transmission and control command interaction between the host CPU / memory and external hardware devices such as FPGAs, smart network cards, and accelerator cards. It supports bidirectional communication and DMA (Direct Memory Access), and can improve transmission rates through multiple channels. It is the core hardware interface for realizing FPGA hardware and DPDK software collaboration, configuration distribution, and data uploading in the embodiments of this invention.

[0030] S5. Receive session data segments using the software platform, and send the session data segments to the core of the central processing unit bound to the traffic bucket according to the traffic bucket that sent the session data segments.

[0031] S6. Use the core to reassemble the session data fragments to obtain reassembled session data.

[0032] DPDK bypasses the kernel and adopts user-space polling and batch packet sending and receiving, which can significantly reduce session data processing latency and CPU overhead. Combined with a multi-core lock-free architecture and zero-copy mechanism, it can efficiently complete session reassembly, stream lookup and data forwarding in high-speed networks, and fully improve the throughput and real-time performance of session data processing.

[0033] This invention provides a session data metagram restoration method that deeply integrates hardware acceleration and software processing. It can achieve high-speed processing, low-latency transmission and load balancing through hardware, avoiding CPU resource overload and processing bottlenecks. Based on the CPU affinity flow allocation strategy, it can also ensure that the same session data is processed by a fixed core, improving cache hit rate and multi-core parallel efficiency. Ultimately, it achieves high performance, low latency and stable reliability for session data metagram restoration under high-speed networks.

[0034] Furthermore, the above embodiments of the present invention offload the tasks of protocol parsing, session feature calculation, and stream classification to FPGA hardware, allowing the CPU core to focus on complex session state maintenance and data splicing, thereby reducing the overall CPU load and improving single-core processing capability; FPGA preprocessing achieves single-cycle parsing, and combined with the DPDK zero-copy mechanism, the end-to-end processing latency is significantly reduced compared to traditional solutions, meeting the stringent latency requirements of real-time security detection scenarios.

[0035] The method provided in this invention can be widely applied to network security monitoring, and specifically for real-time traffic analysis, intrusion detection, and threat intelligence extraction.

[0036] In practice, DPDK directly accesses the hardware's DMA buffer, avoiding data copying from kernel mode to user mode.

[0037] In practice, the software periodically reads the hardware statistical counter to monitor processing performance.

[0038] In practice, the status of critical session data is synchronized between hardware and software via control messages.

[0039] Figure 2 The overall architecture of the modules required in the embodiments of the present invention is shown. The FPGA mainly includes a protocol-independent parser for processing data, a feature hash module for calculating hash values, and a session scheduling module for transmitting data. The CPU and the DPDK mounted on the CPU include a load synchronization module, a session management module, and a data reassembly module. The reassembled session data will be pushed to the user terminal as a service.

[0040] Specifically, the above-mentioned hardware and software collaborative processing flow includes: Hardware preprocessing: The FPGA receives network data packets, completes protocol parsing, keyword extraction, and CRC (Cyclic Redundancy Check) calculation (specifically, the CRC calculation result is the hash value mentioned above), and transfers the processed session data fragments (including the CRC result) to the host memory via DMA; Software batch reception: The DPDK working core receives session data fragments in batches through polling and extracts the CRC result generated by the hardware; Fast session lookup: The software uses the hardware CRC result to directly locate the session table, avoiding repeated calculation of hash values ​​by the software; State update and reassembly: The CPU reassembles the data according to the session state and updates the sequence number information; Data output: When the push conditions are met, the CPU outputs the reassembled data to the business layer through a callback function.

[0041] The following embodiments of the present invention will further describe the working method of each module.

[0042] In another, more specific embodiment, the hardware acceleration module specifically includes a top-level module for processing data and calculating hash values. The top-level module instantiates a complete processing pipeline, and its parameterized design defines the bit width characteristics of the data path: a 512-bit data bus (a channel for transmitting 512 bits of data at a time), a 128-bit metadata bus (a channel for transmitting 128 bits of auxiliary information at a time), supporting 64-byte line-rate processing. Input data undergoes bit-width conversion via a 64-to-512 module, converting 64-bit received session data into 512-bit internal data via a format conversion unit (64-bit MAC (Media Access Control) interface to a 512-bit internal bus). Then, it enters a data multiplexing module that merges the four input data streams into one output stream (two port receives + two DMA (Direct Memory Access) receives). The data multiplexing module uses a weighted round-robin arbiter to ensure bandwidth balance and guarantee fair and orderly transmission of the four data streams. The data then enters the processing core of the top-level module.

[0043] like Figure 3 As shown, the top-level module processing core further includes a keyword extraction module, a protocol-independent parser, a keyword generation module, a hash calculation module, and a data combination module. In this embodiment, the hardware acceleration module's process of processing session data and calculating hash values ​​includes: S21. Extract the first 1024 bits of the session data header vector.

[0044] S21 is executed by the keyword extraction module. This module is responsible for extracting key information for flow classification from the input packets using a double-buffered FIFO (First In First Out) process, supporting uninterrupted processing of continuous packets. When the end-of-packet marker (tlast) is detected, the module outputs both session data and the packet header vector simultaneously, ensuring data integrity and consistency.

[0045] S22. Parse the head vector to obtain the action instructions.

[0046] Action commands are the control and information interaction interface between the header vector parsing results and subsequent stream processing units. They are used to issue decision information after protocol identification and feature matching in the form of hardware-level commands, providing index pointing, field positioning, protocol type identification and validity verification for subsequent processing processes such as hash calculation. This decouples the parsing logic from the business processing logic, ensuring that the entire pipeline can complete uninterrupted protocol-independent message scheduling and session mapping within a single cycle, supporting line-speed processing and dynamic protocol adaptation in high-speed network scenarios.

[0047] S22 is executed by a protocol-independent parser. The protocol-independent parser employs a programmable bit selection strategy to achieve efficient message protocol identification and classification, allowing software to update rules within microseconds without interrupting the data flow. Based on the protocol-independent parser, the adaptation cycle for new protocols (such as SRv6) is shortened from weeks to days using traditional hardware reconfiguration, and can be implemented through software configuration without reprogramming the FPGA. The configurability of the parsing rules ensures system compatibility with historical protocol versions, reducing equipment replacement costs during network upgrades. The combination of hardware acceleration for stateless applications and fine-grained software processing for stateful applications balances high performance and flexibility, adapting to various scenarios such as network security monitoring, traffic auditing, and service quality analysis.

[0048] S23. Based on the action instructions, extract the session data source IP address, destination IP address, source port, destination port, and protocol type from the header vector.

[0049] S23 is executed by the keyword generation module. The keyword generation module adaptively extracts the source IP address, destination IP address, source port, destination port and protocol type 5-tuple from the header vector according to the offset field (including IP keyword offset and port number keyword offset, which are further explained in the following embodiments) in the action instruction, and generates a 328-bit session keyword to support subsequent CRC calculation and software layer session lookup.

[0050] S24. Calculate the hash value of the session data based on the session data source IP address, destination IP address, source port, destination port, and protocol type.

[0051] S24 is executed by the hash calculation module. The hash calculation module uses 288-bit parallel computing comparison software to process the hash latency byte by byte, reducing it from milliseconds to microseconds, and outputs a 128-bit result (including a 32-bit hash value, a 32-bit action instruction, and a 1-bit direction flag) to the data combination module.

[0052] S25. Replace at least part of the header vector with hash values.

[0053] S25 is executed by the data combination module, which combines the 128-bit result output by the hash calculation module with the original session data. The data concatenation is controlled by a state machine (idle state → combination state → additional state), and the processed session data is distributed to the DMA buffer or network port of the hardware acceleration module.

[0054] In practice, the keyword extraction module receives a 512-bit wide data stream, extracts the first 1024 bits of the message (i.e., session data) as the message header vector (phv), and outputs it to the subsequent protocol-independent parser and keyword generation module. Simultaneously, it outputs the original 512-bit session data to the final data integration module. Specifically, the first 512 bits of the header vector are stored in phv_out[1023:512], and the last 512 bits are stored in phv_out[511:0]. Downstream processing is triggered by the phv_out_wr signal.

[0055] In practice, the programmable protocol-independent parser receives a 1024-bit header vector and performs cross-clock domain transmission between the management clock domain (50MHz, synchronized with the PCIe clock) and the data clock domain (125MHz, data clock) via an asynchronous FIFO. Its output 40-bit action command is transmitted back to the data clock domain via the asynchronous FIFO, ensuring that configuration updates do not affect the data path. Then, the protocol-independent parser extracts 128-bit feature information from the input 1024-bit keyword data. It employs an 8-way parallel bit extraction architecture, with each way containing 16 configurable 16-bit position registers, forming a single-cycle extraction circuit from the 1024-bit message header vector to the 128-bit feature vector. The bit extraction unit receives the 1024-bit header vector from the preceding keyword extraction module and, based on the 16 10-bit offsets stored in the configuration register bit_def[15:0], extracts 16-bit features from any bit position in the header vector, combining them into a 16-bit output. The configuration data of the i-th bit extraction unit (i∈[0,7]) is 256 bits, divided into 16 16-bit fields. The high 6 bits of each field are the enable flag, and the low 10 bits are the bit offset address. When the i-th configuration write enable signal is set, the configuration update is completed within a single management clock cycle (20ns, 50MHz) without restarting the data path. This bit-level configurability differs from the byte alignment matching of traditional TCAM (Ternary Content Addressable Memory), supports feature extraction of any protocol field (such as SRv6), and shortens the new protocol adaptation time from the cycle level of traditional FPGA reconstruction to the single cycle level.

[0056] The programmable protocol-independent parser employs an 8-channel parallel matching unit during the matching phase, with each channel containing 16 128-bit mask rules. Each rule consists of a 128-bit matching value, a 128-bit mask, and a 40-bit action instruction. When the 128-bit feature vector is input, the 16 comparators execute the action of checking whether the input feature value matches the mask rule in parallel and output a 16-bit matching vector. The priority encoder selects the least significant bit (LSB) priority matching result and outputs the corresponding 40-bit action instruction `action_out`. The definition of each field in the action instruction `action_out` is shown in Table 1. Here, an IP version identifier of 1 indicates an IPv6 packet (extracting the 128-bit IP address); 0 indicates an IPv4 packet (extracting the 32-bit IP address); the transport layer protocol type identifier indicates the four-layer protocol type: 0x06, TCP, 0x11, UDP; Table 1: [39:32] 8 Index Action instruction number

[31] 1 Valid Valid bits

[30] 1 IP Version Flag IP Version Identifier [29:24] 6 Reserved Reserved bits [23:16] 8 Protocol Transport layer protocol types [15:8] 8 IP offset IP keyword offset [7:0] 8 Port offset Port number keyword offset In practical implementation, the keyword generation module also adopts a cross-clock domain asynchronous FIFO architecture to ensure reliable transmission of action commands between the management clock domain and the data clock domain, and controls the data extraction process through a two-level state machine. The keyword generation module has built-in address resolution logic, configured to extract transport layer and session identification information from a specified position in the header vector based on the offset field in the action command. When an IPv6 packet is detected, the module extracts 256 bits of IP address information (128 bits source IP and 128 bits destination IP) from the header vector; when an IPv4 packet is detected, it extracts 64 bits of IP address information (32 bits source IP and 32 bits destination IP) from the header vector and stores them in different bit fields of the keyword. Simultaneously, the module extracts 32 bits of port information (16 bits source port and 16 bits destination port), adjusting the byte order of the port field through bit swapping. The keyword generation module normalizes the session keyword into a fixed 328-bit format. The highest 40 bits store the original action command, bits 287 to 160 and bits 159 to 32 store IP address information (occupying all 256 bits for IPv6, and only 64 bits for IPv4), and bits 31 to 0 store port information. This keyword is output to the downstream CRC calculation module via the tcp_key signal, enabling hardware-accelerated generation of the session identifier.

[0057] In practical implementation, the hash calculation module adopts a pure combinational logic parallel computing architecture, capable of generating a hash checksum of 288 bits of input data within a single clock cycle, significantly improving the efficiency of flow table processing in high-throughput network environments. Bits 287 to 160 of the input data for the hash calculation module represent the destination IP address, bits 159 to 32 represent the source IP address, and the lower 32 bits represent port information. The hash calculation module extracts 288 bits of valid information from these fields (including source and destination IP addresses and port fields, excluding protocol type and action fields) as the basis for CRC calculation. To ensure consistent session identifiers generated by bidirectional data streams, the module incorporates direction determination logic. This logic is configured to compare the source and destination IP addresses as 128-bit unsigned integers. When the destination IP address is greater than the source IP address, the module maintains the original data order and sets the direction flag; otherwise, it swaps the positions of the source and destination IP address fields and clears the direction flag. Through this normalization process, regardless of the data flow direction, the 288-bit data sequence input to the hash calculation module remains consistent, thus achieving symmetry in bidirectional stream hash values.

[0058] The hash calculation module uses the standard CRC-32 (Ethernet) generator polynomial. , Indicates the first The initial value is configured as 0x00000000, and data input follows the most significant bit priority order. This unit directly expands combinational logic to implement single-cycle CRC calculation through a pre-computed 288-bit parallel XOR network of the generator polynomial. Finally, the hash calculation module concatenates the calculated 32-bit hash value, 32-bit action information field, 1-bit direction flag, 7-bit high-order index bits, and 56-bit reserved field into a 128-bit output result. Among them, the highest 32 bits of the result vector store the hash value, the second highest 32 bits store the original action information, the 64th bit stores the direction flag, the 63rd to 57th bits store the index information, and the remaining 56 bits are cleared and reserved, thus forming a complete session identifier for downstream software layers to perform fast flow table lookups.

[0059] In practical implementation, the precise control of the state machine and the custom tuser field in the data assembly module enables zero-overhead insertion of Flag markers used to identify message type, processing status, and transmission direction, without adding extra clock cycles. The data assembly module includes three operating modes. In normal mode, the output result crc_out of the 128-bit hash calculation module is inserted into the header vector, replacing the first 128 bits of the original session data header vector. In pass-through mode, data from the DMA channel is directly passed through without processing. In tail packet processing mode, special processing is supported for short packets (less than 512 bytes) of session data to ensure data integrity.

[0060] In practice, for the software platform, the software accesses registers in the following hardware acceleration modules through the PCIe BAR (Base Address Register) space. Specifically, the software platform constructs a configuration message (identifier header 0x1234) through the configuration write interface (1024 bits wide, actually using the lower 512 bits) of the protocol-independent parser, and writes it to the hardware's internal cached configuration data queue register via asynchronous FIFO. After the hardware verifies the format and validity of the software configuration message, it writes the queue register matching value, mask, and action instructions to the hardware register storing the preset matching value and the hardware register storing the matching mask in the parallel matching unit of the protocol-independent parser.

[0061] In one specific embodiment, the hardware-software interaction process includes an initialization phase, specifically: after the software initializes the network card through the DPDK initialization function, it calls a custom API (Application Programming Interface) to send service identification rules to the protocol-independent parser via PCIe. Configuration data (256 bits) in the code is written to the register array through the configuration interface managing the time domain, configuring the feature extraction position; simultaneously, configuration data (128 bits), the matching mask (128 bits), and the action command (40 bits) are written to the hardware registers in the parallel matching unit, which store the matching value and the action command, respectively. This process corresponds to the configuration state in the protocol-independent parser state machine.

[0062] The session scheduling module within the hardware acceleration module is a core component for implementing CPU load-aware group scheduling, flow-CPU affinity guarantees, and dynamic core scaling. In some embodiments, this module employs a hardware-software co-design, implementing efficient flow classification, load estimation, and scheduling decisions at the FPGA hardware level, and fine-grained load monitoring, dynamic core allocation, and flow migration management at the DPDK software level. This achieves overall system load balancing and CPU efficiency optimization while ensuring flow integrity.

[0063] In one specific embodiment, the session scheduling module includes a service identification and classification submodule, which is responsible for application-layer identification of incoming data packets, providing a decision-making basis for subsequent differentiated scheduling strategies. This module adopts a masked matching mechanism based on five-tuples, and completes high-speed classification through a hardware-implemented service identification table.

[0064] The service identification table is used to execute S2 as described above. It is stored using a TCAM or hash table structure. Each rule contains a five-tuple matching field (source IP, destination IP, source port, destination port, protocol type) and service identifier information. Upon successful matching, the corresponding service ID and the default assigned underutilized core ID are output. Unmatched traffic is uniformly categorized as the default service and assigned a backup core. The table content can be dynamically added, deleted, or modified by the software platform via the PCIe configuration interface, adapting to flexible changes in business needs.

[0065] Based on the identification results, session data is divided into two processing paths: Stateless application traffic: a simple scheduling mechanism such as round-robin is used, and the relevant parsing results are cached in the high-speed storage inside the FPGA to achieve hardware-level accelerated processing of subsequent traffic without software intervention; Stateful application traffic: enters the dynamic scheduling submodule, where the core allocation, load balancing and flow migration management are completed by hardware and software collaboration to ensure that data packets of the same session are always processed by the same CPU core, and resource allocation is dynamically adjusted according to the system load, i.e., the methods of S3 to S5 in the above embodiments.

[0066] The session scheduling module also includes an indirect table dynamic configuration and flow binding submodule, hereinafter referred to as the dynamic configuration module. This module maintains an indirect table that can be accessed in parallel inside the FPGA. The indirect table is deployed in the SRAM (Static Random Access Memory) within the FPGA. The low-order bits of the five-tuple hash value are used as the index (Bucket ID) of the flow bucket. The table entries include fields such as the valid bits of each flow bucket, the current binding core identifier (CID_c), the migration status flag (flag_t), the target binding core identifier (CID_n), and the count of packets to be processed (current core packet count PN_cc, new core packet technology PN_nc), as shown in Table 2.

[0067] Table 2: field name Bucket_ID CID_c CID_n flag_t PN_cc PN_nc In practice, S3 is executed by the scheduling module. When session data enters the scheduling module, it first completes application-layer identification through the Service ID Table. This table uses a masked 5-tuple matching method to output the service number and the default underloaded core number. Then, a hash operation is performed using the 5-tuple as the key (or the hash value obtained in the previous steps is used), and the lower eight bits are used as the indirect table index. The traffic bucket is located based on the indirect table index. If the valid bit of the corresponding traffic bucket's entry is 0 (invalid state), it indicates that the current traffic bucket is not bound to a core. The hardware writes the underloaded core number output from the Service ID Table into the currently bound core identifier field of that traffic bucket, binding the traffic bucket to the default core, setting the valid bit to 1, setting the migration status to 0, and recording the current hardware timestamp to the update time field. Simultaneously, an independent timer for that entry is started. Subsequent packets from the same stream (i.e., the same session data) are all located to this entry through the same hash index, ensuring that data packets from the same session are always allocated to the same CPU core, maintaining temporal locality.

[0068] In some embodiments, the above method further includes: After binding a traffic bucket to the default core using a hardware acceleration module, a timer is started. If the traffic bucket does not receive any session data fragments during the time period from the start of the timer until the timer reaches a preset time threshold, the traffic bucket is unbound from the current core.

[0069] The aforementioned independent timer decrements at a fixed period. When it decrements to zero and no new session data is received, the valid bit is automatically cleared, releasing the bucket resources of that traffic bucket for subsequent new flows to be reallocated.

[0070] In some embodiments, the above method further includes: The software platform monitors the traffic of all traffic buckets. In response to the detection that the traffic of a traffic bucket exceeds the preset traffic threshold, the hardware acceleration module moves the session data fragments in that traffic bucket to the preset high-flow traffic bucket. The high-flow traffic bucket is bound to the preset high-flow core.

[0071] Then, the software platform is used to monitor the load of all cores, and based on the load, the hardware acceleration module and the software platform are used to modify the binding relationship between the traffic buckets other than the high-flow buckets and the cores other than the high-flow cores.

[0072] The above embodiments of the present invention prevent the problem of high-volume traffic occupancy through high-volume isolation. Simultaneously, when performing load balancing and dynamic flow migration by traffic bucket, the dedicated high-volume traffic bucket is skipped, avoiding cache invalidation and performance fluctuations caused by frequent migration of high-volume traffic between cores, thus ensuring the stability and continuity of high-volume processing. The specific processes of load balancing and dynamic flow migration will be described in detail in the following embodiments.

[0073] In one specific embodiment, the entries of the above indirect table use the lower eight bits of the 5-tuple hash value as the index (Bucket ID) of the traffic bucket, supporting a maximum of 128 independent buckets (0-127), of which 0-119 are dynamically allocated buckets, and 120-127 are reserved for large flow isolation.

[0074] In practice, the hardware sets up a large flow isolation table after indirect table lookup. This table uses an exact match structure and stores the large flow quintuple information identified by traffic analysis and its independently allocated bucket identifier (120-127). After hashing the regular quintuple, the large flow isolation table is queried first. If a match is found, the pre-allocated independent bucket identifier is used directly, bypassing the above-mentioned regular hash allocation process, and bound to a specific large flow dedicated core (Core 0-7). When the software monitors that the traffic in a certain dynamic bucket (0-119) exceeds a predetermined threshold (more than 1GB within 10 seconds) detected by the EWMA (Exponentially Weighted Moving Average) algorithm, the software first copies the bucket table entry data (including core allocation, historical counts, etc.) to an idle large flow bucket in the range of 120-127, and then adds the mapping relationship between the flow quintuple and the independent large flow bucket in the large flow isolation table. After the migration is completed, the original dynamic flow bucket is cleared of its valid bits for use by the new flow, and the subsequent grouping of this large flow is directly mapped to the dedicated core through the large flow isolation table to ensure the stability and continuity of the large flow processing.

[0075] In some embodiments, the hardware acceleration module stores the aforementioned indirect table, and the entries in the indirect table include the current bound core, migration status, and target bound core for each traffic bucket.

[0076] The above method involves using a software platform to monitor the load of all cores and, based on the load, modifying the binding relationships between traffic buckets (excluding high-flow buckets) and cores (excluding high-flow cores) using hardware acceleration modules and the software platform (i.e., the dynamic flow migration process). This includes: S01. Utilize the software platform to monitor the load status of all cores. In response to the situation where the maximum load of the current core exceeds the preset load threshold or the load difference between the current core and another core exceeds the preset balancing threshold, determine at least one traffic bucket bound to the current core as the target traffic bucket.

[0077] S02. Using the software platform, write another target core other than the current core into the target binding core of the target traffic bucket in the indirect table, and write the first state into the migration state of the target traffic bucket in the indirect table.

[0078] S03. In response to the hardware acceleration module reading the first state when allocating session data to the target traffic bucket, the currently received session data is allocated to the current core, and then the target core is written into the indirect table as the currently bound core of the target traffic bucket, and the second state is written into the indirect table as the migration state of the target traffic bucket.

[0079] S04. In response to the second state being read when the hardware acceleration module allocates session data to the target traffic bucket, after allocating the received session data to the target core, the third state is written into the migration state of the target traffic bucket in the indirect table; at the same time, in response to the second state being read when the software platform receives session data fragments from the target traffic bucket, the currently received session data fragments are sent to the buffer queue; in response to the third state being read when the software platform receives session data fragments from the target traffic bucket, the session data fragments in the buffer queue are sent to the target core first.

[0080] The above embodiments of the present invention employ both dual-mark switching and cache priority mechanisms to achieve runtime flow-level core migration. During the migration process, data packets are not lost or out of order, ensuring session integrity.

[0081] Dynamic flow migration employs a three-level state machine to achieve zero-packet-loss switching. State 0 (the third state mentioned above) indicates normal allocation; State 1 (the first state mentioned above) indicates that the software has triggered migration preparation; State 2 (the second state mentioned above) indicates that the hardware is performing migration. When the DPDK software detects that a service meets the load balancing trigger condition, i.e., the maximum core load exceeds the upper limit threshold Tmax, or the load difference between cores exceeds the balancing threshold Tb, the software writes the target bound core number to the "Target Bound Core Identifier" field of the target bucket table in the indirect table through the PCIe configuration interface, and sets the migration state to 1. When the hardware detects that the state is 1 in the next clock cycle, it marks the currently arriving session data segment as the end of migration, still allocates it to the original bound core for processing, and automatically copies the value of "Target Bound Core" to the "Current Bound Core Identifier" field, and updates the migration state to 2. When the first subsequent session data segment arrives, the hardware detects that the state is 2, the session data segment is marked as the start of migration, allocated to the new core (i.e., the target bound core), and then the hardware sets the migration state to 0, completing the switchover.

[0082] For the software platform, when DPDK receives a session data segment and detects the second state, it does not immediately process the segment. Instead, it stores it in a circular buffer queue with an independent depth of 32 corresponding to that bucket and continues polling the receive queue until the third state is detected. After processing the session data segments marked as migration complete, the software responds to the third state by sending a switchover complete signal to the new core via PCIe. The new core then prioritizes processing the backlogged data in the buffer queue to ensure intra-flow order before processing newly arriving data. Simultaneously, the software performs precise bucket counting based on the bucket number carried by the session data segment, compares it with the count value maintained by the hardware, and completes the migration confirmation after verifying no packet loss.

[0083] In some embodiments, the software platform is further configured to maintain a service allocation core and load table. This table records the list of cores currently allocated to each service and the real-time load of each core, represented by the number of remaining queue groups, with a bit width of 32 bits. Specifically, each service includes multiple session data sets, and the service to which each session data set belongs can be represented by the hash value mentioned above. The software calculates the load distribution within each service at a fixed period (default 1 second). When it is determined that the maximum core load used to process session data for a certain service exceeds the upper limit threshold and the minimum core load also exceeds the lower limit threshold, a scaling-up process is triggered, and the software selects a new core from the unallocated core pool to add to the service. When it is determined that the load of a core is below the scaling-down threshold, a scaling-down process is triggered, and the software migrates all traffic buckets on that core to other active cores in the same service and then releases the resources. When it is determined that the difference between the maximum and minimum core loads within the same service exceeds the balancing threshold, a bucket-level migration is triggered, and traffic buckets on high-load cores, sorted by hardware count from smallest to largest, are migrated to low-load cores. In specific implementations, the execution objects in the load balancing process do not include the aforementioned high-flow traffic buckets and high-flow cores.

[0084] In some embodiments, to address sudden traffic surges and ensure real-time performance, the components in this embodiment further include a latency awareness and dynamic optimization submodule to achieve fine-grained dynamic optimization. The software supports configurable group latency sampling calculation, with a configurable sampling ratio (default 1 in 10). When groups are allocated from hardware to software, they carry a hardware timestamp. Upon completion of processing, the software reads the current time, calculates the processing latency, and averages the results to obtain the average processing latency of the service under the current configuration. When the average latency of a service exceeds a reference threshold, the service is deemed to have insufficient processing capacity, triggering the addition of a new core process. The software allocates a new core to the service and migrates small traffic buckets from high-latency cores to the new core, reducing the load on a single core and shortening the processing latency. Conversely, if the latency remains below the threshold and there are idle cores, core reclamation is triggered to improve resource utilization efficiency.

[0085] The above embodiments of the present invention are based on a core scaling mechanism with real-time load monitoring, which automatically detects core overload and underload states, triggers flow migration or core addition or deletion, improves the balance of core utilization, and avoids local hotspots caused by traditional fixed distribution.

[0086] In practice, the software platform writes to the indirect table memory in the hardware acceleration module via PCIe; the direction flag bit (1 bit) and index field (7 bits) in the hash calculation module are uploaded via DMA with each data packet. The software reads these fields in the bus, combines them with the traffic bucket number and migration status flag, and updates the CPU load table.

[0087] In practice, when the software determines that a migration is needed, it writes an entry to the indirect table of the target traffic bucket via PCIe. The hardware completes the state switch within the next clock cycle. In the hardware's data combination module, it sets the output to either a first or second state based on the migration state value. When the software detects the second state, it stores the packet in a buffer until it receives the third state, at which point it sends a confirmation of the switch completion by writing to the PCIe register.

[0088] In practice, once the software identifies a large flow, it writes the entry into the large flow 5-tuple to the parallel matching unit of the protocol-independent parser via PCIe, while simultaneously configuring action instructions. During subsequent hardware matching, the output flow bucket number is 120-127 (configured via action instructions), bypassing conventional hash allocation and directly binding to the dedicated large flow core.

[0089] In summary, the hardware identifies applications and initially allocates cores through a service identification table, maintains flow-core binding relationships through an indirect table, and carries bucket numbers, migration flags, and timestamps in the groups. The software periodically updates the service allocation core and load tables, and dynamically adjusts the mapping relationship between services and cores by combining latency sampling statistics. It triggers hardware migration by modifying fields in the indirect table through the PCIe interface. This collaborative architecture of real-time hardware scheduling and software policy control achieves service-level elastic scaling and differentiated service quality assurance. Large flows receive dedicated resources and processing stability, while small flows achieve load balancing and low-latency processing through dynamic allocation.

[0090] In specific implementation, the aforementioned hardware acceleration module further includes a receive data multiplexing module, a transmit data demultiplexing module, a receive data width conversion module, and a transmit data width conversion module. Specifically, the receive data multiplexing module receives session messages from different input sources; the receive data width conversion module receives the data stream from the receive data multiplexing module and converts its data width to a standard width supported by subsequent processing modules; the transmit data width conversion module receives standard width data output from the data processing pipeline and converts it to a width supported by the output target; and the transmit data demultiplexing module receives one standard data stream output from the transmit data width conversion module, demultiplexes it into multiple data streams according to preset rules, and distributes them to their respective output targets.

[0091] Specifically, the receive data multiplexing module is configured to achieve fair multiplexing and converged output of four input data streams (two port receives and two DMA receives) based on a polling arbitration mechanism, using a grant_4bits weighted polling arbitrator to ensure balanced bandwidth allocation. This module employs a two-stage FIFO buffer architecture, with each input configured with a 705-bit wide synchronous FIFO (1-bit message tail flag + 64-bit byte validity flag + 128-bit user-defined field + 512-bit data field) to achieve cross-clock domain data buffering and backpressure control. The module first detects data request signals from the four input channels. When any channel has a pending message and the output is ready, the grant_4bits arbitrator generates a 4-bit one-hot code based on the polling priority, and then selects one data stream for forwarding. The arbitrator has a built-in history register to ensure that the most recently authorized channel has a lower priority in the next round of arbitration, achieving fair scheduling. The module incorporates port identifier insertion logic, configured to embed a 4-bit port identifier into bits 111 to 108 of a user-defined field during the message header cycle. The lower two bits identify the port channel, and the higher two bits identify the DMA channel. The state machine employs a three-stage pipeline design (idle state → transmission state → wait state). In the transmission state, it continuously forwards data from the selected channel until the message tail flag is detected, after which it releases the bus and returns to the arbitration state. The module supports in-band flow control, monitoring the data count in each channel's FIFO. When the storage depth exceeds a threshold (e.g., 400 / 512), a reverse pressure signal is applied to prevent upstream data overflow. Data output maintains a 512-bit bus width, aligned with the downstream top-level module, achieving seamless connection of high-throughput data paths.

[0092] The data demultiplexing module is configured to accurately distribute one input data stream to four output channels (two port transmissions and two DMA transmissions) based on the packet header port identifier. This module parses the port identifier field in the user-defined field of the input data stream and controls the multi-output enable through one-hot code decoding logic, ensuring that the processed packets are forwarded to the target physical port or DMA channel. The module first detects the valid flag of the input FIFO. When a valid packet is detected and all output channels are ready, it extracts a 4-bit port identifier from bits 111 to 108 of the user-defined field. This identifier is encoded using one-hot code: bits [0] and [1] control the two port outputs respectively, and bits [2] and [3] control the two DMA outputs respectively. The module uses a two-level state machine (idle state → transmission state) to control the transmission process. In the transmission state, the module sets the corresponding output valid signal according to the 4-bit port identifier buffer value, and simultaneously broadcasts 512 bits of data, a 64-bit valid flag, and a 128-bit user field to all output channels, controlling the actual receiving end only through the enable signal. When a message tail flag is detected, the module synchronously sets the message tail flag signal for the corresponding channel, and then returns to the idle state to prepare for the next distribution. The module supports full-duplex flow control, and implements input reverse pressure by monitoring the ready signals of each output channel to ensure that data reading is suspended when downstream is blocked, preventing packet loss. This design realizes flexible flow splitting between the policy-based data plane and DMA plane, supporting mixed traffic management scenarios in network processing.

[0093] The data width conversion module is configured to perform 64-bit to 512-bit data width expansion and byte order conversion, employing a 4-stage shift register architecture to achieve data accumulation and alignment over 8 clock cycles. This module receives 64-bit little-endian data from the MAC layer, converts it to big-endian byte order through bit field rearrangement, and outputs 512-bit big-endian data in the 8th cycle to meet the bus width requirements of subsequent processing modules. The module uses a dual FIFO buffer mechanism: the data FIFO stores 128 bits of data and control information, while the valid FIFO marks message boundaries. A state machine (idle state → transmission state) controls the data reading process, tracking the data clock cycle using a 2-bit counter in the transmission state. The module incorporates bit-swapping logic to ensure correct byte order conversion; this logic is configured to reverse the order of the input 128-bit data byte by byte. During accumulation, the data in cycle 0 is stored in the high 128 bits of the output register, the data in cycle 1 in the second-highest 128 bits, and so on, with the data in the low 128 bits in cycle 3. Simultaneously, the data validity signal is set in cycle 3. The module supports non-full packet processing. When the length of the input message is less than 512 bytes, it generates a corresponding output mask based on the byte validity enable signal of the last valid period to ensure that the downstream module accurately identifies the valid byte boundary.

[0094] The data width conversion module is configured to perform 512-bit to 64-bit data width reduction and byte order inversion, using a time-division multiplexing architecture to split the 512-bit data into eight 64-bit segments for sequential output. This module receives 512-bit big-endian data from the processing plane, performs reverse bit field extraction and byte order conversion (big-endian to little-endian), and outputs 64-bit little-endian data to the MAC layer over eight clock cycles. This module employs a FIFO buffer structure symmetrical to the receiving module, using a data counter for input flow control. The state machine uses a three-level design (idle state → transmission state → waiting state), controlling the data splitting position using a 2-bit counter in the transmission state. This module supports dynamic tail packet processing, monitoring the input message tail flag signal and byte validity flag, setting the tail flag signal at the last valid segment, and accurately calculating the remaining number of bytes based on the current cycle position to generate the corresponding tail flag mask. This design achieves rate matching between the wide bus of the processing plane and the narrow interface of the MAC layer, ensuring data integrity under burst traffic.

[0095] The specific implementation methods on the software platform side will be described in detail below.

[0096] The software system adopts a multi-core parallel processing architecture. The system initialization process includes: EAL (Environment Abstraction Layer) initialization: calling the initialization function to initialize the DPDK runtime environment, parse command-line parameters, and initialize the memory pool and large page memory; Network interface card (NIC) port initialization: calling functions to configure the NIC port, setting parameters such as the number of receive / send queues, the number of descriptors, and the RSS (Receive Side Scaling) hash; Memory pool creation: creating an independent buffer memory pool for each receive queue, configuring the number of buffers and the cache size; Session management structure initialization: initializing data structures such as the IPv4 / IPv6 hash table, session free list, and fragment reassembly list; Timer system initialization: initializing the DPDK timer subsystem and configuring the session timeout detection timer.

[0097] The reception of session data segments is driven by DPDK polling mode, and data packets are received in batches through DPDK core functions. The reception process includes: Batch reception: Each working core receives data packets (up to 32) in batches from the allocated receive queue; Header parsing: Parses the Ethernet header and identifies protocols such as VLAN (Virtual Local Area Network), MPLS (Multi-Protocol Label Switching), IPv4, and IPv6 based on the type field; Hardware metadata extraction: Extracts the hash value results and action information inserted by the FPGA hardware for fast session lookup.

[0098] In some embodiments, S6 includes: S61. Session lookup: Obtain the hash value of the session data segment using the core, and determine the session node of the session data segment based on the hash value and the red-black tree embedded in each traffic bucket.

[0099] The hash value of a session data fragment can roughly determine its node, but sometimes multiple sessions may calculate the same hash value. In such cases, a red-black tree can assist in accurately locating the session node. A red-black tree is a self-balancing binary search tree whose core function is to efficiently store and quickly retrieve data.

[0100] S62. Session Reassembly: Reassemble the session data segments of the same session node to obtain reassembled session data for each session node.

[0101] Session data fragments belonging to the same session node are equivalent to belonging to the same session data, that is, the same user's request, the same business process, etc. Different session data fragments may be transmitted together. Reassembling them according to the session node can clearly distinguish the boundaries of different sessions, ensure that the fragments of each session correspond correctly, avoid data confusion between different sessions, and ensure the normal implementation of subsequent scheduling, load balancing and other functions.

[0102] In practice, the aforementioned session lookup process is implemented using the following method. The system is configured to achieve efficient management of large-scale concurrent sessions based on a hybrid index structure combining hash tables and red-black trees. This architecture guarantees stable session retrieval performance under high load by combining the O(1) average lookup complexity of hash tables with the O(log n) worst-case complexity of red-black trees. This hybrid index structure consists of a global session pool, a hash bucket array, and red-black tree nodes, supporting seamless processing of both IPv4 and IPv6 dual-stack protocols.

[0103] Before session lookup, session management is required. To ensure the uniqueness and direction-independent nature of session keys, the system incorporates a 5-tuple normalization logic. This logic is configured to compare the source IP address with the destination IP address (IPv4 uses a 32-bit unsigned integer comparison, while IPv6 uses a 128-bit byte order comparison). When the destination IP address is determined to be less than the source IP address, the positions of the source and destination IP addresses and port fields are automatically swapped. Through this sorting and normalization process, both bidirectional communication flows are mapped to the same session node, thereby achieving global consistency management of session data.

[0104] To ensure successful reassembly of frames that failed to be parsed by hardware, a complete protocol parse tree is configured in the software. This parse tree contains the hierarchical parsing structure of various network protocols, extracting the protocol header 5-tuple. The system uses the CRC32-IEEE standard algorithm (generating the same polynomial as the hardware version) to hash the normalized 5-tuple, generating a 32-bit hash value as the traffic bucket index. The hash table is divided into multiple traffic buckets (256 by default), each embedding an independent red-black tree to resolve hash collisions. Red-black tree nodes are embedded within the session object, achieving node management with zero additional memory overhead through this embedded structure.

[0105] In one specific embodiment, the session lookup stream is as follows: Figure 4 As shown, the process begins by locating the traffic bucket based on session characteristics. Specifically: if the session data segment is unparsed, extract the 5-tuple information (source IP, destination IP, source port, destination port, protocol type) from the segment, sort the 5-tuples to ensure the smaller IP address comes first, and then calculate the CRC32 hash value to locate the traffic bucket. If the data has already been parsed by hardware, directly extract the hash value to locate the corresponding traffic bucket. Next, search for a matching session node in a red-black tree. If a node is found, further monitor the session status and proceed to the session reassembly stage. If no node is found, allocate a new session node from the idle pool and insert it into the corresponding hash-based traffic bucket. If an idle object exists in the session pool, allocate a new session node directly based on the idle object; otherwise, create a new session using the malloc function.

[0106] In practice, the session lookup process is configured to execute the following steps: For data frames that fail to be parsed by the hardware, firstly, the five-tuple information (source IP, destination IP, source port, destination port, protocol type) is extracted from the packet header of the session data segment, and the above-mentioned normalized sorting is performed; secondly, the CRC function is called to calculate the 32-bit CRC hash value of the five-tuple, and the target traffic bucket is located by the hash value; subsequently, a lookup operation is performed in the red-black tree of the traffic bucket, and a comparison function is used to match session nodes. This function compares fields in the priority order of protocol type, source port, destination port, source IP, and destination IP; finally, if the lookup is successful, the pointer to the existing session node is returned and the role flag is updated; if not, a new session object is allocated from the idle pool. For data frames that are successfully parsed by the hardware, the hash value is directly extracted from the header and a red-black tree lookup is performed.

[0107] The session creation process is configured as follows: when a hash lookup returns null and system resources are sufficient, a pre-allocated session object is retrieved from the idle pool. The 5-tuple, timestamp, timeout counter, and other fields in its configuration block are initialized. A bidirectional role association is set, and the session node is inserted into the red-black tree of the corresponding hash value's traffic bucket. The insertion operation uses a Linux kernel-style red-black tree balancing algorithm to ensure the tree height is always maintained at O(logn) order of magnitude. Simultaneously, the system starts a DPDK timer to manage the session's lifecycle, with a default timeout of 120 seconds. After the timeout, the session deletion and resource reclamation process is automatically triggered.

[0108] In practice, the above session reorganization process is implemented through the following methods.

[0109] The TCP (Transmission Control Protocol) session state and hole management mechanism employs a dual management architecture combining a data fragment linked list and hole detection to achieve dynamic reassembly and reliable transmission of TCP data streams. This mechanism maintains a bidirectional linked list of data fragments to record consecutive received data intervals and identifies data holes based on sequence number continuity detection, thereby ensuring ordered reassembly and integrity verification of data even in out-of-order arrival scenarios.

[0110] Each complete TCP session data object (including both the local and peer ends) is configured with an independent data fragment management context. This context contains key fields such as the data fragment list header, data fragment counter, and sequence number baseline value. The data fragment list consists of multiple data fragment nodes, each maintained through a doubly linked list structure. Each node records the start and end sequence numbers of the data fragment, as well as a pointer to the linked list cached for that data fragment. When a TCP session data fragment arrives, the sequence number and payload length are first extracted from the fragment. Combined with the baseline sequence number of the current session, the absolute sequence number range is calculated. Then, the new data fragment is inserted into the appropriate position in the linked list using the data fragment update logic.

[0111] Specifically, the TCP data reassembly method includes: receiving data fragment packets, extracting the sequence number (seq_no) and payload length (payload_len); calculating the absolute sequence number: abs_seq = seq_no + base_seq, handling sequence number reversal, where base_seq is the base value for the sequence number to avoid duplicate sequence numbers caused by re-counting from 0 after reaching the maximum value; and searching the data fragment linked list to determine the insertion position. Figure 5As shown, the TCP data reassembly method also includes: handling overlap: if a new data segment overlaps with existing data, the overlapping part is truncated; merging adjacent data segments: if a new data segment is continuous with the preceding and following data segments, they are merged into one data segment; updating hole information: maintaining a hole linked list to record the data range that has not been received; triggering data push: when the push conditions are met (ACK confirmation, PUSH flag, or buffer full), the reassembled session data is pushed.

[0112] In practice, during data fragment management, the system automatically handles data overlap and boundary merging by comparing the sequence number ranges of new data fragments with those of existing data fragments. If the sequence numbers of new data fragments overlap with existing data fragments, redundant data is truncated based on the overlap position, retaining only the valid new data fragments. If the new data fragments are consecutive or overlap with adjacent data fragments, a merging operation is triggered, integrating multiple consecutive data fragments into a single data fragment and updating the corresponding linked list pointers and boundary values, thereby optimizing memory usage and reducing linked list traversal overhead.

[0113] For connection establishment tracking, when the system detects a SYN (Synchronize) message, it immediately initializes the session segment sequence number management context, records the initial sequence number, and sets the starting boundary for data reception. This initialization process synchronously allocates the first data segment node, establishes the initial structure of the data segment linked list, and provides a reference point for subsequent data reception.

[0114] For sequence number management, the mechanism in this embodiment of the invention employs a 64-bit extended sequence number space to address the flipping problem of the 32-bit sequence number in the TCP protocol. The system identifies sequence number flipping events by monitoring the comparison between the sequence number difference and a preset threshold, and dynamically adjusts the base sequence number (base_seq) to expand the range of valid sequence numbers, ensuring the uniqueness and continuity of sequence number calculation in long-term connections or high-volume transmission scenarios.

[0115] Regarding data reassembly, the aforementioned hole management mechanism identifies unreceived data intervals by traversing a linked list of data fragments, such as... Figure 5 As shown, when a data push operation is triggered, the system sequentially scans the data segment linked list, comparing the starting sequence number of each data segment with the position of the current push pointer. If a data segment's starting sequence number is detected to be greater than the current push pointer, a data gap is identified, and the system generates fill data based on the gap size or waits for subsequent data to arrive. If the data segments are consecutive, the system directly extracts the cached data from the data segment linked list and pushes it to the application layer via a callback interface. This process supports multiple triggering conditions based on the PUSH flag, ACK confirmation number, or cache capacity threshold to ensure timely data delivery.

[0116] For connection closure, when the system receives an end message or reset message, it immediately adjusts the session timeout timer counter to accelerate the session termination process. During the session timeout callback, the system first flushes the remaining received data in the data fragment list, then releases the data fragment node and its associated memory cache resources, and finally removes the session entry from the session hash table, completing resource reclamation and state cleanup. This mechanism ensures that even in the event of abnormal connection termination, received out-of-order data can still be pushed completely, avoiding data loss.

[0117] The aforementioned session data fragment reassembly also includes the reassembly of IPv4 and IPv6 fragments. Specifically, for IPv4, fragments of the same original session data are identified using the IP identifier field and reassembled according to the fragment offset field; for IPv6, reassembly is performed using the identifier (id) and offset fields in the fragment extension header. Furthermore, this embodiment of the invention also starts a timer for each fragment chain; reassembly chains that fail to complete within the timeout period are discarded.

[0118] This invention provides a flexible software platform data output interface, supporting the following output methods: Callback function output: By registering a callback function, the reconstructed session data is output to the upper-layer business application; File output: Supports writing data to a PCAP (Programmable Network Access Point) file for offline analysis; Kafka output: Data is pushed to a Kafka message queue through a producer thread.

[0119] It should be noted that the method of this embodiment can be executed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method of this embodiment, and the multiple devices will interact with each other to complete the above method.

[0120] It should be noted that some embodiments of the present invention have been described above. Furthermore, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0121] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, the present invention also provides a session data packet recovery device, such as... Figure 6 As shown, it includes a hardware acceleration module, a central processing unit (CPU), and a software platform within the CPU, wherein: The hardware acceleration module is used to receive session data.

[0122] The hardware acceleration module is also used to process session data, calculate hash values, and split session data into fragments, and allocate a default core in the CPU that is underloaded to the session data; the hash value is calculated based on the source IP address, destination IP address, source port, destination port, and protocol type of the session data.

[0123] The hardware acceleration module is also used to allocate traffic buckets based on the hash value of the session data fragments, and in response to the allocated traffic bucket not being bound to a core, to bind the traffic bucket to the default core.

[0124] The hardware acceleration module is also used to transmit session data fragments to the central processing unit via a traffic bucket software platform.

[0125] The software platform is used to receive session data fragments and, based on the traffic bucket that sent the session data fragments, send the session data fragments to the core of the central processing unit bound to that traffic bucket.

[0126] The central processing unit is used to reassemble session data fragments using the core to obtain reassembled session data.

[0127] This invention provides a session data metagram restoration device that deeply integrates hardware acceleration and software processing. It can achieve high-speed processing, low-latency transmission and load balancing through hardware, avoiding CPU resource overload and processing bottlenecks. Based on the CPU affinity flow allocation strategy, it can also ensure that the same session data is processed by a fixed core, improving cache hit rate and multi-core parallel efficiency. Ultimately, it achieves high performance, low latency and stable reliability for session data metagram restoration under high-speed networks.

[0128] For ease of description, the above apparatus is described in terms of its functions, divided into various modules. Of course, in implementing this invention, the functions of each module can be implemented in one or more software and / or hardware components.

[0129] The apparatus described above is used to implement the corresponding session data packet restoration method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0130] Figure 7 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention is shown.

[0131] like Figure 7 As shown, the electronic device may include a processor and a memory storing computer program instructions.

[0132] Specifically, the processor may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement embodiments of the present invention.

[0133] The memory may include a large-capacity storage device for information or instructions. For example, and not limitingly, the memory may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disk drive, a magneto-optical disk drive, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory may include removable or non-removable (or fixed) media. Where appropriate, the memory may be internal or external to the integrated gateway device. In a particular embodiment, the memory is a non-volatile solid-state memory. In a particular embodiment, the memory includes read-only memory (ROM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (Electrically Programmable ROM, EPROM), an electrically erasable programmable ROM (EEPROM), an electrically alterable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0134] The processor reads and executes computer program instructions stored in memory to perform the steps of the session data packet restoration method provided in this embodiment of the invention.

[0135] In one example, the electronic device may also include a transceiver and a bus. For example, Figure 7 As shown, the processor, memory, and transceiver are connected via a bus and communicate with each other.

[0136] A bus may be hardware, software, or both. For example, and not limitingly, a bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industrial Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a MicroChannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, a bus may include one or more buses. Although specific buses are described and illustrated in embodiments of the invention, the invention contemplates any suitable bus or interconnect.

[0137] The following are embodiments of a computer-readable storage medium provided in this invention. This computer-readable storage medium and the session data packet recovery methods of the above embodiments belong to the same inventive concept. For details not described in detail in the embodiments of the computer-readable storage medium, please refer to the embodiments of the session data packet recovery methods described above.

[0138] This embodiment provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform a session data packet restoration method.

[0139] Of course, the computer-executable instructions provided in the embodiments of the present invention are not limited to the above-described method operations, but can also perform related operations in the session data packet restoration method provided in any embodiment of the present invention.

[0140] Based on the above description of the implementation methods, those skilled in the art can clearly understand that the present invention can be implemented using software and necessary general-purpose hardware, and of course, it can also be implemented using hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk, or optical disk, etc., including several instructions to cause a computer cloud platform (which can be a personal computer, server, or network cloud platform, etc.) to execute the session data packet restoration method provided in the various embodiments of the present invention.

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

[0142] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments described above, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for restoring session datagrams, characterized in that, include: Utilize hardware acceleration modules to receive session data; The hardware acceleration module is used to process the session data, calculate hash values, and split the session data into session data fragments. A default core in an underloaded state of the central processing unit is allocated to the session data. The hash value is calculated based on the source IP address, destination IP address, source port, destination port, and protocol type of the session data. The hardware acceleration module allocates traffic buckets to the session data fragments based on the hash value of the session data. In response to the fact that the allocated traffic bucket is not bound to a core, the traffic bucket is bound to the default core. The software platform of the central processing unit is used to transmit the session data fragments through the traffic bucket using the hardware acceleration module. The software platform receives the session data fragments and, based on the traffic bucket from which the session data fragments were sent, sends the session data fragments to the core of the central processing unit bound to that traffic bucket. The core is used to reassemble the session data fragments to obtain reassembled session data.

2. The session data packet recovery method according to claim 1, characterized in that, The hardware acceleration module is a programmable gate array (PGA), and the software platform is a data plane development kit (DPT). The PGA and the DPT transmit data through a high-speed serial computer expansion bus.

3. The session data packet recovery method according to claim 1, characterized in that, The method also includes: The software platform monitors the traffic of all traffic buckets. In response to the detection that the traffic of a traffic bucket exceeds a preset traffic threshold, the hardware acceleration module moves the session data fragment in that traffic bucket to a preset high-traffic bucket. The high-traffic bucket is bound to a preset high-traffic core. The method further includes: The software platform is used to monitor the load of all cores, and based on the load, the hardware acceleration module and the software platform are used to modify the binding relationship between traffic buckets other than the high-flow bucket and cores other than the high-flow core.

4. The session data packet recovery method according to claim 3, characterized in that, The hardware acceleration module stores an indirect table, and the entries in the indirect table include the current bound core, migration status, and target bound core for each traffic bucket. The step of using the software platform to monitor the load of all cores, and modifying the binding relationship between traffic buckets (excluding the high-flow bucket) and cores (excluding the high-flow core) using the hardware acceleration module and the software platform based on the load, includes: The software platform monitors the load of all cores. In response to the maximum load of a current core exceeding a preset load threshold or the load difference between a current core and another core exceeding a preset balancing threshold, at least one traffic bucket bound to the current core is identified as a target traffic bucket. Using the software platform, another target core other than the current core is written into the target binding core of the target traffic bucket in the indirect table, and the first state is written into the migration state of the target traffic bucket in the indirect table; In response to reading the first state when allocating session data to the target traffic bucket using the hardware acceleration module, the currently received session data is allocated to the current core, and then the target core is written into the current bound core of the target traffic bucket in the indirect table, and the second state is written into the migration state of the target traffic bucket in the indirect table. In response to the second state being read when allocating session data to the target traffic bucket using the hardware acceleration module, after allocating the received session data to the target core, the third state is written into the migration state of the target traffic bucket in the indirection table; simultaneously, in response to the second state being read when receiving the session data fragment from the target traffic bucket using the software platform, the currently received session data fragment is sent to the buffer queue; in response to the third state being read when receiving the session data fragment from the target traffic bucket using the software platform, the session data fragment in the buffer queue is preferentially sent to the target core.

5. The session data packet recovery method according to claim 1, characterized in that, it also... include: After binding a traffic bucket to the default core using the hardware acceleration module, a timer is started. If the traffic bucket does not receive session data fragments during the time period from the start of the timer to the timer reaching a preset time threshold, the traffic bucket is unbound from the current core.

6. The session data packet recovery method according to claim 1, characterized in that, The session data undergoes data processing and hash calculation, including: Extract the first 1024 bits of the header vector from the session data; The head vector is analyzed to obtain the action command; Based on the action instruction, extract the source IP address, destination IP address, source port, destination port, and protocol type of the session data from the header vector; The hash value of the session data is calculated based on the source IP address, destination IP address, source port, destination port, and protocol type of the session data; Replace at least a portion of the header vector using the hash value.

7. The session data packet recovery method according to claim 1, characterized in that, The process of reconstructing the session data fragments using the core to obtain reconstructed session data includes: The hash value of the session data segment is obtained using the core, and the session node of the session data segment is determined based on the hash value and the red-black tree embedded in each traffic bucket. The session data segments of the same session node are reassembled to obtain the reassembled session data for each session node.

8. A session data packet recovery device, characterized in that, Includes a hardware acceleration module, a central processing unit, and a software platform within the central processing unit, wherein: The hardware acceleration module is used to receive session data; The hardware acceleration module is also used to process the session data, calculate hash values, and split the session data into session data fragments, and allocate a default core in an underloaded state of the central processing unit to the session data; wherein, the hash value is calculated based on the source IP address, destination IP address, source port, destination port, and protocol type of the session data; The hardware acceleration module is also used to allocate traffic buckets to the session data fragments according to the hash value of the session data, and in response to the allocated traffic bucket not being bound to a core, bind the traffic bucket to the default core; The hardware acceleration module is also used to transmit the session data fragments to the software platform of the central processing unit through the traffic bucket; The software platform is used to receive the session data fragments and, according to the traffic bucket that sent the session data fragments, send the session data fragments to the core of the central processing unit bound to the traffic bucket. The central processing unit is used to reassemble the session data fragments using the core to obtain reassembled session data.

9. An electronic device, characterized in that, include: processor; A memory for storing executable instructions; wherein the processor is configured to read the executable instructions from the memory and execute the executable instructions to implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The storage medium stores a computer program that, when executed by a processor, causes the processor to implement the method described in any one of claims 1 to 7.

Images