A session data packet restoration method, device and storage medium

Abstract

This invention belongs to the field of communications, specifically relating to a method, device, and storage medium for restoring session data group packets. The method employs a collaborative architecture of FPGA hardware and DPDK software: the FPGA side extracts and buffers the packet's five-tuple through a programmable protocol parsing module, completing IP fragmentation and reassembly; then, the elephant stream arbitration module distinguishes the stream type, performing hardware-level out-of-order reassembly and zero-copy DMA writing on the elephant stream to generate ordered reassembled data; the DPDK side parses the custom header attached to the FPGA and selects a fast or slow path to complete session reassembly. This invention, through hardware and software collaborative processing, effectively reduces the host CPU load, achieves a high-efficiency zero-copy data path, and significantly improves the processing performance of high-volume sessions and robustness in abnormal scenarios.

Description

Technical Field

[0001] This invention belongs to the field of communications, and specifically relates to a method, device and storage medium for restoring session data group messages. Background Technology

[0002] With the rapid development of cloud computing, 5G communication, and artificial intelligence applications, data center networks have fully entered the 100Gbps / 400Gbps ultra-high-speed era, and network traffic is growing exponentially. Against this backdrop, applications such as deep network traffic inspection (DPI), security auditing, and forensic analysis are placing higher real-time demands on session-level data packet reassembly (TCP / UDP Session Reassembly). However, the processing of massive data packets and the management of complex session states in ultra-high-speed network environments have become key bottlenecks restricting the performance of network security monitoring systems.

[0003] Traditional session packet reassembly primarily relies on software solutions, using the operating system kernel protocol stack or user-space network processing framework to complete packet capture, protocol parsing, and session reassembly. A typical process is as follows: after a packet is received by the physical network card, it enters the host memory via the PCIe bus, triggering a kernel interrupt; subsequently, a system call enters kernel mode, and after protocol header parsing, the packet is copied to the user-space buffer; finally, in user mode, five-tuple hash calculation, session table lookup, sequence number sorting, and data reassembly are performed. Under 100Gbps line-rate conditions, this solution faces severe challenges from both memory and I / O walls: even with DPDK polling to bypass the kernel protocol stack for single-port 100Gbps line-rate traffic, the CPU still bears significant overhead from protocol parsing, hash calculation, and memory copying. In 100Gbps mixed traffic scenarios, the pure DPDK solution exhibits persistently high CPU core utilization for session reassembly, and as the number of concurrent connections increases, DDR memory access latency becomes an insurmountable performance bottleneck, leading to a sharp increase in packet loss rate and a significant increase in processing latency.

[0004] To overcome the performance limitations of software solutions, the industry is gradually adopting SmartNIC and Data Processing Unit (DPU) technologies to offload network functions into hardware. Existing acceleration solutions mainly fall into the following three categories: (1) Dedicated smart NIC solution based on ASIC architecture. This type of solution implements functions such as RSS (Receive Side Scaling), RDMA, and OVS (Open vSwitch) offloading through dedicated hardware circuits, which can effectively reduce the CPU load on the host. However, the programmability of ASIC architecture is limited, and its fixed packet processing pipeline is difficult to adapt to complex session state machine logic, and cannot support the flexible flow classification and session reassembly requirements based on deep packet inspection (DPI).

[0005] (2) FPGA-based programmable smart NIC solution. FPGAs, with their reconfigurable characteristics, can achieve high-precision packet parsing, custom hash calculation, and flow table management, supporting the offloading of some network processing tasks to hardware execution. However, existing FPGA smart NIC solutions mainly focus on network virtualization acceleration (such as VirtIO offloading, SR-IOV) and storage acceleration (such as NVMe-oF), lacking dedicated hardware support for stateful session reassembly. Specifically, session-level data restoration requires maintaining a large connection state table (including sequence number tracking, out-of-order reassembly buffer, application layer protocol state machine, etc.), placing extremely high demands on FPGA on-chip storage resources (BRAM / URAM) and memory access bandwidth; at the same time, there is a lack of efficient collaboration mechanisms between the FPGA and the host DPDK software stack, making it difficult to achieve a layered processing architecture of "hardware preprocessing - software deep analysis".

[0006] (3) DPU solution based on SoC architecture. DPU achieves deep integration of control plane and data plane by integrating multi-core ARM processor and dedicated hardware accelerator. However, the general-purpose processor core built into DPU still faces the problem of insufficient computing power when processing 100Gbps level line-rate traffic. In addition, the programming model of DPU is complex, the software and hardware interface standards are not yet unified, the development threshold is high, and there are disadvantages in power consumption and cost in large-scale session entry management scenarios. Summary of the Invention

[0007] The technical problem to be solved by the present invention is to provide a method, device and storage medium for restoring session data group packets, which achieves high performance, low latency and flexible programmability of session-level traffic processing through a layered architecture of "hardware acceleration of critical paths and software processing of complex logic".

[0008] A method for restoring session data packets is implemented collaboratively using FPGA hardware (based on a programmable smart network interface card) and host DPDK software. The FPGA hardware includes a MAC unit, a programmable protocol parsing module, an IP fragmentation processing module, an elephant stream arbitration module, a flow table management module, an out-of-order reordering module, and an address translation module. After the message is received by the MAC processing unit, it is transmitted to the programmable protocol parsing module. The parsed message, 5-tuple information and transport layer control flag are obtained through deep packet inspection. The 5-tuple information and transport layer control flag are cached in the packet header vector PHV structure to obtain cached information. The cached information is concatenated with the parsed message to obtain the concatenated message. Unparsable messages are encapsulated with a custom header and sent to the DPDK software. The spliced ​​message is transmitted to the IP fragmentation processing module, where fragmentation detection and reassembly processing are performed to obtain non-fragmented messages and reassembled messages. The unfragmented packets and reassembled packets are transmitted to the Elephant Stream Arbitration Module. Based on the traffic statistics and the determination of the flow type, Elephant Stream packets and Mouse Stream packets are obtained. The Mouse Stream packets are encapsulated with a custom header and then sent to the DPDK software. The elephant stream packet is transmitted to the flow table management module. After the flow direction is normalized, a normalized quad is obtained. The normalized quad is hashed to obtain the flow table index. Based on the flow table index, the chip URAM level 1 flow table cache and the off-chip DDR4 level 2 complete flow table are queried in sequence to obtain the query result. After the query result is hashed to resolve the collision, the hit flow table entry, the expected sequence number and the nextmbuf virtual address pointer are obtained. The elephant stream packets are associated with the hit flow table entries to obtain associated packets. A DMA descriptor is obtained from the FPGA hardware idle queue. The host physical address is obtained based on the DMA descriptor. The address translation module converts the host physical address into a DPDK virtual address and writes it to the nextmbuf virtual address pointer to update the hit flow table entries. Based on the comparison result of the packet sequence number and the expected sequence number, zero-copy DMA writing or out-of-order buffering and chain merging is performed on the associated packets based on the updated flow table entries to obtain ordered reassembled data. The packet sequence number is the sequence number that each processed packet carries to identify its own order during network transmission. The DPDK software selects a fast reassembly path or a slow reassembly path based on the message's custom header, performs session reassembly on the ordered reassembled data, and obtains the restored complete session message.

[0009] Optionally, the step of transmitting the spliced ​​message to the IP fragmentation processing module, and obtaining non-fragmented messages and reassembled messages through fragmentation detection and reassembly processing, includes: The IP fragmentation processing module detects the fragmentation flag and fragment offset field in the IPv4 header or the IPv6 fragmentation extension header, and determines whether the concatenated packet is fragmented or unfragmented. If it is a fragmented packet, the hash index of the fragmented packet is calculated using the CRC32 algorithm based on the source IP address, destination IP address and fragment identifier. The reassembly status is then searched in the fragmented context buffer of the on-chip SRAM according to the hash index. Hardware-level fragmentation and reassembly of the fragmented packet is then performed according to the reassembly status to obtain a reassembled packet. If the packet is not fragmented, output the packet as a non-fragmented packet.

[0010] Optionally, unfragmented packets and reassembled packets are transmitted to the Elephant Stream Arbitration Module. After traffic statistics and flow type determination, Elephant Stream packets and Mouse Stream packets are obtained. Mouse Stream packets are encapsulated with a custom header and then sent to the DPDK software, including: The Elephant Stream Arbitration module performs traffic statistics on unfragmented packets and reassembled packets to obtain the cumulative number of bytes for the corresponding stream; The cumulative number of bytes in the stream is compared with a preset threshold to determine whether it is an elephant stream packet or a mouse stream packet. If it is a rat stream message, then the rat stream message is encapsulated with a custom header and sent to the DPDK software; If it is an elephant flow message, then output the elephant flow message directly.

[0011] Optionally, the elephant stream packets are transmitted to the flow table management module. After flow direction normalization, normalized quadruplets are obtained. A hash calculation is performed on the normalized quadruplets to obtain the flow table index. Based on the flow table index, the on-chip URAM level-one flow table cache and the off-chip DDR4 level-two complete flow table are queried sequentially to obtain the query results. After hash collision handling, the query results are used to obtain the matched flow table entry, the expected sequence number, and the nextmbuf virtual address pointer, including: Elephant flow packets are normalized by comparing the numerical values ​​of the source IP address and the destination IP address, resulting in normalized quadtuples. A four-way parallel CRC32 engine is used to perform hash calculations on the normalized quadtuples to obtain the flow table index; Based on the flow table index, the query results are obtained by sequentially querying the chip URAM level 1 flow table cache and the off-chip DDR4 level 2 complete flow table; The query results are processed using a linear probing method to handle hash collisions, resulting in the matched flow table entry, the expected sequence number, and the nextmbuf virtual address pointer.

[0012] Optionally, the process involves associating elephant stream packets with hit flow table entries to obtain associated packets, retrieving DMA descriptors from the FPGA hardware idle queue, obtaining the host physical address based on the DMA descriptors, and having the address translation module convert the host physical address into a DPDK virtual address and write it to the nextmbuf virtual address pointer to update the hit flow table entries. Based on the comparison between the packet sequence number and the expected sequence number, zero-copy DMA writing or out-of-order buffering and chained merging is performed on the associated packets based on the updated flow table entries to obtain ordered reassembled data, including: The elephant flow message is associated with the found hit flow table entries to obtain the associated message; Obtain an idle DMA descriptor from the hardware idle queue and get the host physical address corresponding to the DMA descriptor; The address translation module uses a single-level memory translation table stored in the FPGA's on-chip BRAM to translate the host physical address into a virtual address accessible by DPDK, and writes the virtual address into the nextmbuf virtual address pointer of the hit flow table entry to update the hit flow table entry. The sequence number of the associated message is compared with the expected sequence number in the updated flow table entry to obtain the order comparison result; If the order is consistent, then zero-copy DMA writing is performed on the associated message according to the updated flow table entry and an mbuf linked list is constructed; If the order is inconsistent, the associated messages are stored in a BRAM independent buffer to form an out-of-order linked list. After the sequence numbers are consecutive, the chain is merged to finally obtain ordered recombined data.

[0013] Optionally, the DPDK software selects a fast reassembly path or a slow reassembly path based on the message's custom header, performs session reassembly on the ordered reassembled data, and obtains the restored complete session message, including: The DPDK software receives the uploaded messages and the ordered reassembled data transmitted by the FPGA hardware. The uploaded messages include mouse stream messages with custom headers and unparseable messages. The DPDK software parses the custom header carried in the message to obtain the path selection result. If the path selection result is a fast reassembly path, the DPDK directly reuses the five-tuple and transport layer control flag extracted by the FPGA hardware to perform fast session reassembly on the ordered reassembled data and obtain the restored complete session message. If the path selection result is a slow reassembly path, the DPDK software performs complete protocol parsing on the ordered reassembled data and messages, extracts relevant session information, and then performs session reassembly to obtain the restored complete session messages.

[0014] Optionally, after obtaining the ordered reassembled data, the FPGA hardware synchronizes the updated flow table entries to the DPDK software through a doorbell mechanism and a shared memory circular queue, so that the DPDK software can call the synchronized flow table information during session reassembly.

[0015] The quintuple includes the source IP address, destination IP address, source port number, destination port number, and protocol type.

[0016] A terminal device includes a memory and a processor. The memory stores a computer program that can run on the processor. When the processor loads and executes the computer program, it employs a session data group message restoration method.

[0017] A computer-readable storage medium storing a computer program, wherein the computer program, when loaded and executed by a processor, employs a session data group message restoration method.

[0018] The beneficial effects of this invention are: 1. A programmable protocol parsing module performs deep packet inspection on packets, pre-extracting the 5-tuple and transport layer control flags and caching them in the PHV structure. Simultaneously, the IP fragmentation processing module performs fragmentation detection and reassembly, offloading time-consuming operations such as protocol parsing and fragmentation reassembly to FPGA hardware. This design avoids the host DPDK from repeatedly parsing a large number of packets, effectively reducing the CPU processing load and providing reliable basic data for subsequent session reassembly.

[0019] 2. The Elephant Stream Arbitration Module performs traffic statistics and flow type determination on unfragmented / reassembled packets, directly sending Mouse Streams to DPDK for processing, while Elephant Streams enter the FPGA hardware acceleration path. Combined with the Flow Table Management Module's flow direction normalization, hash index lookup, and conflict handling, hardware-level ordered reassembly of Elephant Streams is achieved, significantly improving the processing efficiency of high-volume sessions and resolving the performance bottleneck of traditional software processing of Elephant Streams.

[0020] 3. The address translation module converts the host physical address of the DMA descriptor to a DPDK virtual address and writes it to the nextmbuf virtual address pointer of the flow table entry. Combined with the out-of-order reordering module, zero-copy DMA writing or out-of-order buffering and chained merging are performed based on the updated flow table entry to generate ordered reordered data. This design eliminates the overhead of copying data between the FPGA and the host, achieving a true zero-copy data path and significantly improving the efficiency of data transmission and processing.

[0021] 4. DPDK selects either a fast or slow reassembly path based on the message's custom header: For ordered reassembled data that has been parsed by the FPGA, it directly reuses the session information extracted by the hardware to perform fast reassembly; for parsing failures or abnormal messages, it completes the full protocol parsing through the slow path. This hardware-software co-operational dual-path mechanism ensures efficient processing of normal traffic while also being compatible with special scenarios such as non-standard packaging and encrypted payloads, improving the solution's versatility and robustness. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the hardware structure of a session data group message restoration method according to the present invention; Figure 2 This is a schematic diagram of the recombination path selection branch process of the present invention; Figure 3 This is a schematic diagram of the fast path processing flow of the present invention; Figure 4 This is a flowchart of the slow path processing of the present invention. Detailed Implementation

[0023] A method for restoring session data packets is implemented collaboratively using FPGA hardware (based on a programmable smart network interface card) and host DPDK software. The FPGA hardware includes a MAC unit, a programmable protocol parsing module, an IP fragmentation processing module, an elephant stream arbitration module, a flow table management module, an out-of-order reordering module, and an address translation module. Figure 1 As shown, the present invention includes: S1. After the message is received by the MAC processing unit, it is transmitted to the programmable protocol parsing module. The parsed message, 5-tuple information and transport layer control flag are obtained through deep packet inspection. The 5-tuple information and transport layer control flag are cached in the packet header vector PHV structure to obtain cached information. The cached information is concatenated with the parsed message to obtain the concatenated message. Unparsable messages are encapsulated with a custom header and sent to the DPDK software. Specifically, the MAC unit is an Ethernet data transceiver and frame processing module in the FPGA hardware that implements the media access control function. It is used to receive the Ethernet bit stream transmitted from the physical layer and complete frame synchronization, preamble stripping, FCS verification and error frame filtering, and output error-free Ethernet frames to the programmable protocol parsing module.

[0024] Specifically, in the overall data flow processing, after network data frames enter the FPGA hardware from the physical layer, they first pass through the MAC processing unit of the FPGA hardware acceleration card, and then enter the programmable protocol parsing module for header information extraction. This module performs deep packet inspection on the packet. If the parsing logic successfully identifies the five-tuple information (source IP address, destination IP address, source port number, destination port number, and protocol type) and transport layer control flags, the parsing result is cached in the packet header vector (PHV) structure, and the data frame continues to be passed to the downstream processing unit. If the parsing process encounters non-standard encapsulation formats, encrypted payloads, or emerging protocol extensions not supported by the hardware, causing the parsing logic to be unable to extract valid control information, the system encapsulates the data frame in a custom header and sends it directly to the DPDK receive queue in the host memory through the DMA engine of the FPGA hardware acceleration card, where the software performs complete protocol parsing and subsequent processing.

[0025] Programmable protocol parser module: The software configures the parsing path through a visual interface and zero-code operation, generating a configuration file. This configuration file, using data path multiplexing, carries a special marker in the packet header. The hardware uses this marker to distinguish between normal data stream packets and configuration packets. If a configuration packet is identified, the extraction table and mask table are updated based on the packet payload. If a data packet is identified, it enters the data processing path, locates the required bit positions using the extraction table, and extracts them. After extraction, specific pattern matching is performed based on the mask table. The mask table supports configuration in three states: 0, 1, and X. Protocol parsing is completed, and the five-tuple information in the packet header is extracted as a unique identifier for the session, including the source IP address, destination IP address, source port number, destination port number, transport layer protocol type, and the offset position of the session data payload segment.

[0026] If the transport layer protocol is TCP, then the TCP state information, including FIN, RST, SYN, PSH, etc., and sequence information Seq, needs to be extracted from the TCP header fields.

[0027] If the transport layer protocol is UDP, then there is no additional information that needs to be extracted.

[0028] S2. Transmit the spliced ​​message to the IP fragmentation processing module. After fragmentation detection and reassembly processing, non-fragmented messages and reassembled messages are obtained. The process of transmitting the spliced ​​message to the IP fragmentation processing module, and obtaining non-fragmented messages and reassembled messages through fragmentation detection and reassembly, includes: The IP fragmentation processing module detects the fragmentation flag and fragment offset field in the IPv4 header or the IPv6 fragmentation extension header, and determines whether the concatenated packet is fragmented or unfragmented. If it is a fragmented packet, the hash index of the fragmented packet is calculated using the CRC32 algorithm based on the source IP address, destination IP address and fragment identifier. The reassembly status is then searched in the fragmented context buffer of the on-chip SRAM according to the hash index. Hardware-level fragmentation and reassembly of the fragmented packet is then performed according to the reassembly status to obtain a reassembled packet. If the packet is not fragmented, output the packet as a non-fragmented packet.

[0029] Specifically, for data frames that have successfully completed protocol parsing, the system immediately initiates IP fragmentation detection and reassembly processing. The fragmentation processing unit built into the FPGA detects the fragmentation flag and fragment offset field in the IPv4 header, or the existence of the IPv6 fragmentation extension header. If the current data frame is determined to be a fragmented packet, a hash index is calculated using the CRC32 algorithm based on the source address, destination address, and fragmentation identifier, and the reassembly status is searched in the fragmentation context buffer maintained in the on-chip SRAM. If the stream to which the fragment belongs has been identified as an elephant stream, hardware-level fragmentation caching and in-order reassembly are performed using the off-chip DDR as a reassembly buffer. If the data frame is determined to be a non-fragmented packet or fragmentation reassembly has been completed, the data frame enters the elephant stream identification and arbitration stage.

[0030] IP fragmentation processing module: After the packet header information is extracted by the protocol parsing module, the fragmentation processing unit first checks the More Fragments field and the Fragment Offset field in the Flags field of the IPv4 header, or checks the Fragment Header indicated by the Next Header field in the IPv6 header. If the current packet is determined to be a non-fragmented packet, it is directly passed to the downstream flow identification module; if it is determined to be a fragmented packet, the fragmentation and reassembly process is initiated.

[0031] The fragment reassembly process relies on a fragment context hash table. The system uses the same hash algorithm as the flow table management module, calculating hash values ​​based on the source IP address, destination IP address, and fragment identifier (IPv4 ID or IPv6 FragmentIdentification). The index is located in the fragment context buffer within the on-chip BRAM. This buffer uses a multi-way set-associative structure, with each way containing 16 fragment context entries. Each entry records the fragment stream's identification information (including a 5-tuple hash, IP identifier, and protocol type), a reassembly status bitmap, and a timeout counter. When a new fragment arrives, the hardware logic performs a context lookup using parallel comparison circuits. If a valid context is found, the current fragment's payload data is written to the context-associated off-chip DDR4 reassembly buffer at the offset indicated by the fragment offset, and the bitmap is updated to mark that data within that offset range has been received.

[0032] A bitmap overlay detection mechanism is used to determine the integrity of fragment reassembly. Each fragment context is equipped with a 128-byte bitmap area, with each bit corresponding to the data block reception status of a byte. When the last fragment arrives (more fragments have zero bits), the system records the end offset of that fragment as the expected total reassembly length. Subsequently, the hardware logic checks in parallel whether the bitmap covers all data blocks from zero to the total length. If the check passes, the reassembly is marked as complete, and the reassembled complete data packet (only the header of the first fragment is retained, and the fragment extension header is removed) is re-injected into the protocol parsing module for subsequent transport layer parsing, or the address of the reassembled data segment is directly passed to the flow table management module for DMA direct writing. If the reassembly times out (the default timeout window is one second, which can be dynamically adjusted through configuration messages), the hardware automatically releases the fragment context and the corresponding DDR4 buffer, and sends the received fragment sequence as an abnormal stream to the software for processing.

[0033] S3. Transmit the non-fragmented packets and reassembled packets to the Elephant Stream Arbitration Module. Based on the traffic statistics and the determination of the flow type, obtain the Elephant Stream packets and the Mouse Stream packets. Encapsulate the Mouse Stream packets with a custom header and send them to the DPDK software. Unfragmented packets and reassembled packets are transmitted to the Elephant Stream Arbitration module. After traffic statistics and flow type determination, Elephant Stream packets and Mouse Stream packets are obtained. Mouse Stream packets are encapsulated with a custom header and then sent to the DPDK software, including: The Elephant Stream Arbitration module performs traffic statistics on unfragmented packets and reassembled packets to obtain the cumulative number of bytes for the corresponding stream; The cumulative number of bytes in the stream is compared with a preset threshold to determine whether it is an elephant stream packet or a mouse stream packet. If it is a rat stream message, then the rat stream message is encapsulated with a custom header and sent to the DPDK software; If it is an elephant flow message, then output the elephant flow message directly.

[0034] Specifically, during the elephant flow arbitration phase, the system employs a lightweight flow measurement mechanism based on frequency statistics per unit time. It performs parallel cyclic redundancy check (CRC32) hash calculations on the parsed quintuples, maintains a frequency statistics table for all flow entries, and counts the cumulative number of bytes in the flow at a microsecond-level time granularity (a count of incoming frames under a unified timer, similar to the number of incoming frames per unit time). If this statistical value exceeds a preset threshold (default 1MB), or if the flow has already been marked as an elephant flow and a hardware flow table entry has been created in the previous stage, it is determined to be an elephant flow and continues to be processed using FPGA hardware resources. If a data frame is identified as a "mouse stream," the system encapsulates the parsed header information in a custom header and sends it to the DPDK software for processing via a high-priority queue. The hardware maintains only a minimal statistical state. If the statistical value is below the threshold for identifying an "elephant stream," it is marked as invalid and no further processing is performed.

[0035] Elephant Flow Arbitration Module: The process involves statistically analyzing flow information, electing an "elephant stream" (1M entries), and synchronizing it with the software-side flow table. This requires maintaining all frequency flow tables and conducting elections. The table consists of four independent dual-port BRAM instances. During the read phase, the current count value at the corresponding address of each of the four BRAMs is read simultaneously. During the add phase, the payload_len is added to each of the four count values. During the write phase, the new value is written back to the BRAM (while checking for saturation: if all 32 bits are 1, it is retained). The minimum value is selected from the four updated values ​​using a two-level comparison tree. This minimum value is then used as the estimated byte count for the flow and output to the threshold comparator.

[0036] The table entries are defined as follows: Table 1. Item Definitions

[0037] In Table 1, StateEncoding (8-bit) is the 8-bit stream state encoding. INVALID indicates an invalid state, meaning the stream entry is not occupied or has been released. MONITORING indicates a monitoring state, meaning the stream has just been established and is accumulating bytes; it has not yet been determined as an elephant stream or a mouse stream. ELEPHANT indicates an elephant stream state, meaning the accumulated byte count has exceeded a preset threshold, and it will subsequently follow the FPGA hardware acceleration path. MOUSE indicates a mouse stream state, meaning the accumulated byte count has not exceeded the threshold, and it will be directly sent to DPDK for processing. PENDING_UP indicates a waiting-to-upload state, meaning the stream is preparing to submit data to the upper layer. PENDING_DOWN indicates a waiting-to-download state, meaning the stream is waiting for instructions or data from the host side.

[0038] S4. Transmit the elephant stream packet to the flow table management module. After the flow direction is normalized, a normalized quadruple is obtained. The normalized quadruple is hashed to obtain the flow table index. According to the flow table index, the chip URAM level-one flow table cache and the off-chip DDR4 level-two complete flow table are queried in sequence to obtain the query result. After the query result is hashed to resolve the collision, the hit flow table entry, the expected sequence number and the nextmbuf virtual address pointer are obtained. The elephant stream packets are transmitted to the flow table management module. After flow direction normalization, normalized quadruplets are obtained. A hash calculation is performed on the normalized quadruplets to obtain the flow table index. Based on the flow table index, the on-chip URAM level-one flow table cache and the off-chip DDR4 level-two complete flow table are queried sequentially to obtain the query results. After hash collision handling, the matched flow table entry, the expected sequence number, and the nextmbuf virtual address pointer are obtained, including: Elephant flow packets are normalized by comparing the numerical values ​​of the source IP address and the destination IP address, resulting in normalized quadtuples. A four-way parallel CRC32 engine is used to perform hash calculations on the normalized quadtuples to obtain the flow table index; Based on the flow table index, the query results are obtained by sequentially querying the chip URAM level 1 flow table cache and the off-chip DDR4 level 2 complete flow table; The query results are processed using a linear probing method to handle hash collisions, resulting in the matched flow table entry, the expected sequence number, and the nextmbuf virtual address pointer.

[0039] Specifically, for data frames identified as elephant streams, the FPGA immediately initiates a flow table lookup process. The flow table employs a two-level storage architecture: the first-level cache is built on the FPGA's on-chip URAM, with a capacity of 210MB, and uses a four-way set-associative structure to store complete control information of active elephant streams, including TCP Seq, next mbuf virtual address pointer, and connection status flags; the second-level complete table is built on off-chip DDR4, with a capacity of 16GB, and uses a row-bank-column address mapping strategy to optimize access latency. The system first indexes the first-level cache using a 5-tuple hash value. If the tag matches and the valid bit is set, the flow table entry is returned, and the expected Seq and the current next mbuf virtual address pointer stored therein are extracted; if the first-level cache misses, an access to the second-level DDR4 memory is initiated, hash collisions are resolved using linear probing, and the complete flow table state is read.

[0040] Flow table management module: The flow table query module is configured to implement network flow classification and state tracking based on five-tuple information. This design employs a direction normalization mechanism to map bidirectional traffic to unified flow table entries. Through a parallel hash calculation engine and a two-tier storage architecture (on-chip cache + off-chip extended storage), it ensures deterministic latency and high throughput performance for flow table queries in line-rate service scenarios. The module first performs flow direction identification on the input packets, then extracts normalized four-tuples and calculates the hash index. Finally, it completes the location and maintenance of flow table entries through a collaborative query mechanism using on-chip BRAM cache and on-chip DDR memory.

[0041] The flow direction identification logic is configured to determine the packet flow direction based on a numerical comparison between the source IP address and the destination IP address: when the source IP address is less than the destination IP address (Source IP < Destination IP), it is determined as a forward flow (Forward Direction); otherwise, it is determined as a reverse flow (Reverse Direction). For the reverse flow scenario, the module executes a quadruple rearrangement logic, which swaps the positions of the extracted source IP, destination IP, source port, and destination port fields according to the field order of the forward flow, that is, takes the original destination IP as the logical source IP and the original source IP as the logical destination IP, ensuring that both the forward and reverse directions of the same bidirectional communication flow are mapped to the same flow table index space. The normalized quadruple (logical source IP, logical destination IP, logical source port, logical destination port) is used as input data for subsequent hash calculation.

[0042] Further, the hash calculation unit adopts a parallel CRC32 algorithm architecture, and is configured to simultaneously perform multi-channel CRC32 operations on the normalized quadruple to generate a flow table index value. The CRC32 polynomial adopts the IEEE 802.3 standard (0x04C11DB7), with a calculation bit width of 288 bits and a 32-bit hash value output. To reduce the probability of hash collision and improve query throughput, the module implements a four-channel parallel CRC32 calculation engine (CRC32-0 to CRC32-3), which performs variant calculations on the quadruple with different initial values (0x00000000, 0xFFFFFFFF, 0x9E3779B9, 0x5B9CD3B1) respectively, to generate four candidate index values (Index[31:0]) for generating a linear probing sequence of the primary index and the alternative index. The index value is mapped to the flow table address space after bit width truncation.

[0043] The flow table storage architecture adopts a two-level hierarchical design: the first level is an on-chip URAM high-speed cache (210Mb capacity), configured in a true dual-port mode (Port A for query, Port B for update and eviction), organized in a set-associative structure, and used to store active flow entries (Hot Entries) to achieve single-cycle query response; the second level is an on-chip DDR4 extended storage (8GB capacity, dual Rank configuration), used to store the complete flow table, which adopts Linear Probing to resolve hash collisions, and supports long-term storage and maintenance of millions of flow entries. The two levels of storage work cooperatively through the AXI4 bus interface to form a Cache-Memory hierarchical structure, and query requests that do not hit in the URAM automatically sink to the DDR for traversal search.

[0044] The DDR4 memory physical organization adopts an 8GB capacity configuration, a dual-rank architecture (2 Ranks), x8-bit wide data particles (a total of 16 DRAM chips, each with a capacity of 512MB), each rank contains 4 Bank Groups (BG0-BG3), each Bank Group contains 4 Banks (BA0-BA3), the column address width is 10 bits (CA[9:0]), the row address width is 15 bits (RA[14:0]), and the burst length BL=8. The address control signals include the chip select signal (CS#, 1 bit, distinguishing Rank 0 / 1), Bank Group address lines (BG[1:0], 2 bits), Bank address lines (BA[1:0], 2 bits), row address lines (RA[14:0], 15 bits), and column address lines (CA[9:0], 10 bits), with a total byte-level addressing width of 33 bits (addressable 8GB space).

[0045] The Xilinx MIG controller is configured for address decoding based on 8-byte alignment. The lowest 3 bits of the byte-level address (AXI_ADDR[2:0]) are ignored by the hardware, and the actual effective address is AXI_ADDR[32:3]. To maximize DDR4 bandwidth utilization and reduce bank conflicts, the MIG address mapping mode is configured in Row-Bank-Column (RBC) order, and the specific address bit arrangement is shown in Table 2. Table 2. Byte-level address AXI_ADDR[32:0] arrangement design

[0046] The linear probe conflict resolution mechanism is configured to automatically increment the index value (Index = (Index + 1) mod 2^27) and access the next entry position when the flow table entry corresponding to the primary index position is occupied and the key does not match, until a matching flow table entry (hit) or a free entry (insertion is possible if no match is found). The probe depth is limited to 16 probes (16-way probe). If no match is found after exceeding the limit, a flow table overflow interrupt is triggered, and the request is sent to the software for processing. The probe sequence is implemented through AXI burst transmission (Burst Length = 8), and a single burst can sequentially read 8 entries (512 bits × 8 = 4KB), reducing DDR row switching overhead and improving probe efficiency.

[0047] Finally, the flow table query module outputs the query results (hit / miss flag, flow table entry content, flow index address) to the subsequent processing logic. The flow table design is shown in Tables 3 and 4.

[0048] Table 3 IPv6

[0049] Table 4 IPv4

[0050] S5. Associate the elephant flow packets with the hit flow table entries to obtain associated packets. Obtain the DMA descriptor and its host physical address from the FPGA hardware idle queue. The address translation module converts the host physical address into a DPDK virtual address and writes it to the nextmbuf virtual address pointer to update the hit flow table entries. Based on the comparison result of the packet sequence number and the expected sequence number, perform zero-copy DMA writing or out-of-order buffering and chain merging on the associated packets based on the updated flow table entries to obtain ordered reassembled data. The packet sequence number is the sequence number that each processed packet carries to identify its own order during network transmission. Out-of-order reordering module: The BRAM independent buffer is physically divided into independent slots. Each slot corresponds to a block of data corresponding to a hardware flow table entry, with a fixed capacity. A single stream buffer can hold a maximum of 10 hole blocks or more small-sized packets. The BRAM adopts a true dual-port configuration, supporting simultaneous writing of newly arrived out-of-order packets and reading of historical data to be merged, ensuring that out-of-order processing does not affect the line-rate forwarding of sequential packets. Each slot uses a linked list management system, associating discretely stored packet payloads into a logical sequence through embedded linked list pointers. The linked list node structure is compact, containing payload storage address offset, data length, starting sequence number, and next node pointer. All metadata resides in the BRAM. After merging new data, it checks whether there are mergeable nodes for out-of-order packets; if so, the merge is performed.

[0051] Each flow maintains an independent linked list of out-of-order packets. The head pointer of the linked list is stored in the block_head field of the flow table entry and initialized to NULL. The linked list nodes are physically stored in the BRAM area and use a dynamic allocation strategy, with allocation and reclamation managed through a free node bitmap.

[0052] The node begins with 4 bytes storing `seq_start` (the lower 32 bits of the 64-bit extended sequence number as a relative offset, with the higher 32 bits determined by the flow table `base_seq`), followed by 12 bits storing `prev_block`, 12 bits storing `next_block` (an index pointing to the next node, 0x4FF indicating the tail node), and then a 1-byte reserved field for marking valid bits and alignment, totaling 12 bytes of metadata. The block state linked list information is used to support insertion position determination and direct DMA writes; the block state linked list is shown in Table 5.

[0053] Table 5 shows the block state linked list as follows:

[0054] Each block state linked list entry corresponds to a primary FIFO and a secondary FIFO. The primary FIFO is used to reserve DMA descriptors from rx_ring. When a DMA descriptor retrieved from the primary FIFO is used as a candidate for next_mbuf but has not yet been written, the descriptor is stored in the secondary FIFO. When subsequent data packets arrive, the descriptor is retrieved from the secondary FIFO and written, while the descriptor is retrieved from the primary FIFO as the next_mbuf field and written, and then enqueued in the secondary FIFO.

[0055] When a module receives a packet from the flow table management unit and the sequence number comparator determines that it is an ordered packet (is_in_order is valid), it immediately triggers the pass-through DMA process. The hardware first uses the corresponding secondary FIFO in the flow table entry as the destination address to initiate a PCIe DMA write request, transferring the current packet payload from the on-chip receive buffer to the mbuf node in the host memory.

[0056] After DMA is completed, the module performs a first-level queue prefetch: a new descriptor is popped from the hardware-managed Free Mbuf Queue, the physical address is converted to a virtual address by the Address Translation Unit (ATU), and written back to the next pointer field of the current mbuf, completing the linked list connection. Subsequently, the core field new_exp_seq of the flow table is updated to accumulate the current payload length, and new_next_mbuf_vaddr is updated to the virtual address of the new prefetched mbuf.

[0057] After a data write operation is completed, the module reads the block_head of the stream table entry. If the linked list is not empty, it traverses the linked list nodes, comparing the start_sn and end_sn of each node with the sequence number (seq) of the buffered out-of-order packets. If a node's sequence number is found to be exactly equal to the new expected sequence number (i.e., filling the current gap header), chain merging is immediately triggered. The module pauses new packet reception and initiates a DMA transfer for that node, appending its payload to the current stream's mbuf linked list. After the DMA is complete, a new exp_seq (the original value plus the node's payload length) is calculated, the node is released back to the free bitmap, and the next node in the linked list is recursively checked for continuity. This process continues until the linked list is empty or a discontinuous sequence number gap is encountered.

[0058] When a message is determined to be out of order (i.e., its sequence number is greater than the current exp_seq), the module initiates the BRAM caching process. First, it checks the corresponding free node bitmap. If all 16 nodes are occupied, it performs tail node eviction: discarding the node at the tail of the linked list (with the largest sequence number), releasing the data area space it occupies, and ensuring there is buffer space for new messages. The module searches for sufficient contiguous free space in the data area and writes the message payload into the BRAM. Simultaneously, it allocates a new node from the free node pool, filling it with seq_start (relative sequence number), payload_len, and data_offset. It iterates from block_head, comparing the node sequence number with the current message sequence number. If the current message sequence number is less than a node, it is inserted before it; if it is greater than all nodes, it is appended to the tail. During insertion, the next_node_idx pointer of the predecessor node is updated synchronously. After insertion, the linked list head pointer in the flow table entry is updated (if inserted at the head) or left unchanged.

[0059] Random order detection algorithm Starting from the current seq, scan the out-of-order linked list. For each candidate block node, perform interval overlap detection: if the node's end_seq equals seq, it indicates perfect contiguousness, and DMA transmission is immediately scheduled; if seq is less than start_sn and seq + payload_len is greater than start_sn, or seq is less than end_sn and seq + payload_len is greater than end_sn, it indicates partial overlap (retransmission or overlapping packets), calculate the effective data offset and length, and only transmit the uncovered portion; if the node is completely before seq, it is marked as expired data, and the node is directly reclaimed; if the node is completely within the uncovered interval of seq, a new block node is created and the link is inserted.

[0060] After each successful merge, the sequence number (seq) is updated to the new boundary, and the next node in the linked list is checked to see if it meets the new continuity condition. If a non-contiguous node is encountered during the merge process (sequence number jump), the traversal terminates, and the remaining nodes are kept in the linked list to await subsequent filling. The module returns to normal message processing status, waiting for the next trigger.

[0061] The process involves associating elephant stream packets with hit flow table entries to obtain associated packets. A DMA descriptor and its host physical address are retrieved from the FPGA hardware idle queue. The address translation module converts the host physical address to a DPDK virtual address and writes it to the nextmbuf virtual address pointer to update the hit flow table entries. Based on the comparison between the packet sequence number and the expected sequence number, zero-copy DMA writing or out-of-order buffering and chained merging is performed on the associated packets based on the updated flow table entries to obtain ordered reassembled data, including: The elephant flow message is associated with the found hit flow table entries to obtain the associated message; Obtain an idle DMA descriptor from the hardware idle queue and get the host physical address corresponding to the DMA descriptor; The address translation module uses a single-level memory translation table stored in the FPGA's on-chip BRAM to translate the host physical address into a virtual address accessible by DPDK, and writes the virtual address into the nextmbuf virtual address pointer of the hit flow table entry to update the hit flow table entry. The sequence number of the associated message is compared with the expected sequence number in the updated flow table entry to obtain the order comparison result; If the order is consistent, then zero-copy DMA writing is performed on the associated message according to the updated flow table entry and an mbuf linked list is constructed; If the order is inconsistent, the associated messages are stored in a BRAM independent buffer to form an out-of-order linked list. After the sequence numbers are consecutive, the chain is merged to finally obtain ordered recombined data.

[0062] Specifically, if the flow table lookup is successful, the FPGA immediately performs a critical zero-copy data write operation. The system retrieves a DMA descriptor from the hardware-managed free descriptor queue; this descriptor contains the host physical address (PA). The address translation unit module calculates the offset from the base address register, converting the physical address to a virtual address (VA) in the DPDK large page memory space, and writes this virtual address into the next mbuf pointer field in the extended private data area of ​​the current mbuf structure. The DMA engine directly writes the data frame payload to the host memory, simultaneously updating the expected sequence number exp_seq in the flow table to the sum of the current sequence number and the payload length, and writing the newly allocated mbuf virtual address back to the flow table as the tail address of the linked list. This constructs an mbuf linked list structure directly maintained by hardware, achieving linked zero-copy data storage in host memory.

[0063] While the hardware completes the data writing, the system uses a doorbell mechanism and a shared memory circular queue to achieve incremental synchronization of the flow table state. The FPGA side writes the updated flow table entries (including the latest sequence number confirmation, mbuf linked list state, and connection control flags) in batches to a host-readable synchronization buffer, or triggers an interrupt through the memory MMIO register to notify the DPDK polling thread to read the hardware flow table view, ensuring the consistency of the hardware and software states.

[0064] S6, DPDK selects a fast reassembly path or a slow reassembly path based on the message custom header, performs session reassembly on the ordered reassembled data, and obtains the restored complete session message.

[0065] The DPDK selects a fast reassembly path or a slow reassembly path based on the message's custom header, performs session reassembly on the ordered reassembled data, and obtains the restored complete session message, including: DPDK receives the uploaded messages and the ordered reassembled data transmitted by the FPGA. The uploaded messages include mouse stream messages with custom headers and unparseable messages. DPDK parses the custom header carried in the message to obtain the path selection result; if the path selection result is a fast reassembly path, DPDK directly reuses the five-tuple and transport layer control flag extracted by the FPGA hardware to perform fast session reassembly on the ordered reassembled data to obtain the restored complete session message. If the path selection result is a slow reassembly path, DPDK performs complete protocol parsing on the ordered reassembled data and messages, extracts relevant session information, and then performs session reassembly to obtain the restored complete session messages.

[0066] Specifically, for data frames sent to the DPDK software, the system first checks the parsing flag in the custom header. If the flag indicates that hardware parsing is invalid (e.g., encountering a non-standard protocol or fragmentation timeout), it enters the slow reassembly path. The DPDK application layer calls the protocol parsing library to perform software-level parsing of the original message, extracting the 5-tuple and transport layer control information. If the parsing flag is valid, it enters the fast reassembly path, directly extracting the 5-tuple information carried in the header, bypassing repeated parsing calculations, and locating the corresponding stream object based on the 5-tuple hash value. This stream object manages the complete data payload of the session through a continuous data block list. Each continuous data block object further implements the physical splicing of data segments through a memory buffer list (mbuf list) that extends the nextmbuf pointer. The software inserts the newly arrived data segment into the corresponding position according to the TCP sequence number or UDP fragmentation offset, completing out-of-order reassembly and data integrity verification, and finally delivering the reassembled complete session stream to the upper-layer business application.

[0067] After obtaining the ordered reassembled data, the FPGA synchronizes the updated flow table entries to the DPDK through a doorbell mechanism and a shared memory circular queue, so that the DPDK can call the synchronized flow table information during session reassembly.

[0068] Address translation module: The address translation module implements real-time mapping from DMA descriptor physical addresses to DPDK virtual addresses based on a single-level memory translation table. This design stores the complete page table in the FPGA's on-chip BRAM. Through hardware table lookup and address synthesis mechanisms, it ensures that the FPGA can directly generate software-recognizable virtual addresses when reassembling messages or maintaining the mbuf linked list. This module employs a flattened mapping architecture, capable of converting 64-bit PCIe bus addresses to 48-bit virtual addresses, meeting the deterministic latency requirements of line-speed processing for address resolution. This module is strictly designed based on a static memory allocation model, assuming that DPDK Hugepages are allocated during system startup and maintain a fixed mapping relationship during runtime, thereby simplifying the page table synchronization mechanism and ensuring timing determinism.

[0069] The 64-bit big page memory virtual address is divided into two functional fields: the high 36 bits are the relative page address, used to index 60 1GB big pages; the low 30 bits are the page offset, covering 1GB (2^36) of memory. 0 The address space of bytes.

[0070] The 60GB Hugepages memory allocated by the DPDK software layer via rte_malloc is divided into 60 consecutive 1GB large pages. The module has built-in address normalization logic, which is configured to subtract the pre-configured physical base address offset (written through MMIO registers 0x1000-0x1007, corresponding to the starting address of Hugepages in the PCIe bus address space) from the input 64-bit DMA address to generate a 36-bit relative address relative to the start of Hugepages. The high 6 bits (bits[35:30]) of the relative page address are used as the MTT table index (supporting a maximum of 64 entries, covering the 60-page requirement, with indexes 60-63 reserved for boundary checks), and the low 30 bits (bits[29:0]) are directly used as the byte offset within the page.

[0071] The MTT table is stored in a dual-port BRAM and contains 64 entries, each 64 bits wide. Its structure is divided into functional fields as shown in Table 6: Table 6 Functional Field Definitions

[0072] When the module receives the DMA descriptor address, it first performs address normalization calculation to verify whether the relative address is less than 60GB (0xF00000000). If it exceeds the range, an address out-of-bounds exception is triggered. After passing the boundary check, the high 6 bits are extracted as the BRAM read address index, and the corresponding entry is read in a single cycle. If the valid flag bit is 1 and the index value is less than 60, the module executes the address synthesis logic: it performs a bitwise OR operation (Bitwise OR, Virtual Address = Virtual_Page_Base | Page_Offset) on the 48-bit virtual page base address and the 30-bit page offset in the MTT entry to generate a complete 48-bit virtual address; if the valid flag bit is 0 or the index value is greater than or equal to 60, the module triggers an address exception interrupt, latches the current fault address to the error register (0x1010-0x1017), and reports it to the software driver.

[0073] In the DPDK mbuf structure's next pointer conversion scenario, when the FPGA completes message reassembly and needs to update the next field of the mbuf linked list, the input value is the physical address of the next mbuf (the physical form of m->next). The module automatically executes the above table lookup and reassembly process, writing the converted virtual address back to the mbuf structure. This ensures that when the software layer subsequently traverses the mbuf linked list through the m->next pointer, it can directly obtain a valid virtual address without needing to perform rte_mem_phy2virt conversion again, achieving a true zero-copy data path. The write-back operation is completed through the PCIe transaction layer, and it is recommended to use the PCIeWrite Flush mechanism or descriptor write-back strategy to ensure CPU cache consistency.

[0074] The host DPDK software is as follows: The software-side message processing module receives message data uploaded from the FPGA via the DMA channel, performs validity checks and protocol parsing status identification based on a custom header, and selects either a Fast Path or a Slow Path for differentiated processing based on the parsing results. This module adopts a hardware-software co-design architecture, avoiding redundant calculations by reusing FPGA hardware preprocessing results (five-tuple extraction, hash calculation, and sequence number parsing), thereby improving CPU cache hit rate and processing throughput.

[0075] The software first detects the custom header appended to the leading area of ​​the message buffer. This header is automatically appended to the front of the original message by the FPGA during DMA write operations. The custom header structure is divided into the following functional fields: The Type (custom header type) field is defined as follows: 0x01 = PARSE_FAIL / / Protocol parsing failed (unable to extract quintuples or Seq) 0x02 = MOUSE_FLOW / / Mouse flow (flow below threshold) 0x03 = FRAGMENT_TIMEOUT / / Fragment reassembly timeout 0x04 = FT_MISS / / Flow table miss (hardware flow table is full or abnormal) 0x05 = EXCEPTION / / Hardware processing error (DDR error, out-of-order limit violation, etc.) 0x06 = ELEPHANT_SYNC / / Elephant stream state synchronization (not data packets, only state updates) 0x07 = CONFIG_PKT / / Configuration message (reverse, sent from software to hardware) 0xFF = RAW_DUMP / / Direct transmission of raw packets (Debug mode) The parsing flags in the packet_hdr (custom header) are checked. If the FPGA indicates that the packet has been fully parsed (five-tuple extraction, checksum, and verification), the software skips repeated parsing and enters the fast reassembly path, directly extracting header information to enter the flow table lookup stage. If the FPGA indicates that parsing failed (non-standard packaging, encrypted payload, emerging protocol extensions), the software enters the slow reassembly path and enables full protocol stack parsing.

[0076] First, the message enqueue processing function is executed, receiving the message object and queue identifier (Queue ID). The function extracts the hardware metadata header appended to the message front and locates the starting address of the data payload by skipping the metadata area using a pointer offset. Then, the queue statistics counters are updated: the queue message count and queue byte count are incremented. Next, the parsing status determination logic is executed. If the parsing status flag in the metadata is equal to "parsing complete," the fast path processing function is called; otherwise, the slow path processing function is called, such as... Figure 2 As shown.

[0077] The fast path processing function performs flow state maintenance and out-of-order reordering based on hardware pre-extracted information. First, a 5-tuple object is constructed, which can be directly extracted from the lightweight packet header (source IP, destination IP, source port, destination port, protocol number). Then, the hardware-provided flow hash feature is used as an index to perform a software flow table lookup operation.

[0078] If the flow table entry does not exist, it indicates that the connection is the first packet. The function creates a new flow table entry, initializes the five-tuple information, hash value, queue ID binding, and initializes the sequence number baseline and expected sequence number based on the TCP sequence number in the metadata.

[0079] The flow direction determination logic is then executed. By comparing the hardware direction flags, it is determined whether the packet belongs to a forward or reverse flow, and mapped to the forward or reverse flow role object in the flow table entry.

[0080] The function handles TCP control flags. If the TCP flags in the metadata include the SYN flag, it performs connection establishment processing (updating the initial sequence number, window scaling factor, maximum segment length, and other states of the role object), releases the packet buffer, and returns. If it includes the FIN or RST flag, it marks the connection as terminated, sets the aging timeout for the flow table entry, and prepares to enter the connection closing sequence.

[0081] For data packets, out-of-order detection and reassembly logic based on sequence numbers is executed. This logic extracts the current sequence number (Sequence Number) and payload length (Payload Length), and calculates the end sequence number (End Sequence Number = Current Sequence Number + Payload Length). First, it detects 32-bit sequence number spatial wrapping by comparing the current sequence number with the last received sequence number stored in the role object. If wrapping is detected (the current sequence number is significantly smaller than the last sequence number, and the difference is greater than 2^31), the sequence number base (Sequence NumberBase) is adjusted, expanding the current and end sequence numbers into 64-bit virtual sequence numbers to avoid comparison ambiguity.

[0082] Update the last received sequence number field of the role object to the end sequence number. Then execute the reassembly logic, inserting the message into the ordered data block linked list Block List. The Block node is defined as follows: struct block { uint8_t payload_ptr; / / Payload data pointer, pointing to the DPDK mbuf data segment uint32_t payload_len; / / Length of this payload segment (bytes) uint64_t start_seq; / / 64-bit starting sequence number (after virtual expansion) uint64_t end_seq; / / 64-bit end sequence number struct mid_node prev; / / Linked list pointer, pointing to the next out-of-order data block or NULL. struct mid_node next; / / Linked list pointer, pointing to the next out-of-order data block or NULL. uint16_t mbuf_ref_cnt; / / mbuf reference counting, managing memory release uint8_tflags; / / Status flags (e.g., pushed, partially overlapped, etc.) }; If the current sequence number is equal to the expected sequence number, it means that the sequence has arrived. Append the data block to the end of the linked list, update the expected sequence number to the end sequence number, and attempt to push continuous data to the application layer (attempt to push continuous data function). If the current sequence number is greater than the expected sequence number, it indicates that the sequence number has arrived out of order. A sequence number hole (Hole) is generated, a new data block (Block) structure is created and inserted into the appropriate position in the linked list. The hole range (Hole Range) is recorded, and the hole counter is incremented. If the current sequence number is less than the expected sequence number, it indicates that the message is being retransmitted. Retransmission data processing is then performed, and partial overlap removal and merging are carried out.

[0083] After data concatenation, the function checks the push conditions. If the TCP flag contains the PSH (Push) flag, or the receive buffer is full, a data push operation is triggered, delivering the reassembled continuous data to the application layer protocol processor. The fast path processing flow is as follows: Figure 3 As shown.

[0084] Slow path handling handles exception messages or complex protocol encapsulations that fail to be resolved by hardware. Multi-branch protocol parsing is performed based on the Ethernet type field (EtherType). If it is IPv4 (0x0800), parse the IPv4 header and check the Fragmentation Flags. If fragmentation exists, add it to the IP Fragment Reassembly Queue, and extract the transport layer header after fragmentation is completed; if there is no fragmentation, directly parse the TCP / UDP header. If it is IPv6 (0x86DD), parse the IPv6 header, traverse the Extension Header Chain, and locate the transport layer header; If it is a VLAN (0x8100 or 0x88A8), perform VLAN tag stripping and recursively call the parsing function to process the inner Ethernet type.

[0085] After extracting the complete quintuple and transport layer information, a pseudo-metadata object is constructed. The CRC32 hash value on the software side is calculated (using the same polynomial and seed as the hardware). Fields such as TCP sequence number, flags, and payload length are filled in. Finally, the fast path processing function is called to enter a unified processing flow, ensuring consistency in subsequent flow state machine processing logic regardless of whether hardware or software parsing is used. The fast path processing flow is as follows: Figure 4 As shown.

[0086] The empty data block management logic maintains the continuity of data blocks in the ordered linked list. First, it traverses the linked list of data blocks of the role object and checks whether the starting sequence number of each data block is less than or equal to the push sequence number. If the starting sequence number of the data block is less than the push sequence number, it means that some data has been pushed. Calculate the pushed offset PushedOffset = Push Sequence Number - Start Sequence Number, adjust the data pointer and effective length, and push the remaining data. If the starting sequence number of the data block is equal to the push sequence number, push the complete data block directly, update the push sequence number to the ending sequence number of the data block, and release the data block node. Repeat the above process until a data block with discontinuous sequence numbers is encountered.

[0087] If the pushed sequence number is less than the last received sequence number, it indicates that there is a gap to be filled. Record the gap range from the pushed sequence number to the last received sequence number and wait for subsequent messages to fill it.

[0088] This application also discloses a terminal device, including a memory and a processor. The memory stores a computer program that can run on the processor. When the processor loads and executes the computer program, it uses a session data group message restoration method.

[0089] The terminal device can be a computer device such as a desktop computer, a laptop computer, or a cloud server. The terminal device includes, but is not limited to, a processor and a memory. For example, the terminal device may also include input / output devices, network access devices, and buses.

[0090] The processor can be a central processing unit (CPU). Of course, depending on the actual use, it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc., and this application does not limit it.

[0091] The memory can be an internal storage unit of the terminal device, such as a hard disk or RAM of the terminal device, or an external storage device of the terminal device, such as a plug-in hard disk, smart memory card (SMC), secure digital card (SD), or flash memory card (FC) equipped on the terminal device. Furthermore, the memory can be a combination of internal storage units and external storage devices of the terminal device. The memory is used to store computer programs and other programs and data required by the terminal device. The memory can also be used to temporarily store data that has been output or will be output. This application does not limit this.

[0092] In this terminal device, the session data group message restoration method in the above embodiment is stored in the memory of the terminal device and loaded and executed on the processor of the terminal device for convenient use.

[0093] This application also discloses a computer-readable storage medium, which stores a computer program, wherein when the computer program is executed by a processor, the session data group message restoration method described in the above embodiments is used.

[0094] The computer program can be stored in a computer-readable medium. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or certain middleware. The computer-readable medium includes any entity or device capable of carrying computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the computer-readable medium includes, but is not limited to, the above-mentioned components.

[0095] The session data group message restoration method described in the above embodiments is stored in the computer-readable storage medium and loaded and executed on the processor to facilitate the storage and application of the above method.

[0096] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of protection of this application is limited to these examples; within the framework of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of one or more embodiments of this application as described above, which are not provided in detail for the sake of brevity.

[0097] One or more embodiments in this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of this application. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments in this application should be included within the protection scope of this application.

Claims

1. A method for restoring session data group messages, characterized in that, This system is implemented using FPGA hardware based on a programmable smart network interface card (NIC) and host DPDK software. The FPGA hardware includes a MAC unit, a programmable protocol parsing module, an IP fragmentation processing module, an elephant stream arbitration module, a flow table management module, an out-of-order reordering module, and an address translation module. After the message is received by the MAC processing unit, it is transmitted to the programmable protocol parsing module. The parsed message, 5-tuple information and transport layer control flag are obtained through deep packet inspection. The 5-tuple information and transport layer control flag are cached in the packet header vector PHV structure to obtain cached information. The cached information is concatenated with the parsed message to obtain the concatenated message. Unparsable messages are encapsulated with a custom header and sent to the DPDK software. The spliced ​​message is transmitted to the IP fragmentation processing module, where fragmentation detection and reassembly processing are performed to obtain non-fragmented messages and reassembled messages. The unfragmented packets and reassembled packets are transmitted to the Elephant Stream Arbitration Module. Based on the traffic statistics and the determination of the flow type, Elephant Stream packets and Mouse Stream packets are obtained. The Mouse Stream packets are encapsulated with a custom header and then sent to the DPDK software. The elephant stream packet is transmitted to the flow table management module. After the flow direction is normalized, a normalized quad is obtained. The normalized quad is hashed to obtain the flow table index. Based on the flow table index, the chip URAM level 1 flow table cache and the off-chip DDR4 level 2 complete flow table are queried in sequence to obtain the query result. After the query result is hashed to resolve the collision, the hit flow table entry, the expected sequence number and the nextmbuf virtual address pointer are obtained. The elephant stream packets are associated with the hit flow table entries to obtain associated packets. A DMA descriptor is obtained from the FPGA hardware idle queue. The host physical address is obtained based on the DMA descriptor. The address translation module converts the host physical address into a DPDK virtual address and writes it to the nextmbuf virtual address pointer to update the hit flow table entries. Based on the comparison result of the packet sequence number and the expected sequence number, zero-copy DMA writing or out-of-order buffering and chain merging is performed on the associated packets based on the updated flow table entries to obtain ordered reassembled data. The packet sequence number is the sequence number that each processed packet carries to identify its own order during network transmission. The DPDK software selects a fast reassembly path or a slow reassembly path based on the message's custom header, performs session reassembly on the ordered reassembled data, and obtains the restored complete session message.

2. The session data group message restoration method according to claim 1, characterized in that, The process of transmitting the spliced ​​message to the IP fragmentation processing module, and obtaining non-fragmented messages and reassembled messages through fragmentation detection and reassembly, includes: The IP fragmentation processing module detects the fragmentation flag and fragment offset field in the IPv4 header or the IPv6 fragmentation extension header, and determines whether the concatenated packet is fragmented or unfragmented. If it is a fragmented packet, the hash index of the fragmented packet is calculated using the CRC32 algorithm based on the source IP address, destination IP address and fragment identifier. The reassembly status is then searched in the fragmented context buffer of the on-chip SRAM according to the hash index. Hardware-level fragmentation and reassembly of the fragmented packet is then performed according to the reassembly status to obtain a reassembled packet. If the packet is not fragmented, output the packet directly.

3. The session data group message restoration method according to claim 1, characterized in that, Unfragmented packets and reassembled packets are transmitted to the Elephant Stream Arbitration module. After traffic statistics and flow type determination, Elephant Stream packets and Mouse Stream packets are obtained. Mouse Stream packets are encapsulated with a custom header and then sent to the DPDK software, including: The Elephant Stream Arbitration module performs traffic statistics on unfragmented packets and reassembled packets to obtain the cumulative number of bytes for the corresponding stream; The cumulative number of bytes in the stream is compared with a preset threshold to determine whether it is an elephant stream packet or a mouse stream packet; If it is a rat stream message, then the rat stream message is encapsulated with a custom header and sent to the DPDK software; If it is an elephant flow message, then output the elephant flow message directly.

4. The session data group message restoration method according to claim 1, characterized in that, The elephant stream packets are transmitted to the flow table management module. After flow direction normalization, normalized quadruplets are obtained. A hash calculation is performed on the normalized quadruplets to obtain the flow table index. Based on the flow table index, the on-chip URAM level-one flow table cache and the off-chip DDR4 level-two complete flow table are queried sequentially to obtain the query results. After hash collision handling, the matched flow table entry, the expected sequence number, and the nextmbuf virtual address pointer are obtained, including: Elephant flow packets are normalized by comparing the numerical values ​​of the source IP address and the destination IP address, resulting in normalized quadtuples. A four-way parallel CRC32 engine is used to perform hash calculations on the normalized quadtuples to obtain the flow table index; Based on the flow table index, the query results are obtained by sequentially querying the chip URAM level 1 flow table cache and the off-chip DDR4 level 2 complete flow table; The query results are processed using a linear probing method to handle hash collisions, resulting in the matched flow table entry, the expected sequence number, and the nextmbuf virtual address pointer.

5. The session data group message restoration method according to claim 1, characterized in that, The process involves associating elephant stream packets with hit flow table entries to obtain associated packets. A DMA descriptor is retrieved from the FPGA hardware idle queue. The host physical address is obtained based on the DMA descriptor. The address translation module converts the host physical address to a DPDK virtual address and writes it to the nextmbuf virtual address pointer to update the hit flow table entries. Based on the comparison between the packet sequence number and the expected sequence number, zero-copy DMA write or out-of-order buffering and chained merging is performed on the associated packets based on the updated flow table entries to obtain ordered reassembled data, including: The elephant flow message is associated with the found hit flow table entries to obtain the associated message; Obtain an idle DMA descriptor from the hardware idle queue and get the host physical address corresponding to the DMA descriptor; The address translation module uses a single-level memory translation table stored in the FPGA's on-chip BRAM to translate the host physical address into a virtual address accessible by DPDK, and writes the virtual address into the nextmbuf virtual address pointer of the hit flow table entry to update the hit flow table entry. The sequence number of the associated message is compared with the expected sequence number in the updated flow table entry to obtain the order comparison result; If the order is consistent, then zero-copy DMA writing is performed on the associated message according to the updated flow table entry and an mbuf linked list is constructed; If the order is inconsistent, the associated messages are stored in a BRAM independent buffer to form an out-of-order linked list. After the sequence numbers are consecutive, the chain is merged to finally obtain ordered recombined data.

6. The session data group message restoration method according to claim 1, characterized in that, The DPDK software selects a fast reassembly path or a slow reassembly path based on the message's custom header, performs session reassembly on the ordered reassembled data, and obtains the restored complete session message, including: The DPDK software receives the uploaded messages and the ordered reassembled data transmitted by the FPGA hardware. The uploaded messages include mouse stream messages with custom headers and unparseable messages. The DPDK software parses the custom header carried in the message to obtain the path selection result. If the path selection result is a fast reassembly path, the DPDK directly reuses the five-tuple and transport layer control flag extracted by the FPGA hardware to perform fast session reassembly on the ordered reassembled data and obtain the restored complete session message. If the path selection result is a slow reassembly path, the DPDK software performs complete protocol parsing on the ordered reassembled data and messages, extracts relevant session information, and then performs session reassembly to obtain the restored complete session messages.

7. The session data group message restoration method according to claim 1, characterized in that, After obtaining the ordered reassembled data, the FPGA hardware synchronizes the updated flow table entries to the DPDK software through a doorbell mechanism and a shared memory circular queue, so that the DPDK software can call the synchronized flow table information during session reassembly.

8. The session data group message restoration method according to claim 1, characterized in that, The quintuple includes the source IP address, destination IP address, source port number, destination port number, and protocol type.

9. A terminal device, comprising a memory and a processor, characterized in that, The memory stores a computer program that can run on a processor, and when the processor loads and executes the computer program, it employs the method described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is loaded and executed by the processor, it employs the method described in any one of claims 1 to 8.

Images