A method and device for implementing packet reassembly and verification in a network card chip

Abstract

The present application relates to the technical field of packet processing, in particular to a method and device for realizing packet reassembly and verification in a network card chip, comprising the following steps: extracting address identification and fragmentation information to generate flow index and register reassembly table, recording fragmentation according to offset and calculating length, determining total length of packet and updating offset record, judging reassembly completion, splicing in sequence and performing header and transport layer verification after completion, submitting host queue and clearing record after verification, in the present application, source address, destination address and fragmentation related fields are extracted and combined synchronously when receiving data frame, the overall length of packet gradually converges during the process of arriving of fragments, consistency is determined according to the number of theoretical fragments and actual registered number, reassembly completion boundary is determined in advance, waiting and repeated judgment are reduced, abnormal content is identified and intercepted before submission, normal packet directly enters receiving queue according to splicing address and length, the processing path is more concentrated, and the data delivery rhythm is more stable.

Description

Technical Field

[0001] This invention relates to the field of packet processing technology, and in particular to a method and apparatus for implementing fragmented packet reassembly and verification in a network interface card (NIC) chip. Background Technology

[0002] The field of packet processing technology involves receiving, parsing, buffering, forwarding, and verifying packet data in data exchange networks. Its core aspects include: parsing the IP datagram header, identifying the identifier field, determining fragment offsets and other fragmentation flags, constructing a 5-tuple or 4-tuple index based on the source address, destination address, protocol number, and identifier field; establishing fragment cache entries in the storage structure; sorting and concatenating fragments according to their offsets; and performing header checksum verification and length consistency checks after reassembly. This technology typically involves setting up a fragmentation reassembly table in the host operating system kernel protocol stack, using a hash table structure to store fragmentation control blocks, managing timed-out fragments using a timer mechanism, and having the network interface controller write the fragmented data to host memory via DMA, after which the kernel completes the reassembly and verification processing. Traditionally, fragmented packet reassembly and verification are implemented in the network interface card chip. The verification method refers to the fact that the reassembly and verification of IP fragmented packets are mainly completed by the host kernel protocol stack. The network card only performs MAC layer frame reception verification (CRC) and initiates DMA transfer through the PCIe bus to write each fragment into the memory buffer. The kernel searches for or creates reassembly entries in the fragment hash table based on the identifier field, fragment offset field and other fragment flags in the IP header. The fragments are inserted into the linked list or sequential buffer. After all fragments are in place, the IP header checksum calculation and total length field are checked. For the specific processing of IP header parsing, fragment identifier matching, fragment offset sorting, buffer management, timeout discarding and IP header checksum verification in the network card chip hardware logic, the traditional method usually relies on the fragment reassembly function in the kernel protocol stack to perform fragment buffer management and verification calculation according to the field rules defined in RFC791 to complete the packet splicing process.

[0003] Existing processing paths typically distribute fragments into the host-side buffer area, then the protocol processing gradually retrieves, attaches, waits, assembles, and verifies them. This process spans multiple stages, including bus transmission, memory access, table retrieval, chained organization, and timeout maintenance. The path is long, and as the number of fragments increases, address lookups, control block maintenance, timed scanning, and cache hit fluctuations amplify, easily leading to processing congestion. For example, when large file transfers are accompanied by a large number of concurrent fragments, the host needs to continuously receive discrete segments and maintain multiple incomplete records, resulting in fragmented processing resources and fluctuating application data delivery timing. Existing operational methods... The method often enters a relatively complete length verification and validation stage only after the fragments are basically all received. The error exposure point is too late, and the transmission bandwidth, memory space and scheduling times already invested in the front end are difficult to recover in time. When encountering out-of-order, missing fragments, duplicate fragments or sudden traffic, the incomplete record stay time is too long, and the buffer area and management structure are easily continuously occupied. This can increase the reception latency at best, and induce a chain reaction of fragment loss, queue backlog, and increased host load at worst. In actual deployment, there may also be a situation where business traffic and fragment maintenance traffic compete for processing resources, causing the normal message advance speed to decrease, and the overall forwarding efficiency and stability of the system are affected.

[0004] In addition, the existing solutions have the following significant drawbacks:

[0005] ● Severe waste of CPU resources: Even if the fragments are incomplete or contain errors, each fragment still needs to be uploaded to memory via interrupt / DMA and trigger the kernel protocol stack processing logic, consuming a large number of CPU cycles;

[0006] ● High kernel memory consumption: The fragmented hash table needs to allocate memory entries for each stream to be reassembled. In high-concurrency or Teardrop (a malformed packet based on UDP protocol that is implemented by constructing IP fragmented packets with abnormally overlapping offsets) scenarios, it is very easy to exhaust memory, resulting in a decrease in system performance or even crash.

[0007] ● Increased latency: Software reassembly requires waiting for all fragments to arrive and involves multiple memory copies and locking operations, increasing end-to-end latency;

[0008] ● Inability to filter invalid traffic in advance: Maliciously constructed fragments (such as overlapping, excessively long, and forged IDs) will continuously occupy system resources, creating potential security risks. Summary of the Invention

[0009] The purpose of this invention is to overcome the shortcomings of the existing technology and to propose a method for implementing fragmented packet reassembly and verification in a network interface card (NIC) chip.

[0010] To achieve the above objectives, the present invention adopts the following technical solution: a method for implementing fragmented packet reassembly and verification in a network interface card (NIC) chip, comprising the following steps:

[0011] S1: The network interface card chip receiving and control unit receives data frames and sends them to the Internet Protocol header parsing unit. It extracts the source address field, destination address field, identifier field, protocol field, fragment offset field, and fragment flag field. It combines the source address field, destination address field, and identifier field to generate a flow identifier index and writes it to the fragment reassembly table storage area. It registers the fragment position according to the fragment offset field and establishes a fragment reassembly table entry.

[0012] S2: Read the fragment offset field and fragment flag field of the fragment reassembly table entry record, calculate the fragment data length by combining the total length field and the header length field, calculate the overall message length when the fragment flag field is in the end state and write it into the total length field of the fragment reassembly table entry, update the maximum offset record when the fragment flag field is in the unend state, and generate the message total length registration value.

[0013] S3: Based on the total message length registration value, read the total length field of the fragment reassembly table entry, calculate the theoretical number of fragments, register the storage area status and count the number of registered fragments, compare the number of registered fragments with the theoretical number of fragments, and generate a reassembly completion flag.

[0014] S4: When the reassembly completion flag is set, call the fragment reassembly buffer to register the fragment address, perform data splicing according to the fragment offset field, calculate the header check field check value and calculate the transport layer check field and pseudo header information check value, and generate message check result;

[0015] S5: Read the message verification result. If the verification result passes, call the direct memory access control unit to submit the spliced ​​message address and total length field length to the host receiving queue. At the same time, clear the record status of the fragment reassembly table storage area and reset the total length field to obtain the message submission record.

[0016] As a further aspect of the present invention, the fragment reassembly entry includes a flow identifier index, a fragment location index, and an entry status code; the total message length registration value includes an end fragment length parameter, a maximum offset parameter, and a total message length parameter; the reassembly completion flag includes a consistency determination bit, a fragment completeness flag, and a completion trigger flag; the message verification result includes a header verification conclusion, a transport layer verification conclusion, and a pseudo header verification conclusion; the message submission record includes a submission queue identifier, a message address description, and a length receipt identifier.

[0017] As a further aspect of the present invention, the step of obtaining S1 is as follows:

[0018] S101: The network interface card chip receiving control unit receives data frames and sends them to the Internet Protocol header parsing unit. It detects the Internet Protocol header structure and performs bit segment splitting processing on the source address field, destination address field, identifier field, protocol field, fragment offset field, and fragmentation flag field. According to the Internet Protocol header field length configuration table, it performs boundary positioning calculation on the field bit sequence to form a set of field bit sequences and performs field serialization encoding processing to obtain the protocol header field sequence matrix.

[0019] S102: Based on the protocol header field sequence matrix, call the source address field, destination address field, and identifier field bit sequence to perform field concatenation processing, calculate the check value of the concatenation result and establish a field combination index structure, perform address identifier rearrangement encoding processing according to the field combination index structure, and generate a stream identifier index;

[0020] S103: Calculate the offset value by calling the fragment offset field bit sequence and the fragment flag field bit sequence according to the flow identifier index, and perform fragment sequence number judgment based on the offset value and flag bit status. Register the position sequence of the fragment offset value and establish a table entry structure mapping with the flow identifier index to form a fragment position registration structure and generate a fragment reassembly table entry.

[0021] As a further aspect of the present invention, the step of obtaining S2 is as follows:

[0022] S201: Based on the fragmentation reassembly table entry, read the fragmentation offset field and fragmentation flag field, detect the fragmentation offset field and perform offset value parsing calculation, perform status determination processing on the fragmentation flag field, establish a fragmentation position identifier sequence according to the offset value and flag field status, perform sequential encoding processing on the fragmentation position identifier and form a unified record structure to obtain the fragmentation position sequence structure.

[0023] S202: According to the fragmented position sequence structure, the total length field and the header length field are called to perform field value reading processing, the total length field and the header length field are calculated to form the fragmented data area length value, and the fragmented position sequence structure and the data area length value are associated and registered. The fragmented data length is sorted and a length registration structure is established to generate the fragmented data length sequence.

[0024] S203: Based on the fragmented data length sequence, detect the status of the fragmentation flag field, perform length summary calculation on the fragmented data length sequence and register the result in the total length field of the table entry. When the flag field is in an unfinished state, perform maximum offset value identification on the fragmented data length sequence and update the maximum offset record of the table entry. Perform unified registration processing on the table entry length record structure and generate the total length registration value of the message.

[0025] As a further aspect of the present invention, the step of obtaining S3 is as follows:

[0026] S301: Read the total length field in the table entry according to the total message length registration value, detect the record value of the total length field and perform fragmentation capacity benchmark calculation, calculate the theoretical number of fragments according to the total message length registration value and the fragmentation capacity benchmark, perform sequential numbering registration on the theoretical number of fragments and form a unified numbering structure, establish a fragmentation number record structure, and obtain the theoretical fragmentation number sequence.

[0027] S302: Based on the theoretical sharding quantity sequence, read the sharding registration status in the sharding reorganization table storage area, detect the sharding registration status field and extract the status identifier, perform statistical calculations on the sharding registration status field and form a registered quantity record, perform corresponding registration processing with the statistical results and the theoretical sharding number structure, establish a sharding registration quantity record structure, and generate a registered sharding quantity value.

[0028] S303: Perform a consistency determination based on the theoretical shard quantity sequence and the registered shard quantity value, perform a corresponding comparison process on the theoretical shard quantity sequence record value and the registered shard quantity value, and when the determination result is consistent, perform a status setting process on the reorganization completion flag field in the table entry, register the status identifier, and generate a reorganization completion flag bit.

[0029] As a further aspect of the present invention, the step of obtaining S4 is as follows:

[0030] S401: When the reassembly completion flag is set, call the fragment reassembly buffer to register fragment addresses, monitor the fragment address records in the buffer and extract the corresponding fragment offset fields, perform order determination on the fragment offset fields and establish fragment address arrangement relationships, and perform number registration processing on the fragment addresses according to the offset field order to form a unified arrangement structure and obtain a fragment address sequence table.

[0031] S402: Based on the fragment address sequence table, call the fragment address record in the fragment reassembly buffer, read the fragment data according to the fragment offset order and perform data splicing processing, extract the header field of the spliced ​​message, calculate the check value of the header check field, establish a corresponding registration structure between the check record and the spliced ​​message, and generate the header check record value.

[0032] S403: Extract the transport layer verification field of the concatenated message based on the header verification record value and detect the pseudo header information. Perform verification value calculation on the transport layer verification field in combination with the pseudo header information. Write the verification record into the network card verification status register unit and complete the status registration process to generate the message verification result.

[0033] As a further aspect of the present invention, the step of obtaining S5 is as follows:

[0034] S501: Read the contents of the network card verification status register unit according to the message verification result, detect the status field of the register unit and extract the verification status identifier, perform a pass condition judgment on the verification status identifier, and perform corresponding matching registration with the concatenated message address record to form a correspondence structure between address record and verification status, and perform sequential registration processing on the correspondence structure to obtain the verification status address table.

[0035] S502: Based on the verification status address table, call the direct memory access control unit, retrieve the spliced ​​message address record and read the total length field in the table entry, perform corresponding matching registration on the spliced ​​message address and total length field records, submit the matching record to the host receiving queue registration area, perform sequential registration processing on the submitted record, and establish a message queue submission record;

[0036] S503: Based on the message queue submission record, call the corresponding table entry record in the fragmentation and reassembly table storage area, detect the table entry status field and perform status clearing processing, perform field reset registration on the total length field in the table entry, perform association registration processing on the reset record and the message queue submission record, perform unified recording on the associated record structure, and generate a message submission record.

[0037] An apparatus for implementing fragmented packet reassembly and verification in a network interface card (NIC) chip, comprising:

[0038] The data frame parsing module receives data frames from the network interface card chip's receiving and control unit and sends them to the Internet Protocol header parsing unit. It extracts the source address field, destination address field, identifier field, protocol field, fragment offset field, and fragment flag field. Based on the source address field, destination address field, and identifier field, it forms a flow identifier index and writes it to the fragment reassembly table storage area. At the same time, based on the fragment offset field, it registers the fragment position information in the table entry and generates a fragment reassembly table entry.

[0039] The fragment length registration module reads the fragment offset field and fragment flag field based on the fragment reassembly table entry, calculates the fragment data length by combining the total length field and header length field, calculates the overall message length when the fragment flag field is detected as the end state, and registers it in the total length field of the table entry. When the fragment flag field is detected as the incomplete state, the maximum offset record in the table entry is updated to form complete message length registration content and generate the message total length registration value.

[0040] The reassembly determination module reads the total length field in the table entry based on the total length registration value of the message and calculates the theoretical number of fragments. At the same time, it reads the fragment registration status in the fragment reassembly table storage area and counts the number of registered fragments. It then determines the consistency between the number of registered fragments and the theoretical number of fragments. If they are consistent, it sets the reassembly completion flag field and generates the reassembly completion flag bit.

[0041] When the message verification module detects that the reassembly completion flag is set, it calls the fragment reassembly buffer to register the fragment address, completes data splicing according to the fragment offset field order, then performs check value calculation on the header check field, and performs check value calculation on the transport layer check field in combination with the pseudo header information, writes the check calculation result into the network card check status register unit, and generates the message verification result.

[0042] The message submission module reads the contents of the network card verification status register unit according to the message verification result. If the verification result passes, it calls the direct memory access control unit to submit the spliced ​​message address and the length corresponding to the total length field to the host receiving queue. At the same time, it performs status clearing and length field reset on the corresponding table entries in the fragment reassembly table storage area to obtain the message submission record.

[0043] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0044] In this invention, the source address, destination address, and fragmentation-related fields are extracted and combined synchronously when receiving data frames. The overall length of the message gradually converges as fragments arrive. Then, consistency is determined based on the theoretical number of fragments and the actual number of registered fragments. The reassembly completion boundary is determined in advance, reducing waiting and repeated judgments. Abnormal content is identified and intercepted before submission. Normal messages directly enter the receiving queue based on the spliced ​​address and length. The processing path is more centralized, and the data delivery cycle is more stable.

[0045] Specifically, the present invention has the following beneficial effects:

[0046] ● CPU savings of over 80%: Invalid fragments are filtered at the hardware level, without triggering interrupts or kernel processing; actual tests show that CPU utilization drops from 91% to 10% under a 10Gbps fragmented stream compared to traditional software solutions.

[0047] ● Memory usage is close to zero: the fragmented cache is located in the SRAM inside the network card chip and does not occupy the host memory; the kernel memory usage is reduced from 1.2GB in the traditional solution to less than 10MB (driver structure only).

[0048] ● Throughput increased by 3-4 times: Eliminates software reassembly bottleneck, and in actual tests, the fragmented throughput under a 10Gbps link increased from 3.1Gbps to 9.6Gbps.

[0049] ● Enhanced security: Through hardware-level overlap detection, excessively long detection, timeout cleanup, and a mechanism to prevent uploads after verification failure, it naturally resists fragment flood attacks (such as Teardrop and Ping of Death variants), preventing malicious fragments from entering the host memory.

[0050] ● Strong compatibility: It is completely transparent to upper-layer protocols and applications, requiring no modification to the existing network stack and no change to the socket API for the driver.

[0051] ● Efficient resource reclamation: Timeout timers and proactive eviction policies (LRU) ensure that on-chip caches are not occupied by invalid streams for a long time, guaranteeing stability in high-concurrency scenarios. Attached Figure Description

[0052] Figure 1 This is a flowchart of the main steps of the present invention;

[0053] Figure 2 This is a detailed schematic diagram of S1 of the present invention;

[0054] Figure 3 This is a detailed schematic diagram of S2 of the present invention;

[0055] Figure 4 This is a detailed schematic diagram of S3 of the present invention;

[0056] Figure 5 This is a detailed schematic diagram of S4 of the present invention;

[0057] Figure 6 This is a detailed schematic diagram of S5 of the present invention. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0059] In the description of this invention, it should be understood that the terms "length," "width," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, in the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0060] Please see Figure 1 A method for implementing fragmented packet reassembly and verification in a network interface card (NIC) chip includes the following steps:

[0061] S1: The network card chip receives and controls the data frames received and sends them to the Internet Protocol header parsing unit. It extracts the source address field, destination address field, identifier field, protocol field, fragment offset field, and fragment flag field. Based on the source address field, destination address field, and identifier field, it forms a flow identifier index and writes it into the fragment reassembly table storage area. At the same time, it registers the fragment position information in the table entry based on the fragment offset field and generates a fragment reassembly table entry.

[0062] S2: Based on the fragmentation reassembly table entry, read the fragmentation offset field and fragmentation flag field, combine the total length field and header length field to calculate the fragmentation data length, calculate the overall message length when the fragmentation flag field is detected as the end state and register it in the total length field of the table entry, update the maximum offset record in the table entry when the fragmentation flag field is detected as the not-end state, form the complete message length registration content, and generate the message total length registration value;

[0063] S3: Read the total length field in the table entry based on the total message length registration value and calculate the theoretical number of fragments. At the same time, read the fragment registration status in the fragment reassembly table storage area and count the number of registered fragments. Determine the consistency between the number of registered fragments and the theoretical number of fragments. If they are consistent, set the reassembly completion flag field and generate the reassembly completion flag.

[0064] S4: When the reassembly completion flag is set, call the fragment reassembly buffer to register the fragment address, complete the data splicing according to the fragment offset field order, then perform check value calculation on the header check field, and perform check value calculation on the transport layer check field in combination with the pseudo header information. Write the check calculation result into the network card check status register unit to generate the message check result.

[0065] S5: Read the contents of the network card verification status register unit according to the message verification result. If the verification result is passed, call the direct memory access control unit to submit the spliced ​​message address and the length corresponding to the total length field to the host receiving queue. At the same time, perform status clearing and length field reset on the corresponding table entries in the fragment reassembly table storage area to obtain the message submission record.

[0066] The fragmentation and reassembly table entries include the flow identifier index, fragmentation location index, and entry status code; the total message length registration values ​​include the end fragment length parameter, maximum offset parameter, and total message length parameter; the reassembly completion flags include the consistency determination bit, fragment completeness flag, and completion trigger flag; the message verification results include the header verification conclusion, transport layer verification conclusion, and pseudo-header verification conclusion; the message submission record includes the submission queue identifier, message address description, and length receipt identifier.

[0067] Please see Figure 2 The steps to obtain S1 are as follows:

[0068] S101: The network interface card chip receiving control unit receives data frames and sends them to the Internet Protocol header parsing unit. It detects the Internet Protocol header structure and performs bit segment splitting processing on the source address field, destination address field, identifier field, protocol field, fragment offset field, and fragmentation flag field. According to the Internet Protocol header field length configuration table, it performs boundary positioning calculation on the field bit sequence to form a set of field bit sequences and performs field serialization encoding processing to obtain the protocol header field sequence matrix.

[0069] When the network interface card (NIC) chip's receive control unit receives data frames from the physical link, the data frames originate from continuously written frame records in the Ethernet link interface buffer. Each data frame is stored according to the network standard structure, consisting of a header area and a data area, with the header area arranged sequentially in bytes. The receive control unit first reads the first 20 bytes of the header record at the frame start offset position and extracts the version field, header length field, service field, total length field, identifier field, fragmentation flag field, fragmentation offset field, protocol field, source address field, and destination address field in the order of the Internet Protocol header field structure. Subsequently, it performs a bit segmentation operation on the source address field, destination address field, identifier field, protocol field, fragmentation offset field, and fragmentation flag field. The segmentation operation is completed by reading the bit width record table of the fields, which is stored in the NIC's internal configuration register.

[0070] Table 1 Internet Protocol Header Field Length Configuration Table

[0071] Field Name Bit width length Byte offset position Source address field 32-bit 12 bytes Destination address field 32-bit 16 bytes Identifier field 16-bit 4 bytes Protocol fields 8-bit 9 bytes Fragment offset field 13 people 6 bytes Fragmentation flag field 3 people 6 bytes

[0072] As shown in Table 1, boundary positioning is performed on the original header binary sequence by reading the bit width information from the field length record table. For example, when the original byte sequence read from the source address field is 192.168.10.25, its binary representation is a 32-bit continuous address sequence; the destination address field is 192.168.10.40; the identifier field reads a value of 4250; the protocol field reads a value of 17; the fragment offset field reads a value of 185, corresponding to a byte offset of 185*8=1480; and the fragment flag field reads a value of 1. Next, through field serialization encoding, the above field values ​​are written into the field bit sequence set structure in a unified order. The serialization order is as follows: source address field, destination address field, identifier field, protocol field, fragment offset field, and fragment flag field are arranged consecutively. Then, each field value is converted into a fixed-length record item; for example, the source address field is written into a 32-bit sequence block, the destination address field is written into a 32-bit sequence block, and the identifier field is written into a 16-bit sequence block. After all fields are written, a sequence matrix structure of 6 field record blocks is formed. For example, when the source address field value is 192.168.10.25, the destination address field value is 192.168.10.40, the identifier field value is 4250, the protocol field value is 17, the fragment offset field value is 185, and the fragmentation flag field value is 1, the field sequence matrix records 6 field blocks in sequence, and the matrix length is recorded as 6 field sequences, thus completing the generation of the protocol header field sequence matrix.

[0073] S102: Based on the protocol header field sequence matrix, call the source address field, destination address field, and identifier field bit sequence to perform field concatenation processing, calculate the check value of the concatenation result and establish a field combination index structure, perform address identifier reordering encoding processing according to the field combination index structure, and generate a stream identifier index;

[0074] After the header field sequence matrix is ​​formed, the source address field bit sequence, destination address field bit sequence, and identifier field bit sequence are read from the matrix, and a field concatenation operation is performed. The concatenation operation is arranged in address priority order: first, the source address field bit sequence is written; then, the destination address field bit sequence is written; and finally, the identifier field bit sequence is written. The length of the concatenated field combination sequence is 80 bits. A checksum is then calculated on the concatenated sequence. The checksum calculation process is completed by byte-by-byte accumulation. First, the field combination sequence is divided into 10 byte segments, each recording a decimal value. For example, when the source address field 192.168.10.25 is converted to the byte sequence 192, 168, 10, 25, the destination address field 192.168.10.40 is converted to 192, 168, 10, 40, and the identifier field 4250 is split into two byte values ​​of 16 and 154, the above 10 byte values ​​are sequentially accumulated, resulting in a byte accumulation result of 975. The accumulated result is then truncated modulo 256 to obtain a checksum of 207. Next, a field combination index structure is built. Each index record consists of a field combination sequence value and a checksum. The combination sequence is written as the primary key to the sharded reorganized table index area, while the checksum is written to the check field record area. Then, address identifier rearrangement encoding is performed according to the field combination index structure. The encoding process rearranges the combination sequence according to the high-order byte of the address field. For example, when the source address is 192.168.10.25, the destination address is 192.168.10.40, and the identifier field is 4250, the combination encoding sequence is arranged in the order of 192, 168, 10, 25, 192, 168, 10, 40, 4250, with a checksum of 207 appended to the end of the sequence. After rearrangement, an 11-byte index encoding record is generated. This record is written to the stream identifier index area and an index number is registered. For example, the currently generated index number is 10235, corresponding to a unique stream identifier record. After completing this process, a stream identifier index structure record is obtained.

[0075] S103: Calculate the offset value by calling the fragment offset field bit sequence and the fragment flag field bit sequence according to the flow identifier index, and perform fragment sequence number judgment based on the offset value and flag status. Register the position sequence of the fragment offset value and establish a table entry structure mapping with the flow identifier index to form a fragment position registration structure and generate a fragment reassembly table entry.

[0076] After the flow identifier index is generated, the fragment offset field bit sequence and fragment flag field bit sequence are read based on the flow identifier index, and the offset value is calculated. The offset value is parsed as an integer value according to the 13-bit offset field width. For example, when the fragment offset field value is 185, this value indicates that the starting byte position of the current fragment data in the original packet is byte 1480. Then, the fragment sequence number is determined based on the fragment flag field status. A fragment flag field status record value of 1 indicates that there is still fragment data remaining. The current fragment data area length field is read to calculate the current fragment termination position. Assuming the current fragment data area length offset is 1480 bytes, the termination position is byte 2960. Then, the position sequence of the fragment offset value is registered. The registration process writes the values ​​to the fragment registration table in offset position order.

[0077] Table 2 Example of Segment Location Registration

[0078] Flow Identifier Index Number Piece offset position Segmentation termination position Segment number 10235 0 bytes 1480 bytes 1 10235 1480 bytes 2960 bytes 2

[0079] As shown in Table 2, when the first fragment offset is 0 bytes and the second fragment offset is 1480 bytes, fragment numbers 1 and 2 can be obtained by determining the order of the offset positions. A mapping relationship is then established between the fragment position records and the stream identifier index number 10235. This mapping relationship is written into the fragment reassembly table entry structure. The entry structure records the stream identifier index number, fragment offset position sequence, fragment termination position sequence, and fragment sequence number. Subsequently, a unified registration process is performed on the fragment position sequences, arranging all offset records in ascending order of value. For example, the current offset sequence records are 0 bytes, 1480 bytes, and 2960 bytes. After the arrangement is completed, a fragment position registration structure is formed, and the corresponding fragment reassembly table entry record is generated in the fragment reassembly table.

[0080] Please see Figure 3 The steps to obtain S2 are as follows:

[0081] S201: Based on the fragmentation reorganization table entry, read the fragmentation offset field and fragmentation flag field, detect the fragmentation offset field and perform offset value parsing calculation, perform status determination processing on the fragmentation flag field, establish a fragmentation position identifier sequence based on the offset value and flag field status, perform sequential encoding processing on the fragmentation position identifier and form a unified record structure to obtain the fragmentation position sequence structure.

[0082] After reading the fragment reassembly table entries, the fragment offset field and fragment flag field are extracted from the records. The offset field is recorded in the table entry as a 13-bit offset value, and parsing is performed by reading the offset value in the offset record area. The parsing process converts the offset value into a decimal byte position. For example, when three offset values ​​(converted to offset bytes) 0, 1480, and 2960 are read, they are recorded as the fragment start positions in sequence. Then, the corresponding fragment flag field status value is read. A flag field value of 0 indicates that the current fragment is the last segment of data, and a flag field value of 1 indicates that there are still fragments to be added. Assume that the current three fragment flag field values ​​are 1, 1, and 0 in sequence. Then, a fragment position identifier sequence is established based on the offset values ​​and flag field status. This sequence record entry contains the fragment start position, end position, and status identifier. Then, sequential encoding processing is performed on the fragment position identifier sequence. The encoding rule is to arrange the offset positions in ascending order and generate consecutive numbers. For example, the offset value 0 byte is recorded as sequence number 1, 1480 byte as sequence number 2, and 2960 byte as sequence number 3. The unified record structure contains the sequence number, offset position, and status field. For example, sequence number 1 corresponds to offset 0 bytes and status 1, sequence number 2 corresponds to offset 1480 bytes and status 1, and sequence number 3 corresponds to offset 2960 bytes and status 0. After completing all registrations, the fragment position sequence structure is obtained.

[0083] S202: Based on the fragment location sequence structure, call the total length field and the header length field to perform field value reading processing, perform data length calculation on the total length field and the header length field to form the fragment data area length value, and perform association registration processing on the fragment location sequence structure and the data area length value, perform sequence sorting on the fragment data length and establish a length registration structure to generate the fragment data length sequence;

[0084] After the fragment location sequence structure is established, the total length field and header length field in the Internet Protocol (IP) header are read. The total length field records the total byte length of the current fragment, and the header length field records the number of bytes in the header area. For example, when the total length field reads 1500 bytes and the header length field reads 20 bytes, the fragment data area length is 1480 bytes by subtracting the header length field from the total length field. This data area length value is then associated with the fragment location sequence structure. Specifically, the data area length corresponding to sequence number 1 is recorded as 1480 bytes, sequence number 2 as 1480 bytes, and sequence number 3 as 920 bytes. The 920 bytes of data come from the last fragment's actual read length. Then, sequence sorting is performed on all fragment data lengths. The sorting process writes the sequence lengths into the length registration structure in sequence. For example, the sequence lengths are recorded as 1480, 1480, and 920. After sorting, a fragment data length sequence is formed.

[0085] S203: Detect the status of the fragmentation flag field based on the fragmentation data length sequence, perform length summary calculation on the fragmentation data length sequence and register the result in the total length field of the table entry, when the flag field is in an unfinished state, perform maximum offset value identification on the fragmentation data length sequence and update the maximum offset record of the table entry, perform unified registration processing on the table entry length record structure, and generate the total length registration value of the message.

[0086] After reading the fragmented data length sequence, the status of the fragmentation flag field is checked. During the check, the status fields in the sequence are read sequentially. The current sequence status is 1, 1, 0. Then, a length summation calculation is performed on the fragmented data length sequence. The calculation process sequentially sums 1480 bytes, 1480 bytes, and 920 bytes to obtain a total length of 3880 bytes. This result is then recorded in the total length field of the fragmentation reassembly table entry. When the flag field status is detected as "not finished," the maximum offset value is identified in the fragmented data length sequence. The offset sequence records are 0, 1480, 2960. The maximum offset record value is 2960 bytes. The maximum offset record area of ​​the table entry is then updated to 2960 bytes. Finally, the total length of 3880 bytes and the maximum offset of 2960 bytes are written into the table entry length record structure. After registration, the total message length registration value is 3880 bytes.

[0087] Please see Figure 4 The steps to obtain S3 are as follows:

[0088] S301: Read the total length field in the table entry according to the total message length registration value, check the record value of the total length field and perform fragmentation capacity benchmark calculation, calculate the theoretical number of fragments according to the total message length registration value and the fragmentation capacity benchmark, perform sequential numbering registration on the theoretical number of fragments and form a unified numbering structure, establish a fragmentation number record structure, and obtain the theoretical fragmentation number sequence.

[0089] The system reads the total message length of 3880 bytes from the fragmentation reassembly table and the fragmentation capacity baseline value from the current network interface configuration. The fragmentation capacity baseline value is determined by the network interface's maximum transmission unit (MTBF) parameter. Reading the configuration register records reveals a MTBF of 1500 bytes and a header length of 20 bytes; therefore, a single fragment can carry 1480 bytes of data. The theoretical fragmentation count is then calculated by subtracting the fragmentation capacity from the total message length until less than 1480 bytes remain. For example, subtracting 1480 bytes twice leaves 920 bytes, thus the theoretical fragmentation count is 3. The theoretical fragmentation count is then registered with sequential numbers: sequence number 1, sequence number 2, and sequence number 3. Each sequence number corresponds to a theoretical fragmentation number record. This numbering structure is then written into the fragmentation count record area, forming a theoretical fragmentation count sequence record.

[0090] S302: Based on the theoretical sharding quantity sequence, read the sharding registration status in the sharding reorganization table storage area, detect the sharding registration status field and extract the status identifier, perform statistical calculations on the sharding registration status field and form a registered quantity record, perform corresponding registration processing with the statistical results and the theoretical sharding number structure, establish a sharding registration quantity record structure, and generate a registered sharding quantity value.

[0091] After the theoretical shard count sequence is written, the shard registration status field is read sequentially from the shard reorganization table storage area. Each shard registration status field occupies 1 byte of record space in each entry, and its value has only two states: a value of 1 indicates that the shard has been registered and written to the reorganization table entry, and a value of 0 indicates that the shard has not yet been written to the table entry. During reading, the registration status area is accessed sequentially according to the theoretical shard number sequence. For example, when the theoretical shard number sequence is 1, 2, 3, the corresponding 3 status records are read sequentially. The reading operation is performed by scanning each record, and each read status record is written to the temporary statistics area. Then, a status identifier extraction operation is performed. The extraction operation converts each status record into a statistically valid numerical sequence. For example, if the read status record value is 1, 1, 1, it is recorded as the status sequence 1, 1, 1. If the read result is 1, 0, 1, it is recorded as 1, 0, 1. After all readings are completed, statistical calculations are performed. The statistical calculation process is implemented by sequentially accumulating all status values. When the status value is 1, the number of registered fragments is increased by 1; when the status value is 0, the number remains unchanged. For example, when the status sequence is 1, 1, 1, the cumulative statistical result is 3; when the status sequence is 1, 0, 1, the cumulative statistical result is 2. The statistical result is then matched with the theoretical fragment number structure for corresponding registration. This matching registration operation is accomplished by establishing a relationship between fragment numbers and status identifiers. For example, when theoretical number 1 corresponds to status 1, theoretical number 2 corresponds to status 1, and theoretical number 3 corresponds to status 1, these three records are written to the fragment registration quantity record structure. To ensure the traceability of statistical records, the theoretical number, status value, and cumulative statistical value are recorded simultaneously in the registration structure. To illustrate the statistical process, for example, when the current total message length is 3880 bytes and the data capacity of a single fragment is 1480 bytes, the theoretical number of fragments is 3. The fragment registration status sequence 1, 1, 1 is then read, and the three status values ​​are sequentially statistically processed to obtain the registered fragment quantity value of 3. This value is written to the registered quantity record area. If the statistical result is 3 and the theoretical shard count record value is also 3, it indicates that all theoretical shards have been written to the shard reorganization table record area. The statistical result 3 is recorded as the registered shard count value and written to the shard reorganization table entry statistics field, thereby generating a registered shard count value record.

[0092] S303: Perform consistency determination based on the theoretical shard quantity sequence and the registered shard quantity value. Perform corresponding comparison processing on the theoretical shard quantity sequence record value and the registered shard quantity value. When the determination result is consistent, perform status setting processing on the reorganization completion flag field in the table entry, register the status identifier, and generate the reorganization completion flag bit.

[0093] After the registered fragment quantity value is recorded, the theoretical fragment quantity sequence value and the registered fragment quantity value are read. The theoretical fragment quantity sequence value comes from the aforementioned fragment capacity baseline calculation process. Its value is obtained by continuously subtracting the total message length of 3880 bytes from the fragment capacity of 1480 bytes, resulting in 3 theoretical fragment numbers. The registered fragment quantity value comes from the status statistics process, and its statistical result is also 3. Subsequently, a consistency determination operation is performed. The consistency determination operation is completed by comparing the theoretical fragment quantity record value and the registered fragment quantity record value item by item. During the comparison process, the theoretical fragment quantity record value of 3 is read first, and then the registered fragment quantity record value of 3 is read, and the two values ​​are directly compared. When the two values ​​are exactly the same, it means that the theoretical quantity and the registered quantity are consistent. When the comparison result is consistent, the reassembly completion flag field in the fragment reassembly table structure is set. The reassembly completion flag field occupies 1 byte of space in the fragment reassembly table, and the initial record value is 0. When the setting operation is performed, the record value of this field is updated from 0 to 1, and the setting timestamp is recorded at the same time. For example, if the current network clock records a time of 125,000 microseconds, then the status 1 and timestamp 125,000 microseconds are registered in the status record area. To further illustrate the determination process, consider this example: when the theoretical fragment count is 3, and the statistically obtained registered fragment count is also 3, a consistency determination is obtained by comparing the two values. The reassembly completion flag field is then updated to 1, and a flag record is written to the table entry status record area. If the statistical result is 2 and the theoretical count is 3, the comparison result is inconsistent; in this case, the flag field remains at 0, and no flag setting registration is performed. When the comparison result is consistent and the flag field update is completed, a reassembly completion flag record is generated in the table entry status record area. This record contains the flow identifier index number 10235, the theoretical fragment count of 3, the registered fragment count of 3, and the flag field status of 1. After registration, a reassembly completion flag structure is formed and serves as the trigger condition for subsequent fragment address read operations.

[0094] Please see Figure 5 The steps to obtain S4 are as follows:

[0095] S401: When the reassembly completion flag is set, call the fragment reassembly buffer to register fragment addresses, monitor the fragment address records in the buffer and extract the corresponding fragment offset fields, perform order determination on the fragment offset fields and establish fragment address arrangement relationships, and perform number registration processing on the fragment addresses according to the offset field order to form a unified arrangement structure and obtain the fragment address sequence table.

[0096] When the reassembly completion flag is set, fragment address records are read from the fragment reassembly buffer. Fragment address records are stored in the buffer as 32-bit address values, with each address corresponding to a segment of received fragment data. During reading, the buffer addresses are accessed sequentially according to the fragment offset records registered in the fragment reassembly table. For example, the current fragment address records might be 32000, 33480, and 34960.

[0097] Next, the fragment address records in the buffer are monitored and the corresponding fragment offset fields are extracted. The offset field is recorded in the fragment reassembly table, corresponding one-to-one with each address record. For example, address 32000 corresponds to an offset of 0 bytes, address 33480 corresponds to an offset of 1480 bytes, and address 34960 corresponds to an offset of 2960 bytes. After reading the offset records, a sequence determination operation is performed. Sequence determination is achieved by comparing all offset values, placing the smallest offset value first, and the remaining offset values ​​in ascending order. In the current example, the offset value sequence is 0, 1480, 2960, and the sorted result is 0, 1480, 2960. Then, a fragment address arrangement relationship is established. This arrangement relationship binds the address records to the sorted offset values. For example, offset 0 bytes corresponds to address 32000, offset 1480 bytes corresponds to address 33480, and offset 2960 bytes corresponds to address 34960. Next, numbering and registration are performed according to the offset field order. The numbering rule is to register numbers 1, 2, 3, etc., in the sorted order. For example, offset 0 bytes corresponds to number 1, offset 1480 bytes corresponds to number 2, and offset 2960 bytes corresponds to number 3. The number, address record, and offset value are then written into a unified arrangement structure. The unified arrangement structure records the fragment number, fragment offset position, and buffer address. After all numbers are registered, a fragment address sequence table is formed. For example, the sequence table records that number 1 corresponds to address 32000 with offset 0 bytes, number 2 corresponds to address 33480 with offset 1480 bytes, and number 3 corresponds to address 34960 with offset 2960 bytes. This sequence table is written to the fragment address sequence record area, serving as the access order basis for subsequent fragment data reading and concatenation operations.

[0098] S402: Based on the fragment address sequence table, call the fragment address record in the fragment reassembly buffer, read the fragment data according to the fragment offset order and perform data splicing processing, extract the header field of the spliced ​​message, calculate the check value of the header check field, establish a corresponding registration structure between the check record and the spliced ​​message, and generate the header check record value.

[0099] After the fragment address sequence table is established, fragment data in the fragment reassembly buffer is read sequentially according to the address records in the sequence table. The read operation is performed in numerical order. First, the buffer address 32000 corresponding to number 1 is accessed, and 1480 bytes of fragment data are read from this address; then, the address 33480 corresponding to number 2 is accessed, and 1480 bytes of fragment data are read; finally, the address 34960 corresponding to number 3 is accessed, and 920 bytes of fragment data are read. After reading, data concatenation is performed. Concatenation is achieved by writing each fragment data segment continuously into the message buffer in numerical order. First, the 1480 bytes of data read from address 32000 are written, then the 1480 bytes of data read from address 33480 are appended, and finally the 920 bytes of data read from address 34960 are appended. After concatenation, a complete message data area is formed, with a total length of 3880 bytes. Then, the header field extraction operation is performed. The header area of ​​20 bytes is read from the beginning of the concatenated message, and the header check field is extracted. The header checksum field is a 16-bit integer value. After reading, the checksum is calculated. During the calculation, the header area is divided into 10 segments of 2 bytes each. For example, the 10 segments read are 1200, 3200, 1400, 2200, 1600, 800, 600, 500, 300, and 200. These 10 segments are sequentially summed to obtain a cumulative value of 12000. Then, this value is inversely multiplied to obtain the checksum value 53535. The checksum value 53535 is then used to establish a corresponding registration structure with the concatenated message address 36000. The registration record contains the message address 36000, the header checksum value 53535, and the message length of 3880 bytes. After registration is complete, the header checksum value is generated.

[0100] S403: Extract the transport layer check field of the concatenated message based on the header check record value and detect the pseudo header information. Perform check value calculation on the transport layer check field in combination with the pseudo header information. Write the check record into the network card check status register unit and complete the status registration process to generate the message check result.

[0101] The transport layer checksum field is read from the concatenated message. This field is located in the transport layer header area, and its record value is a 16-bit integer. For example, the current read value is 26850. Then, the pseudo-header information is checked. The pseudo-header information consists of a source address field, a destination address field, a protocol field, and a data length field. Reading the concatenated message header yields a source address of 192.168.10.25, a destination address of 192.168.10.40, a protocol field of 17, and a data length of 3880 bytes. The pseudo-header information is then converted into a continuous byte sequence and combined with the transport layer data area for checksum accumulation. For example, the source address is converted to the byte sequence 192, 168, 10, 25; the destination address is converted to 192, 168, 10, 40; the protocol field of 17; and the data length of 3880 is converted to the byte sequence 15 and 40. These byte values ​​are then sequentially accumulated with the transport layer data segment record value. Assume the accumulation result is 26980. Finally, a one's complement operation is performed to obtain the checksum record value 38555. The verification record is then written to the network interface card (NIC) verification status register. The register contains a verification result field and a verification record field. The verification record value 38555 is written to the verification record field, and the verification result field is registered as pass status 1. After writing, a complete message verification result record is generated in the register. This record contains the message address 36000, header checksum 53535, transport layer checksum 38555, and verification status identifier 1. This record is written to the verification status register and serves as the status basis for subsequent message queue submission processing.

[0102] Please see Figure 6 The steps to obtain S5 are as follows:

[0103] S501: Read the contents of the network card verification status register unit according to the message verification result, detect the status field of the register unit and extract the verification status identifier, perform a pass condition judgment on the verification status identifier, and perform corresponding matching and registration with the concatenated message address record to form a correspondence structure between address record and verification status. Perform sequential registration processing on the correspondence structure to obtain the verification status address table.

[0104] When reading the network interface card (NIC) verification status register based on the message verification result, the status field record area in the register is accessed first. The register stores verification status records in a continuous address structure. Each record contains a message address record field, a header verification record field, a transport layer verification record field, and a verification status identifier field. The read operation proceeds in the order of the register record numbers. For example, if there are three records in the register, their message address records are 36000, 38000, and 40200, and their corresponding verification status identifiers are 1, 1, and 1, respectively. Next, the register status fields are checked and the verification status identifiers are extracted. During extraction, the status field values ​​are read one by one and converted into a comparable status sequence. For example, if the read result is 1, 1, 1, it is recorded as the status sequence 1, 1, 1. Next, a pass / fail condition determination operation is performed. This operation compares the status field values; when the status field value is 1, it is recorded as a pass record, and when the status field value is 0, it is recorded as a fail record. Taking the current read status sequence 1, 1, 1 as an example, the determination result is that all three records are in a pass state. The judgment result is then matched and registered with the concatenated message address record. Matching and registration are achieved by establishing an association between address records and verification status; for example, address 36000 corresponds to status 1, address 38000 corresponds to status 1, and address 40200 corresponds to status 1. To ensure a consistent record structure, the matched records are processed sequentially. Sequential registration arranges the message addresses in ascending order, for example, 36000, 38000, and 40200. The arranged records are then written into the verification status address table structure. The verification status address table contains field address records and verification status records.

[0105] Table 3 Message Verification Status Address Table

[0106] Message address record Verification status indicator 36000 1 38000 1 40200 1

[0107] As shown in Table 3, a complete address status mapping structure can be formed by reading the register unit status field and performing a matching registration operation. This structure records the check status identifier corresponding to each concatenated message address. When the status identifier is 1, the address record enters the subsequent direct memory access control unit processing flow. After completing all registrations, a check status address table is obtained.

[0108] S502: Based on the verification status address table, call the direct memory access control unit, retrieve the spliced ​​message address record and read the total length field in the table entry, perform corresponding matching registration on the spliced ​​message address and total length field records, submit the matching record to the host receiving queue registration area, perform sequential registration processing on the submitted record, and establish a message queue submission record;

[0109] After the verification status address table is established, the Direct Memory Access Control Unit (DMI) is invoked based on the address table records. During the invocation, the concatenated message address records are read sequentially according to the address order in the address table. For example, the first address in the address table is 36000, the second is 38000, and the third is 40200. Then, the total length field of the corresponding entry is read from the fragment reassembly table storage area. The total length field records the complete length of the currently concatenated message. For example, the total length field corresponding to address 36000 is 3880 bytes, the length record corresponding to address 38000 is 2960 bytes, and the length record corresponding to address 40200 is 1480 bytes. Next, the matching and registration process between the address records and the total length field records is performed. The matching operation is achieved by establishing a one-to-one correspondence between address records and length records. For example, address 36000 corresponds to a length of 3880 bytes, address 38000 corresponds to a length of 2960 bytes, and address 40200 corresponds to a length of 1480 bytes. After the matching is completed, a message submission record is generated. Next, the matching records are submitted to the host receive queue registration area. The host receive queue stores records in a first-in, first-out (FIFO) manner, and each record contains two fields: message address and message length. Assuming the current receive queue already has 12 records, newly submitted records are written sequentially to positions 13, 14, and 15. For example, record 13 has address 36000 and a length of 3880 bytes, record 14 has address 38000 and a length of 2960 bytes, and record 15 has address 40200 and a length of 1480 bytes. After the write operation is complete, sequential registration processing is performed on the submitted records. The sequential registration operation numbers the newly written records according to the order of their write time, for example, numbered 13, 14, and 15. Subsequently, a corresponding message queue submission record structure is generated in the host receive queue registration area. This structure contains the record number, message address, and message length fields. After registration is completed, a message queue submission record is generated.

[0110] S503: Based on the message queue submission record, call the corresponding table entry record in the fragmentation and reassembly table storage area, check the table entry status field and perform status clearing processing, perform field reset registration on the total length field in the table entry, perform association registration processing on the reset record and message queue submission record, perform unified recording on the associated record structure, and generate message submission record;

[0111] After the packet queue submission record is generated, the corresponding entry record in the fragment reassembly table storage area is retrieved based on the address record and flow identifier index number in the submission record. The read operation first locates the corresponding entry address using the flow identifier index number 10235, and then reads the status field inside the entry. The status field occupies 1 byte of space in the fragment reassembly table, and its initial value is set to 1 when reassembly is complete. Subsequently, a status clearing process is performed. This clearing process is implemented by updating the status field record value from 1 to 0. For example, if the current entry's status field record value is 1, then an update value of 0 is written, and an update time record is registered in the status record area. For example, if the current network time counter record value is 128500 microseconds, then the time 128500 microseconds and the status update value 0 are written to the update record area. Then, a field reset registration is performed on the total length field within the entry. The total length field needs to have its original record value cleared after packet submission. For example, if the current entry's total length field record value is 3880 bytes, this field is updated to 0 bytes through a reset operation. Subsequently, the fragment offset record area is cleared, removing all existing offset records (bytes 0, 1480, and 2960) from 0. Next, the reset records and message queue commit records are associated. This association is established by setting a correspondence between commit record numbers and entry index numbers. For example, commit record number 13 corresponds to flow identifier index number 10235, and commit record number 14 corresponds to index number 10236. After the association is complete, the associated record structure is written to the record area. Then, a unified record processing is performed on the associated record structure. The unified record structure includes the commit record number, message address record, flow identifier index number, and reset status record. For example, record item 13 corresponds to address 36000, index number 10235, and reset status 0. After all records are written, a message commit record structure is generated and written to the message commit record area as a historical commit log record.

[0112] An apparatus for implementing fragmented packet reassembly and verification in a network interface card (NIC) chip, comprising:

[0113] The data frame parsing module receives data frames from the network interface card chip's receiving and control unit and sends them to the Internet Protocol header parsing unit. It extracts the source address field, destination address field, identifier field, protocol field, fragment offset field, and fragment flag field. Based on the source address field, destination address field, and identifier field, it forms a flow identifier index and writes it to the fragment reassembly table storage area. At the same time, based on the fragment offset field, it registers the fragment position information in the table entry and generates a fragment reassembly table entry.

[0114] The fragment length registration module reads the fragment offset field and fragment flag field from the fragment reassembly table entry, calculates the fragment data length by combining the total length field and header length field, calculates the overall message length when the fragment flag field is detected as the end state, and registers it in the total length field of the table entry. When the fragment flag field is detected as the incomplete state, the maximum offset record in the table entry is updated to form complete message length registration content and generate the message total length registration value.

[0115] The reassembly determination module reads the total length field in the table entry based on the total message length registration value and calculates the theoretical number of fragments. At the same time, it reads the fragment registration status in the fragment reassembly table storage area and counts the number of registered fragments. It then performs a consistency determination between the number of registered fragments and the theoretical number of fragments. If they are consistent, it sets the reassembly completion flag field and generates a reassembly completion flag.

[0116] When the message verification module detects that the reassembly completion flag is set, it calls the fragment reassembly buffer to register the fragment address, completes data splicing according to the fragment offset field order, then performs check value calculation on the header check field, and performs check value calculation on the transport layer check field in combination with the pseudo header information. The check calculation result is written to the network card check status register unit to generate the message verification result.

[0117] The message submission module reads the contents of the network card verification status register unit according to the message verification result. If the verification result is passed, it calls the direct memory access control unit to submit the concatenated message address and the length corresponding to the total length field to the host receiving queue. At the same time, it performs status clearing and length field reset on the corresponding table entries in the fragment reassembly table storage area to obtain the message submission record.

[0118] Overall Architecture

[0119] This invention integrates a Fragment Reassembly Engine (FRE) into a SmartNIC chip that supports programmable or dedicated logic. The FRE is located after the MAC layer and before DMA upload in the received data path. Controlled by a hardware state machine, the FRE employs a three-stage pipeline architecture: the first stage handles fragment parsing and flow identification; the second stage manages on-chip buffers and determines reassembly; and the third stage performs integrity verification and selective upload. Internally, the FRE includes:

[0120] ● The fragment reassembly table storage area is located in the static random access memory (SRAM) inside the network card chip. It is used to store table entry information such as stream identifier index, fragment offset record, and timeout timer (hardware fragment cache table, HFCT).

[0121] ● The fragment reassembly buffer, also located in on-chip SRAM, is used to cache fragmented data load;

[0122] ● Timeout management unit, which maintains an independent timer for each entry;

[0123] ● Checksum offloading unit, used to calculate IP header checksum and TCP / UDP checksum.

[0124] Key technical steps detailed

[0125] ● Fragmentation identification and classification: The network card parses the received Ethernet frame and extracts the IP header; if the "MoreFragments (MF)" flag in the IP header is 1 or "Fragment Offset" ≠ 0, it is determined to be a fragmented packet; extract the triple as the flow identifier: {source IP, destination IP, Identification field}.

[0126] ● On-chip cache management: A hardware fragment cache table (HFCT) is maintained in the SRAM on the network card. Each entry contains: Flow identifier (triple); List of received fragments (recording offset, length, and payload pointers); Timeout timer (e.g., default 30 seconds); Total length (calculated based on the last fragment (fragment with MF=0), the last fragment offset, and the IP header length).

[0127] ● Fragmentation Storage and Reassembly: Upon arrival of a new fragment, the HFCT is searched based on the stream identifier. If a match is found, the payload is written to the corresponding buffer, and the fragment list is updated. If a match is missed and it is the first fragment (offset=0), a new entry is created. If it is not the first fragment and there is no corresponding entry, it is discarded directly (to avoid attacks). Reassembly is triggered when the last fragment (MF=0) is received and all offsets continuously cover [0, total length).

[0128] ● Integrity verification: After reassembly, the hardware automatically performs: IP header checksum verification; for TCP / UDP, calculate and verify the transport layer checksum (using the network card's built-in checksum offload unit); only when all checks pass, the complete packet is uploaded to the designated receive queue in the host memory via DMA; if the check fails or the packet is not received within a timeout, the corresponding buffer in HFCT is released and no data is uploaded.

[0129] ● Resource reclamation mechanism: Each HFCT entry is bound to a timeout timer, and is automatically cleaned up after the timeout; it supports proactive eviction policies (such as LRU) based on flow rate or cache pressure.

[0130] Interacting with the host

[0131] ● The network card driver does not require modification of the existing socket API;

[0132] ● The complete message is uploaded in the normal packet format, and the application is unaware of it;

[0133] ● Statistical information (such as "number of discarded fragments" and "number of successful reassemblies") can be exposed through registers for monitoring purposes.

[0134] Security protection mechanism

[0135] Before writing the fragment to the cache, FRE performs the following security checks:

[0136] ● Overlap Detection: Checks whether the offset range of the new fragment overlaps with that of already received fragments. If overlap exists (e.g., due to a Teardrop attack), the fragment is discarded and the corresponding entry is released; it is not uploaded to the host.

[0137] ● Excess Length Detection: Checks if the total length field of the fragment exceeds 65535 bytes (the maximum IPv4 packet length). If it does, it is considered a malformed packet and is discarded.

[0138] ● First piece verification: If a non-first piece is received (offset ≠ 0) but there is no corresponding entry, it will be discarded to prevent malicious pre-filling attacks.

[0139] Example: 100G smart network interface card based on programmable data path (P4 programmable or fixed-function ASIC)

[0140] 1. Hardware platform configuration

[0141] ● Network card chip model: Self-developed SmartNIC-X1 (supports PCIe 4.0 x16, with 32MB of on-chip SRAM);

[0142] ● The receiver engine includes: MAC unit, fragment reassembly engine (FRE), DMA controller, and RSS module;

[0143] ● The FRE module consists of a dedicated state machine and an SRAM cache array, supporting parallel processing of up to 8192 fragment streams.

[0144] 2. Fragmented Message Reception and Identification Process

[0145] When the network card receives an Ethernet frame:

[0146] ● The MAC unit strips the preamble and FCS and sends the IP packet into the FRE;

[0147] ● FRE parses the IPv4 header (if it is IPv6, it is directly passed through, because IPv6 prohibits intermediate fragmentation).

[0148] ● If MF=1 or Fragment Offset > 0 is detected, it is determined to be a fragment;

[0149] ● Extract the triple Key = {SrcIP: 192.168.1.10, DstIP: 10.0.0.5, ID:0x1234}.

[0150] 3. On-chip cache management operations

[0151] ● FRE uses the hash function H(Key) = (SrcIP ⊕ DstIP ⊕ ID) mod 8192 to locate HFCT entries;

[0152] ● If table entry #5678 is hit, check if the new shard offset overlaps with an existing shard (to prevent Teardrop attacks).

[0153] ● If there is no conflict, write the payload to SRAM address 0x200000 and update the fragment bitmap (e.g., bit

[185] =1 indicates that the fragment at offset 1480 has been received).

[0154] ● If it is the last fragment (fragment with MF=0), read the IP Total Length, Fragment Offset, and IP header length, calculate the original length of the original fragment before fragmentation, and record it in the table entry.

[0155] 4. Examples of security protection mechanisms

[0156] ● Overlap detection: When a fragment offset=1480 and length=1480 is received, and an existing fragment covers [0,1480) and [1480,2960), an overlap is detected, the fragment is immediately discarded and the entry is released.

[0157] ● Overlength detection: If an attacker sends an overlength packet with ID=0x1234, offset=0, and length=60000, FRE will detect that Total Length > 65535 (maximum for IPv4) and immediately discard it without creating an entry.

[0158] ● First piece verification: If a non-first piece is received (offset≠0) but there is no corresponding entry, it is discarded directly.

[0159] 5. Recombination Triggering and Verification

[0160] ● When a fragment with MF=0 and offset=1480 (IP header length 20 bytes) is received, the original_length of the packet is calculated. FRE detects that the bitmap is all 1s and covers [0, original_length);

[0161] ● Initiate reassembly: Concatenate all payloads into a contiguous buffer in offset order;

[0162] ● Invoke the built-in checksum unit:

[0163] Recalculate the IP header checksum (after setting the original checksum field to 0);

[0164] If the protocol is UDP, calculate the checksum using the pseudo header + UDP header + data;

[0165] ● All verification results are 0xFFFF → Valid.

[0166] 6. Uploading to the host and handling failures

[0167] ● When verification passes: The reassembled original_length bytes of complete IP packet are written to the DMA descriptor queue; an MSI-X interrupt is triggered (or the driver is notified via polling); the host protocol stack reads the packet from the receive queue and processes it as a normal unfragmented packet, without the application being aware of it.

[0168] ● When verification fails: Release the corresponding cache and SRAM space in HFCT, do not submit any data to the host, and do not trigger an interrupt.

[0169] ● Timeout handling: If all fragments are not collected within 30 seconds, the timeout timer expires, HFCT#5678 and the corresponding SRAM space are automatically released, and the data is not uploaded to the host.

[0170] 7. Resource recycling and disposal strategies

[0171] When the on-chip SRAM cache pressure exceeds a threshold (e.g., utilization > 90%), FRE initiates a proactive eviction policy, prioritizing the eviction of the least recently updated (LRU) entries to ensure that new streams can be processed normally. The received fragments corresponding to the evicted entries are discarded directly and not uploaded to the host.

[0172] 8. Performance Test Data

[0173] Tested in a Linux 5.15 + DPDK 22.11 environment:

[0174] index Traditional software processing Hardware processing of this invention CPU utilization (10Gbps fragmented stream) 91% 10% Effective throughput (UDP fragmentation) 3.1 Gbps 9.6 Gbps Kernel memory usage 1.2 GB <10 MB (Driver structure only) CPU usage under Teardrop attack Surges to 100% and packet loss No significant changes

[0175] 9. Alternative Implementation Plan

[0176] ● Partial offloading mode: Hardware reconfiguration is enabled only for specific protocols (such as UDP over IPv4), while the rest still use software;

[0177] ● Configurable strategy: Enable or disable this function via register switches, compatible with older systems;

[0178] ● Multi-queue support: The reassembled message can be distributed to the receive queues of different CPU cores according to the RSS rules.

[0179] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for implementing fragmented packet reassembly and verification in a network interface card (NIC) chip, characterized in that, Includes the following steps: S1: The network interface card chip receiving and control unit receives data frames and sends them to the Internet Protocol header parsing unit. It extracts the source address field, destination address field, identifier field, protocol field, fragment offset field, and fragment flag field. It combines the source address field, destination address field, and identifier field to generate a flow identifier index and writes it to the fragment reassembly table storage area. It registers the fragment position according to the fragment offset field and establishes a fragment reassembly table entry. S2: Read the fragment offset field and fragment flag field of the fragment reassembly table entry record, calculate the fragment data length by combining the total length field and the header length field, calculate the overall message length when the fragment flag field is in the end state and write it into the total length field of the fragment reassembly table entry, update the maximum offset record when the fragment flag field is in the unend state, and generate the message total length registration value. S3: Based on the total message length registration value, read the total length field of the fragment reassembly table entry, calculate the theoretical number of fragments, register the storage area status and count the number of registered fragments, compare the number of registered fragments with the theoretical number of fragments, and generate a reassembly completion flag. S4: When the reassembly completion flag is set, call the fragment reassembly buffer to register the fragment address, perform data splicing according to the fragment offset field, calculate the header check field check value and calculate the transport layer check field and pseudo header information check value, and generate message check result; S5: Read the message verification result. If the verification result passes, call the direct memory access control unit to submit the spliced ​​message address and total length field length to the host receiving queue. At the same time, clear the record status of the fragment reassembly table storage area and reset the total length field to obtain the message submission record.

2. The method for implementing fragmented packet reassembly and verification in a network interface card (NIC) chip according to claim 1, characterized in that, The fragment reassembly table entry includes a flow identifier index, a fragment location index, and an entry status code; the total message length registration value includes an end fragment length parameter, a maximum offset parameter, and a total message length parameter; the reassembly completion flag includes a consistency determination bit, a fragment completeness flag, and a completion trigger flag; the message verification result includes a header verification conclusion, a transport layer verification conclusion, and a pseudo header verification conclusion; the message submission record includes a submission queue identifier, a message address description, and a length receipt identifier.

3. The method for implementing fragmented packet reassembly and verification in a network interface card (NIC) chip according to claim 2, characterized in that, The steps to obtain S1 are as follows: S101: The network interface card chip receiving control unit receives data frames and sends them to the Internet Protocol header parsing unit. It detects the Internet Protocol header structure and performs bit segment splitting processing on the source address field, destination address field, identifier field, protocol field, fragment offset field, and fragmentation flag field. According to the Internet Protocol header field length configuration table, it performs boundary positioning calculation on the field bit sequence to form a set of field bit sequences and performs field serialization encoding processing to obtain the protocol header field sequence matrix. S102: Based on the protocol header field sequence matrix, call the source address field, destination address field, and identifier field bit sequence to perform field concatenation processing, calculate the check value of the concatenation result and establish a field combination index structure, perform address identifier rearrangement encoding processing according to the field combination index structure, and generate a stream identifier index; S103: Calculate the offset value by calling the fragment offset field bit sequence and the fragment flag field bit sequence according to the flow identifier index, and perform fragment sequence number judgment based on the offset value and flag bit status. Register the position sequence of the fragment offset value and establish a table entry structure mapping with the flow identifier index to form a fragment position registration structure and generate a fragment reassembly table entry.

4. The method for implementing fragmented packet reassembly and verification in a network interface card (NIC) chip according to claim 3, characterized in that, The steps to obtain S2 are as follows: S201: Based on the fragmentation reassembly table entry, read the fragmentation offset field and fragmentation flag field, detect the fragmentation offset field and perform offset value parsing calculation, perform status determination processing on the fragmentation flag field, establish a fragmentation position identifier sequence according to the offset value and flag field status, perform sequential encoding processing on the fragmentation position identifier and form a unified record structure to obtain the fragmentation position sequence structure. S202: According to the fragmented position sequence structure, the total length field and the header length field are called to perform field value reading processing, the total length field and the header length field are calculated to form the fragmented data area length value, and the fragmented position sequence structure and the data area length value are associated and registered. The fragmented data length is sorted and a length registration structure is established to generate the fragmented data length sequence. S203: Based on the fragmented data length sequence, detect the status of the fragmentation flag field, perform length summary calculation on the fragmented data length sequence and register the result in the total length field of the table entry. When the flag field is in an unfinished state, perform maximum offset value identification on the fragmented data length sequence and update the maximum offset record of the table entry. Perform unified registration processing on the table entry length record structure and generate the total length registration value of the message.

5. The method for implementing fragmented packet reassembly and verification in a network interface card (NIC) chip according to claim 4, characterized in that, The steps to obtain S3 are as follows: S301: Read the total length field in the table entry according to the total message length registration value, detect the record value of the total length field and perform fragmentation capacity benchmark calculation, calculate the theoretical number of fragments according to the total message length registration value and the fragmentation capacity benchmark, perform sequential numbering registration on the theoretical number of fragments and form a unified numbering structure, establish a fragmentation number record structure, and obtain the theoretical fragmentation number sequence. S302: Based on the theoretical sharding quantity sequence, read the sharding registration status in the sharding reorganization table storage area, detect the sharding registration status field and extract the status identifier, perform statistical calculations on the sharding registration status field and form a registered quantity record, perform corresponding registration processing with the statistical results and the theoretical sharding number structure, establish a sharding registration quantity record structure, and generate a registered sharding quantity value. S303: Perform a consistency determination based on the theoretical shard quantity sequence and the registered shard quantity value, perform a corresponding comparison process on the theoretical shard quantity sequence record value and the registered shard quantity value, and when the determination result is consistent, perform a status setting process on the reorganization completion flag field in the table entry, register the status identifier, and generate a reorganization completion flag bit.

6. The method for implementing fragmented packet reassembly and verification in a network interface card (NIC) chip according to claim 5, characterized in that, The steps to obtain S4 are as follows: S401: When the reassembly completion flag is set, call the fragment reassembly buffer to register fragment addresses, monitor the fragment address records in the buffer and extract the corresponding fragment offset fields, perform order determination on the fragment offset fields and establish fragment address arrangement relationships, and perform number registration processing on the fragment addresses according to the offset field order to form a unified arrangement structure and obtain a fragment address sequence table. S402: Based on the fragment address sequence table, call the fragment address record in the fragment reassembly buffer, read the fragment data according to the fragment offset order and perform data splicing processing, extract the header field of the spliced ​​message, calculate the check value of the header check field, establish a corresponding registration structure between the check record and the spliced ​​message, and generate the header check record value. S403: Extract the transport layer verification field of the concatenated message based on the header verification record value and detect the pseudo header information. Perform verification value calculation on the transport layer verification field in combination with the pseudo header information. Write the verification record into the network card verification status register unit and complete the status registration process to generate the message verification result.

7. The method for implementing fragmented packet reassembly and verification in a network interface card (NIC) chip according to claim 6, characterized in that, The steps to obtain S5 are as follows: S501: Read the contents of the network card verification status register unit according to the message verification result, detect the status field of the register unit and extract the verification status identifier, perform a pass condition judgment on the verification status identifier, and perform corresponding matching registration with the concatenated message address record to form a correspondence structure between address record and verification status, and perform sequential registration processing on the correspondence structure to obtain the verification status address table. S502: Based on the verification status address table, call the direct memory access control unit, retrieve the spliced ​​message address record and read the total length field in the table entry, perform corresponding matching registration on the spliced ​​message address and total length field records, submit the matching record to the host receiving queue registration area, perform sequential registration processing on the submitted record, and establish a message queue submission record; S503: Based on the message queue submission record, call the corresponding table entry record in the fragmentation and reassembly table storage area, detect the table entry status field and perform status clearing processing, perform field reset registration on the total length field in the table entry, perform association registration processing on the reset record and the message queue submission record, perform unified recording on the associated record structure, and generate a message submission record.

8. A device for implementing fragmented packet reassembly and verification in a network interface card (NIC) chip, characterized in that, The system is used to execute a method for implementing fragmented packet reassembly and verification in a network interface card chip as described in any one of claims 1-7, comprising: The data frame parsing module receives data frames from the network interface card chip's receiving and control unit and sends them to the Internet Protocol header parsing unit. It extracts the source address field, destination address field, identifier field, protocol field, fragment offset field, and fragment flag field. Based on the source address field, destination address field, and identifier field, it forms a flow identifier index and writes it to the fragment reassembly table storage area. At the same time, based on the fragment offset field, it registers the fragment position information in the table entry and generates a fragment reassembly table entry. The fragment length registration module reads the fragment offset field and fragment flag field based on the fragment reassembly table entry, calculates the fragment data length by combining the total length field and header length field, calculates the overall message length when the fragment flag field is detected as the end state, and registers it in the total length field of the table entry. When the fragment flag field is detected as the incomplete state, the maximum offset record in the table entry is updated to form complete message length registration content and generate the message total length registration value. The reassembly determination module reads the total length field in the table entry based on the total length registration value of the message and calculates the theoretical number of fragments. At the same time, it reads the fragment registration status in the fragment reassembly table storage area and counts the number of registered fragments. It then determines the consistency between the number of registered fragments and the theoretical number of fragments. If they are consistent, it sets the reassembly completion flag field and generates the reassembly completion flag bit. When the message verification module detects that the reassembly completion flag is set, it calls the fragment reassembly buffer to register the fragment address, completes data splicing according to the fragment offset field order, then performs check value calculation on the header check field, and performs check value calculation on the transport layer check field in combination with the pseudo header information, writes the check calculation result into the network card check status register unit, and generates the message verification result. The message submission module reads the contents of the network card verification status register unit according to the message verification result. If the verification result passes, it calls the direct memory access control unit to submit the spliced ​​message address and the length corresponding to the total length field to the host receiving queue. At the same time, it performs status clearing and length field reset on the corresponding table entries in the fragment reassembly table storage area to obtain the message submission record.

Images