Data packet processing methods, devices and equipment, media, and products

Abstract

This application discloses a method, apparatus, device, medium, and product for processing data packets. The method is applied to a network device equipped with a programmable hardware forwarding chip. The method is executed by the programmable hardware forwarding chip and includes: acquiring a first data packet received by the network device, the first data packet including a header extension option field, the header extension option field being a variable-length and non-fixed-structure option field; parsing the header extension option field based on the hardware alignment constraints of the programmable hardware forwarding chip to obtain a parsing result, the parsing result including a target option field in the header extension option field; modifying the target option field when it is determined that the target option field meets the modification conditions; and updating the first data packet based on the modified target option field to obtain a second data packet. This application can improve the processing efficiency of data packets.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a data packet processing method, a data packet processing apparatus, a computer device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] With the continuous development of network services, header extension option fields have been introduced into data packets to adapt to complex traffic engineering strategies such as Service Function Chaining (SFC), Network Slicing, and Source Routing. In actual service deployments, network devices (such as switches and routers) often need to modify option fields in the header extension option fields that meet specific conditions. For example, when the maximum segment size (MSS) supported by the network device is smaller than the MSS carried in the header extension option field, the MSS in the header extension option field needs to be modified to the MSS supported by the network device. However, because the header extension option field has variable length and non-fixed structure, existing technologies struggle to quickly parse and modify option fields such as MSS in the header extension option field while ensuring high network device performance, resulting in low data packet processing efficiency. Summary of the Invention

[0003] This application provides a data packet processing method, apparatus, device, medium, and product that can quickly parse and modify target option fields (such as MSS fields) in the header extended option field while ensuring the high performance of network devices, thereby improving the processing efficiency of data packets.

[0004] On one hand, embodiments of this application provide a data packet processing method. This method is applied to a network device, which is configured with a programmable hardware forwarding chip. The method is executed by the programmable hardware forwarding chip and includes: The first data packet received by the network device is obtained. The first data packet includes a header extension option field, which is an option field with variable length and non-fixed structure. Based on the hardware alignment constraints of the programmable hardware forwarding chip, the header extension option field is parsed to obtain the parsing result, which includes the target option field in the header extension option field. When the target option field is determined to meet the modification conditions, the target option field is modified, and the first data packet is updated based on the modified target option field to obtain the second data packet.

[0005] On one hand, embodiments of this application provide a data packet processing apparatus, which is applied to a network device. The network device is configured with a programmable hardware forwarding chip, and the apparatus is executed by the programmable hardware forwarding chip. The apparatus includes: The message parsing unit is used to obtain the first data packet received by the network device. The first data packet includes a header extension option field, which is an option field with variable length and non-fixed structure. The message parsing unit is also used to parse the header extension option field based on the hardware alignment constraints of the programmable hardware forwarding chip, and obtain the parsing result, which includes the target option field in the header extension option field. The modification and reassembly unit is used to modify the target option field when it is determined that the target option field meets the modification conditions, and update the first data packet based on the modified target option field to obtain the second data packet.

[0006] In one embodiment, the programmable hardware forwarding chip includes data packet parsing rules designed based on hardware alignment constraints. The hardware alignment constraints are used to indicate that the byte length of the hardware alignment operation granularity of the programmable hardware forwarding chip is a first byte length. The data packet parsing rules are used to indicate that the first option field occupied by the target option field is located from the header extended option field based on the first byte length and according to the option field truncation and splicing method. The message parsing unit, based on the hardware alignment constraints of the programmable hardware forwarding chip, parses the header extension option field to obtain the parsing result, including: According to the instructions of the data packet parsing rules, determine the i-th reference option field from the header extended option field, and determine whether the i-th reference option field contains the identifier of the target option field, where i is a positive integer; If the i-th reference option field contains the identifier of the target option field, then the first option field occupied by the target option field in the i-th reference option field is added to the parsing result; Wherein, if i=1, then the i-th reference option field is the option field occupied by the first option field in the header extended option field; if i>1, and there are remaining bytes after the i-1 reference option field is truncated in units of the first byte length, then the i-th reference option field is the option field obtained by concatenating the remaining bytes and the next option field of the i-1 reference option field in the header extended option field; if i>1, and there are no remaining bytes after the i-1 reference option field is truncated in units of the first byte length, then the i-th reference option field is the option field occupied by the next option field of the i-1 reference option field in the header extended option field.

[0007] In one embodiment, the message parsing unit is further configured to: If the i-th reference option field does not contain the identifier of the target option field, then the i-th reference option field is truncated in units of the first byte length to obtain the second option field in the header extended option field that is located before the target option field. The second option field is then added to the parsing result; the byte length of the second option field is the same as the length of the first byte. Let i = i + 1, and execute the step of determining the i-th reference option field from the extended option field in the header.

[0008] In one embodiment, the message parsing unit is further configured to: When there is a preceding byte before the target option field in the i-th reference option field, the third option field in the header extended option field is determined based on the option field occupied by the preceding byte. The byte length of the third option field is the length of the second byte, and the length of the second byte is less than the length of the first byte. Add the third option field to the parsing result.

[0009] In one embodiment, the programmable hardware forwarding chip further includes a front buffer and a message buffer, wherein the first data packet is stored in the message buffer; The message parsing unit determines the i-th reference option field from the header extended option field, and determines whether the i-th reference option field contains the identifier of the target option field, including: Read the header extended option fields from the message buffer into the front buffer; Pre-read the identifier of the next option field of the (i-1)th reference option field in the pre-buffer; If the identifier of the next option field of the (i-1)th reference option field is the identifier of the target option field, then the i-th reference option field is determined based on the next option field of the (i-1)th reference option field, and it is determined that the i-th reference option field contains the identifier of the target option field.

[0010] In one embodiment, the message parsing unit is further configured to: If the identifier of the next option field of the (i-1)th reference option field is not the identifier of the target option field, then the i-th reference option field is determined based on the next option field of the (i-1)th reference option field, and it is determined that the i-th reference option field does not contain the identifier of the target option field.

[0011] In one embodiment, the programmable hardware forwarding chip further includes a counter for the first data packet, the counter being set with a preset length threshold equal to the length of the header extension option field; the packet parsing unit is further configured to: Get the length of the third byte of the option field added to the parsed result; Increase the length of the parsed bytes in the counter of the first data packet by the length of the third byte; If the length of the parsed bytes after the increase is equal to the preset length threshold in the counter of the first data packet, it is determined that there is no target option field in the header extension option field, and the step of determining the i-th reference option field from the header extension option field is stopped.

[0012] In one embodiment, the programmable hardware forwarding chip includes a header buffer containing multiple storage blocks of a first byte length; the programmable hardware forwarding chip includes a parsing result storage rule designed based on hardware alignment constraints, the parsing result storage rule being used to record the storage blocks allocated to each data structure in the header data structure definition; the header data structure definition includes a first data structure of a target option field in bytes, a second data structure of a first byte length, and a third data structure of a second byte length. The message parsing unit adds the first option field to the parsing result, including: storing the first option field in the storage block allocated for the first data structure in the header buffer according to the parsing result storage rules; The message parsing unit adds the second option field to the parsing result, including: storing the second option field in the storage block allocated for the second data structure in the header buffer according to the parsing result storage rules; The message parsing unit adds the third option field to the parsing result, including: storing the third option field in the storage block allocated for the third data structure in the header buffer according to the parsing result storage rules.

[0013] In one embodiment, the first data message further includes a fixed header, which includes a checksum field; When the reassembly unit determines that the target option field meets the modification conditions, it modifies the target option field and updates the first data packet based on the modified target option field to obtain the second data packet, including: When the target option field is determined to meet the modification conditions, the target option field is modified, and the checksum field is recalculated based on the modified target option field. Based on the modified target option field and the recalculated checksum field, the first data packet is updated to obtain the second data packet.

[0014] In one embodiment, the programmable hardware forwarding chip further includes a matching action table for the target option field. The matching action table contains at least one matching rule and a modification action rule corresponding to each matching rule. The first data packet also includes a fixed header. The programmable hardware forwarding chip includes a header buffer, which stores the fixed header and the target option field. When the recombination unit determines that the target option field meets the modification conditions, it modifies the target option field, including: Extract the header protocol fields from the fixed header from the header buffer; Determine the target matching rule that the header protocol field conforms to from the matching action table, and determine the recommended field parameters of the target option field based on the modification action rule corresponding to the target matching rule; Retrieve the actual field parameters of the target option field from the header cache; If the recommended field parameter of the target option field does not match the actual field parameter of the target option field, then the target option field is determined to meet the modification conditions, and the actual field parameter of the target option field in the header cache is updated to the recommended field parameter of the target option field.

[0015] In one embodiment, the programmable hardware forwarding chip includes a header buffer that stores a fixed header and a target option field. The recombination unit is modified to recalculate the checksum field based on the modified target option field, including: Retrieve the actual field parameters of the target option field and the actual field parameters of the checksum field from the header cache; The difference between the actual field parameter of the checksum field and the actual field parameter of the target option field is calculated to obtain the intermediate field parameter of the checksum field; If the actual field parameter of the target option field in the header cache is updated to the recommended field parameter of the target option field, then the recommended field parameter of the target option field and the intermediate field parameter of the checksum field are summed to obtain the recommended field parameter of the checksum field. Update the actual field parameters of the checksum field in the header cache to the recommended field parameters of the checksum field.

[0016] In one embodiment, the programmable hardware forwarding chip includes a header buffer containing a fixed header after recalculating the checksum field, a modified target option field, and an option field in the header extended option field that precedes the target option field. The programmable hardware forwarding chip also includes a message buffer where the first data packet is stored. The reassembly unit updates the first data packet based on the modified target option field and the recalculated checksum field to obtain the second data packet, which includes: Retrieve the fixed header after recalculating the checksum field from the header cache, the modified target option field, and the option field in the header extended option field that precedes the target option field; Read the content field following the target option field from the first data packet from the message buffer; The second data packet is assembled based on the fixed header after the recalculated checksum field, the modified target option field, the option field in the header extended option field before the target option field, and the content field in the first data packet after the target option field.

[0017] On one hand, embodiments of this application provide a computer device, including: a processor, a memory, and a communication interface; The processor is connected to the memory and the communication interface. The communication interface is used to provide network communication functions, the memory is used to store program code, and the processor is used to call the program code to execute the above-mentioned data packet processing method.

[0018] On one hand, embodiments of this application provide a computer-readable storage medium storing a computer program, the computer program including computer instructions adapted to be loaded by a processor and executed by the above-described data packet processing method.

[0019] On the one hand, embodiments of this application provide a computer program product, which includes a computer program or computer instructions. When the computer program or computer instructions are executed by a processor, they implement the above-mentioned data packet processing method.

[0020] This application provides a data packet processing scheme applied to a network device equipped with a programmable hardware forwarding chip. The scheme is executed by the programmable hardware forwarding chip and includes: acquiring a first data packet received by the network device. The first data packet includes a header extension option field, which is a variable-length and non-fixed-structure option field. This means the scheme processes data packets with complex structures, laying the foundation for subsequent targeted solutions and ensuring the universality and practicality of this scheme. Based on the hardware alignment constraints of the programmable hardware forwarding chip, the header extension option field is parsed to obtain a parsing result containing the target option field in the header extension option field. By designing the header extension option field parsing process using the hardware alignment constraints of the programmable hardware forwarding chip, variable-length structures that are difficult for hardware to process directly become regular and controllable, achieving the ability to accurately and efficiently parse complex fields using high-performance hardware. When the target option field meets the modification conditions, it is modified. The first data packet is updated based on the modified target option field to obtain a second data packet. By directly performing modification operations based on accurate parsing, this application achieves a seamless integration of business logic and high-performance forwarding. It can perform refined and intelligent processing of data packets while ensuring line-rate forwarding performance. Therefore, this application can quickly parse and modify target option fields (such as MSS fields) in the header extended option field while ensuring the high performance of network devices, thus improving the processing efficiency of data packets. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the structure of a network device provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a TCP packet provided in an embodiment of this application; Figure 3 This is a schematic diagram of the architecture of a data packet processing system provided in this application; Figure 4 This is a flowchart illustrating a data packet processing method provided in an embodiment of this application; Figure 5 This is a flowchart illustrating a data packet parsing method provided in an embodiment of this application; Figure 6 This is a flowchart illustrating a message reassembly method provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a data packet processing device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0022] To facilitate a better understanding of the technical solutions proposed in this application, the technical terms involved in this application will be explained below.

[0023] I. Network Equipment: Network devices can refer to devices that integrate dedicated hardware and software systems for intelligently connecting, managing, and forwarding data in a computer network. Network devices can include, but are not limited to, switches, routers, and firewalls.

[0024] Please see Figure 1 This is a schematic diagram of the structure of a network device provided in an embodiment of this application. The network device typically adopts a "layered architecture" design and can be composed of a management plane, a network operating system, software forwarding logic, and hardware forwarding chips.

[0025] (1) Management Plane: The management plane is the "brain command center" of network devices. It is responsible for non-real-time operations such as configuration management, status monitoring, fault diagnosis, and software upgrades of network devices. It is the entry point for administrators to interact with network devices.

[0026] For example, the management side can be responsible for: ① Receive instructions from the administrator, such as through CLI (Command-Line Interface), Web interface, SNMP (Simple Network Management Protocol, a protocol for monitoring and managing network devices), NetConf (Network Configuration Protocol), and other protocols; ② Maintain the global status of network devices, such as interface status, routing table version, CPU (Central Processing Unit) utilization, and memory utilization; ③ Deploy configurations to the control plane, such as routing policies and ACL (Access Control List) rules, and collect feedback on the control plane's operational status.

[0027] The management plane typically does not participate in data forwarding and has a lower priority than the control plane and forwarding plane. Even if the management plane fails (such as a web service crash or CLI process malfunction), as long as the control plane (responsible for route calculation and forwarding rule calculation) and the forwarding plane (responsible for data packet forwarding) are normal, the network device can continue to forward data (without affecting service continuity).

[0028] (2) Network Operating System (NOS): The network operating system is the "central nervous system" of a network device. It is the kernel-level software of the network device and the carrier of the control plane and management plane. It is responsible for parsing instructions from the management plane, performing logical operations on the control plane (such as route calculation and forwarding policy decision-making), and synchronizing the results to the forwarding plane.

[0029] For example, a network operating system can be responsible for: ① Provide APIs (Application Programming Interfaces) for the management plane, such as command-line interpreters and web frameworks, to handle administrator configuration requests, such as translating CLI commands like "create virtual interface" into internal configuration commands; ② Run control plane protocols such as OSPF (Open Shortest Path First), BGP (Border Gateway Protocol), STP (Spanning Tree Protocol), and VRRP (Virtual Router Redundancy Protocol) to complete routing calculation, topology discovery, and redundancy backup. ③ Generate forwarding rules, such as FIB (Forwarding Information Base, which stores the mapping relationship between "destination address → outgoing interface or next hop") and flow table (used for traffic matching rules of SDN (Software-Defined Networking) devices), and distribute the forwarding rules to software forwarding logic or hardware forwarding chip; ④ Coordinate the interaction between the management plane and the control plane, such as passing the administrator's "Modify BGP Autonomous System Number" command to the control plane for execution.

[0030] (3) Software Forwarding Logic: Software forwarding logic is the "software backup" of the forwarding plane. It is a forwarding program that runs in user mode (non-kernel privileged mode) or kernel mode (kernel privileged mode) of the network operating system and is used to handle complex, low-throughput traffic or new protocol traffic that is not supported by the hardware.

[0031] For example, the software forwarding logic can be responsible for: ① When the hardware forwarding chip does not support a certain forwarding rule, such as a custom ACL or a niche routing protocol, the software forwarding logic takes over the processing of the traffic. ② Perform deep inspection on traffic, such as DPI (Deep Packet Inspection, which analyzes the application layer content of data packets) and application identification (such as identifying application types). These operations require parsing multiple layers of data packets, which is usually difficult to implement efficiently in hardware and must be done in software. ③ As a backup for hardware forwarding, when the hardware forwarding chip fails, such as the ASIC (Application-Specific Integrated Circuit) failing, software forwarding can temporarily take over some traffic (but its performance is far lower than that of hardware and can only meet basic connectivity requirements).

[0032] Software forwarding logic is highly flexible (supports arbitrary custom logic), but its forwarding performance is low (limited by CPU processing power).

[0033] (4) Hardware Forwarding Chip: Hardware forwarding chips are the "performance engines" of the forwarding plane. They can include application-specific integrated circuits (ASICs) and network processors (NPUs) designed for high-speed data forwarding. They are the key to enabling devices to achieve "line-speed forwarding" (i.e., the forwarding rate equals the interface rate, with no bottleneck).

[0034] For example, a hardware forwarding chip can be responsible for: ① Based on the FIB table or flow table issued by the network operating system, data packets are quickly forwarded by looking up the table, such as looking up the route by IP (Internet Protocol) address, looking up the port by MAC (Media Access Control Address) address, and matching the flow table by the five-tuple (containing source IP, destination IP, source port, destination port, and protocol); ② It supports hardware-accelerated protocol processing, such as VLAN (Virtual Local Area Network) tag stripping and addition, ACL filtering, etc. These operations are directly completed by the chip hardware circuit, which is extremely fast; ③ Implement pipelined forwarding, breaking down the process of "receiving → parsing → table lookup → rewriting → sending" into multiple hardware stages for parallel processing to maximize throughput.

[0035] Hardware forwarding chips have extremely high performance, reaching Tbps (Terabit per second), but their flexibility is limited (they only support predefined protocols and functions of the chip, and new functions usually require the chip manufacturer to update the firmware or use software assistance).

[0036] (5) Collaboration process of each part (taking data packet forwarding as an example): ① Administrator configuration: Issue an ACL rule "Block access from xx address" through the management interface; ②NOS processing: The network operating system parses the ACL rules, generates corresponding forwarding entries (such as ACL entries), and sends the forwarding entries to the hardware forwarding chip and software forwarding logic; ③ Hardware forwarding priority: When a data packet enters the network device, the hardware forwarding chip first matches the ACL entries. If an "ACL rule that prohibits access" is matched, the data packet is dropped directly (completed in microseconds); ④ Software forwarding fallback: If the data packet is a custom protocol that the hardware does not support (such as a certain industrial protocol), the hardware forwarding chip cannot recognize it and it is handed over to the software forwarding logic for processing. The software parses the protocol and then decides whether to forward it. ⑤ Status Feedback: NOS synchronizes the number of ACL rule hits, software forwarding logic and / or hardware forwarding chip forwarding statistics to the management plane, which can be viewed by the administrator through the web interface.

[0037] II. Data Messages: A data packet is a set of data encapsulated and formatted according to a specific network protocol (such as IP protocol, TCP protocol, etc.). Its structure includes header information used for network control and routing (which can be simply referred to as the data packet header) and a payload carrying upper-layer application data. Network devices can identify, process, and forward data packets by parsing the header information.

[0038] The header information includes a fixed header. A fixed header refers to a mandatory, fixed-length basic control information area within the data packet header, defined according to the specifications of a specific network protocol (such as IP or TCP). Please refer to [link to relevant documentation]. Figure 2 This is a schematic diagram of the structure of a TCP packet provided in an embodiment of this application. As can be seen, the fixed header (20 bytes) of a TCP (Transmission Control Protocol) packet includes the following option fields: Source Port, Destination Port, Sequence Number, Acknowledgment Number, Data Offset, Reserved, NS (ECN - nonce concealment protection), CWR (Congestion Window Reduced), ECE (ECN - Echo), URG (Urgent), ACK (Acknowledgment), PSH (Push flag, requesting immediate data delivery), RST (Reset), SYN (Synchronize), FIN (Finish), Window (Window size), Checksum, and Urgent Pointer. One byte equals 8 bits. Byte offset refers to the distance from the start of a datagram to a specific byte position. Bit offset refers to the distance from the start of a datagram to a specific bit position.

[0039] For example, in addition to the fixed header, the header information may also include header extended option fields. See, for example, [link to relevant documentation]. Figure 2The TCP header extension options field is an optional area, with a byte length ranging from 0 to 40 bytes. The byte length of the header extension options field can be calculated from the Data Offset field in the TCP fixed header: Header extension options field byte length = Data Offset × 4 - 20. Here, Data Offset is in 4-byte units, and 20 bytes is the length of the TCP fixed header. When the calculation result is 0, it indicates that the TCP packet does not contain a header extension options field.

[0040] III. Header Extended Options Field: Header extension options fields are variable-length (or variable-length) options fields in the data packet header with non-fixed structures. They can be used to supplement enhanced functions not covered by the fixed header, such as the Record Route and Timestamp option fields in IP packets, and the MSS (Maximum Segment Size) and SACK (Selective Acknowledgment) option fields in TCP packets.

[0041] The option fields in the header extended options field typically follow the Kind-Length-Data (KLD) triple encoding rule: ①Kind (1 byte): Identifies the option type, such as 0x02 representing TCP MSS and 0x07 representing IP Record Route; ②Length (1 byte): Declares the total length of the option (including Kind and Length); ③Data (variable bytes): The specific content of the option, such as the Data field of MSS storing the specific segment size value.

[0042] The variable length of the header extension options field stems from two main needs: First, the requirements for extension functions vary significantly across different network scenarios. For example, only 4 bytes are needed when only MSS negotiation is required, while more bytes are needed when multiple SACK blocks are required. The variable length design allows for the allocation of header space as needed, avoiding resource waste or insufficient functionality caused by a fixed length. Second, network protocol iterations continuously add new extension options, such as the Fast Open option field added to TCP (used to allow application data to be directly carried in the SYN (Synchronize) message of the TCP three-way handshake). The variable length structure can be compatible with new options without modifying the basic protocol framework, reducing protocol upgrade costs.

[0043] The reason for the non-fixed structure of the header extension option field is mainly due to the diversity and flexibility requirements of extension options: different extension options have significantly different uses, encoding formats, and data lengths. For example, the Record Route option field needs to store multiple route addresses, and the Timestamp option field needs to record timestamps and identification information. It is impossible to meet all requirements with a unified and fixed field arrangement. At the same time, the extension option systems of different protocols (IP, TCP, etc.) are independent of each other, and options within the same protocol can also be selected as needed. The non-fixed structure design allows the header extension option field to be dynamically combined according to the actual type of option carried. It is compatible with existing options and reserves expansion space for future added options without having to reconstruct the header basic structure due to the addition of new functions.

[0044] Furthermore, the data offset field in a data packet is typically measured in 4-byte units. Therefore, the total length of the data packet header must be aligned to 4 bytes, meaning the total length of the data packet header must be a multiple of 4 bytes to ensure efficient processing by the hardware forwarding chip and the network operating system. For example, when the header extension option field is less than a multiple of 4 bytes, it can be padded with a 1-byte special option. This 1-byte special option can include EOL (Kind=0, end of option) and NOP (Kind=1, no operation).

[0045] IV. Target Options Field: The target option field refers to the option field located within the header extended option field that needs to be determined whether to perform a modification operation. Network devices can parse the target option field from the header extended option field and dynamically decide whether to modify the target option field according to preset rules (such as the target option field matching action table below) to achieve fine-grained traffic control and quality of service assurance.

[0046] For example, the target option field may include, but is not limited to: (1) MSS (Maximum Segment Size) option field: The MSS option field is used during the TCP connection establishment phase to negotiate the maximum size of the TCP payload that both communicating parties can receive. This collaboratively avoids fragmentation at the IP layer, thereby improving transmission efficiency and reliability. During the TCP three-way handshake, the initiating and responding parties include the MSS option field in their respective SYN packets, informing each other of their maximum acceptable TCP payload. When the SYN packet passes through a network device that supports this function, the network device calculates a recommended upper limit for MSS based on its own egress interface MTU (Maximum Transmission Unit, referring to the maximum IP datagram length it can carry). The formula relating MSS and MTU is: MSS = MTU - IP header length - TCP header length. In tunneling scenarios such as GRE (Generic Routing Encapsulation) and IPsec (Internet Protocol Security), an additional tunnel header is added to the outer layer of the original IP packet (e.g., a GRE tunnel typically adds 24 bytes, including a 20-byte outer IP header and a 4-byte GRE header). This reduces the effective MTU that the link can actually carry, and the corresponding MSS upper limit needs to be adjusted accordingly. If a network device detects that the MSS value advertised by the peer is greater than this calculated upper limit, it will proactively reduce this MSS value to a more conservative value. Simultaneously, after modifying the MSS value, the network device must synchronously update the checksum field in the TCP header (used by the receiving end to verify packet integrity) to ensure the packet format is valid. In this way, when the SYN packet completes the three-way handshake and reaches the destination host, the MSS value negotiated by both parties will be the minimum value allowed by all relevant network devices along the entire network path from source to destination. From then on, both communicating parties will use this negotiated value to encapsulate TCP segments, ensuring that the total length of the subsequently generated IP datagrams (IP header + TCP header + TCP payload) will not exceed the minimum MTU on the path. This fundamentally avoids inefficient IP fragmentation during transmission (fragmentation increases network latency and packet loss risk, and requires the receiving end to reassemble, consuming host resources), and reduces the burden on endpoint hosts and routers to reassemble fragments.

[0047] (2) Record Route option field: The Record Route option field is one of the extended options in the TCP header, used to record the IP addresses of each hop (router or gateway) a data packet traverses from the source host to the destination host. In some network diagnostics or path control scenarios, network devices may need to determine if the record space in the Record Route option field is exhausted. For example, when an IP packet configured with the Record Route option field enters a network device, the device can parse the Data portion of the Record Route option field and count the number of recorded hops. If the hop count has reached its limit, to prevent new path information from being overwritten, the network device may choose to clear the existing record in the Record Route option field or replace it with a new, shorter path before forwarding. Conversely, if the space is not full, the Record Route option field can insert its own IP address.

[0048] (3) SACK (Selective Acknowledgment) option field: The SACK option field is a TCP performance optimization option used to address the limitations of traditional TCP's "cumulative acknowledgment" mechanism. When the receiver receives discontinuous TCP data segments (i.e., packet loss occurs), cumulative acknowledgments only inform the sender that "all data up to a certain sequence number has been correctly received," forcing the sender to retransmit all data after that sequence number (even if some data has already been received). The SACK option field allows the receiver to explicitly inform the sender "which discontinuous data blocks have been successfully received," enabling the sender to retransmit only the lost portions, significantly improving transmission efficiency in packet loss scenarios. In a security environment with extremely stringent requirements for connection establishment and closure, policies might stipulate that the SACK option is only allowed during the TCP data transmission phase (i.e., after the handshake is complete). In this case, if a network device detects the SACK option in a SYN or FIN (connection closure) packet, it may identify it as an anomaly or attack and delete or modify it to enhance network security.

[0049] (4) Timestamp option field: The Timestamp option field is an extension option in the TCP header used to carry the sender's sending timestamp and the receiver's acknowledgment timestamp for previous packets. It is primarily used to more accurately measure round-trip time (the total time it takes for a data packet to travel from sender to receiver and back to the acknowledgment) and to calculate PAWS (Protection Against Wrapped Sequences). Network devices may need to determine whether the timestamp value is within a reasonable range or has been maliciously tampered with. For example, if an unreasonable timetamp value is detected as going backwards or jumping, it may indicate a replay attack or clock synchronization problem. In such cases, network devices can choose to ignore the timestamp information carried in the Timestamp option field or generate a reasonable new timestamp using local time to replace it, ensuring that time-stamp-dependent TCP algorithms (such as RTO (Retransmission Timeout) estimation) function correctly and preventing abnormal connection interruptions.

[0050] V. Hardware Alignment Constraints: Hardware alignment constraints are low-level data processing rules determined by the physical characteristics or architecture of the hardware during the design of a hardware forwarding chip. They specify the byte-level alignment requirements that data packets must meet during storage, parsing, and modification within the hardware. Hardware forwarding chips typically employ a pipelined architecture, which decomposes the packet processing into multiple sequential and parallel processing stages (such as packet parsing, matching action execution, and packet reassembly and transmission). Intermediate results are passed between stages through buffers, thereby enabling continuous and high-speed data packet flow within the hardware.

[0051] For example, a hardware forwarding chip may include a programmable hardware forwarding chip. A programmable hardware forwarding chip refers to a high-performance packet forwarding device implemented using hardware architectures such as ASICs and NPUs, which supports custom configuration of packet processing logic through high-level programming languages. Examples include ASICs or NPUs that support P4 (Programming Protocol-Independent Packet Processors, an open-source high-level data plane programming language) programming.

[0052] Hardware alignment constraints for programmable hardware forwarding chips can be used to indicate that the byte length of the hardware alignment operation granularity of the programmable hardware forwarding chip is the first byte length. Hardware alignment operation granularity refers to the minimum number of bytes (i.e., the first byte length) used by the programmable hardware forwarding chip when performing data storage, access, and processing. This means that operations involving reading, writing, parsing, modifying, and verifying data packet headers must be performed in multiples of the first byte length (e.g., 1x, 2x, etc.) to ensure that hardware circuits (such as caches, registers, and buses) can complete access in one go, avoiding additional overhead and errors caused by crossing boundaries. A common hardware alignment operation granularity is 4 bytes (32 bits), which is consistent with the design of header length fields in many network protocols (e.g., the DataOffset in the TCP header is in 4-byte units), facilitating direct hardware access to complete fields via address addressing.

[0053] For example, a programmable hardware forwarding chip may include a packet buffer, a prefetch buffer, and a packet header vector (HPV). The packet buffer stores the received raw data packets, ensuring that subsequent stages can readily access the required fields; it can be constructed using on-chip SRAM (Static Random-Access Memory) or a dedicated packet buffer memory. The prefetch buffer temporarily caches the data packet header, supporting packet parsing; it can be constructed using a FIFO (First In, First Out) buffer or a small-scale SRAM. The header packet vector (HPV) stores the parsed header information, providing a fast access interface for the matching action execution stage; it can be constructed using a high-speed register file or SRAM.

[0054] Hardware forwarding chips employ a pipelined architecture, providing near-line-speed forwarding performance. However, their underlying physical design introduces hardware alignment constraints, which contradicts the "variable length and non-fixed structure" characteristics of the header extension option field. Specifically, the length of the header extension option field and the starting position of each option field are variable, and the option fields may not satisfy the boundary alignment granularity of the hardware alignment operation. This makes it difficult for hardware forwarding chips to process or efficiently process such flexible protocol fields, typically requiring software assistance to parse and modify the target option field. For example, network devices can employ a software processing scheme based on a general-purpose processor (CPU) to modify the target option field. In this scheme, the network device sends the received data packets to the central processing unit (CPU), where software programs running on the CPU (such as software forwarding logic running on the network operating system) parse and modify the data packets layer by layer. The software program can sequentially traverse each option field of the header extended option field. For example, it reads the Kind value to determine the option type. If it is a target option field (such as MSS), it extracts and determines whether its Data content needs to be modified. If not, it reads the Length value, precisely skips the remaining part of the current option field based on this length, and then moves to the beginning of the next option to continue the judgment. This process is essentially serial and byte-by-byte software logic. Its advantage is high flexibility (supporting arbitrary custom logic), but its forwarding performance is low (limited by CPU processing power). The CPU's processing bandwidth is usually at the Gbps level, far below the line speed requirements of modern high-speed communication interfaces (100Gbps and above). Software parsing and modification become the performance bottleneck of the entire forwarding process, leading to decreased device throughput, increased and unstable forwarding latency, and failing to meet the high-performance and low-latency requirements of modern data centers. At the same time, a large amount of computing resources are used for packet processing, resulting in high CPU utilization and vulnerability to SYN Flood attacks (a common distributed denial-of-service attack), which may affect the normal operation of the device's management and control planes.

[0055] To overcome the performance bottleneck of software processing, this application provides a data packet processing scheme that supports direct parsing and modification of target option fields on a programmable hardware forwarding chip, achieving a balance between the high bandwidth and high performance of hardware and the flexibility of software. This scheme proposes a novel design paradigm: without changing the underlying hardware architecture, it translates the variable protocol structure into a fixed sequence of operations that can be efficiently executed by the hardware by designing a set of matching parsing and storage rules. This design paradigm can be achieved through the following three collaborative mechanisms: (1) Data packet parsing mechanism coordination: This data packet parsing mechanism dynamically adapts hardware alignment constraints and variable-length option field characteristics to construct a "truncation-concatenation-iterative positioning" data packet parsing rule, transforming the variable protocol structure into a fixed sequence of hardware-executable operations. For example, this data packet parsing rule includes: ① The first option field is used as the first reference option field (i=1). Subsequent reference option fields (i>1) are generated by concatenating the remaining bytes after the previous reference option field is truncated (if any) with the next option field (i>1 and there are remaining bytes), or by directly taking the next option field (i>1 and there are no remaining bytes). ② Combine the pre-read option field identifier (such as Kind value) in the pre-buffer to detect the identifier matching of the option field in the reference option field. If there is no match, the field is truncated in units of the first byte length. If there is a match, the target option field is extracted and stored. ③ Introduce a counter mechanism (preset length threshold = total length of header extension option field), accumulate the length of parsed bytes, and terminate parsing when the preset length threshold is reached.

[0056] Through the above collaboration, the hardware does not need to traverse byte by byte serially, but processes in batches based on the length of the first byte, balancing the flexibility of variable-length structures with the efficiency of hardware alignment, and achieving rapid location of target option fields.

[0057] (2) Collaborative storage mechanism for parsing results: The parsing result storage mechanism uses structured storage mapping and precise matching with hardware cache units to collaboratively store the parsed differential option fields, such as the target option field itself (i.e., the first option field below), the alignment truncation field (i.e., the second option field below, with a byte length equal to the first byte length), and the leading short byte field (i.e., the third option field below, with a byte length equal to the second byte length but less than the first byte length), into a fixed-granularity hardware cache area (i.e., the header cache area).

[0058] Structured storage mapping refers to binding the three types of differentiated option fields one-to-one with the structured data structures defined in the header data structure definition. Precise matching of hardware cache units means that the data structures in the header data structure definition can be mapped to fixed storage blocks in the header cache. The header cache can contain multiple storage blocks. A storage block is a fixed-size storage unit in the header cache, with the length of the first byte as the unit. Each storage block is independently addressed and boundary-aligned to ensure efficient hardware addressing and access.

[0059] The header data structure definition refers to the standardized description of the field composition, length, alignment, storage format, and semantic relationships of each layer of the data packet header (such as Ethernet, IPv4 (Internet Protocol version 4), TCP, etc.) and extended options (such as TCP option fields and IPv4 extension headers) in a structured and typed manner. Its goal is to transform the "unstructured binary data stream" of network packets into a standardized data structure that can be directly parsed, efficiently accessed, and precisely modified by programmable hardware forwarding chips. This allows the hardware to bypass complex dynamic parsing logic and quickly process the packet header according to predefined rules. In other words, the header data structure definition is the "format specification" (clarifying "how to parse the meaning of fields") + "storage layout specification" (clarifying "how to store and access fields in hardware") + "semantic relationship guide" (clarifying "the hierarchy and dependencies between fields") for programmable hardware forwarding chips to parse data packets. It is the technical foundation for ensuring line-speed forwarding and low-latency processing in hardware.

[0060] For example, with the first byte being 4 bytes long, the header data structure definition can declare ten 4-byte data structures, one 2-byte data structure, one 1-byte data structure, and one data structure for storing the target option field. For instance, the P4-encoded header data structure definition could be: struct my_headers_t { ethernet_t ethernet; / / Data structure used to store the Ethernet header ipv4_t ipv4; / / Data structure used to store the IPv4 header tcp_h tcp; / / Data structure used to store the TCP header tcp_option_4byte_h

[10] tcp_options_4byte_before; / / 10 four-byte data structures tcp_option_2byte_h tcp_options_2byte_before; / / A 2-byte data structure tcp_option_1byte_h tcp_options_1byte_before; / / A 1-byte data structure tcp_option_mss_h tcp_options_mss; / / Data structure used to store MSS } The `my_headers_t` structure is a standardized, structured definition used in programmable hardware forwarding chips that support P4 programming. It's used for uniformly parsing, storing, and modifying headers at each layer of data packets. It also serves as the carrier of protocol headers at each layer during the chip's pipelined packet processing, covering full-level header processing for Ethernet, IPv4, TCP, and TCP variable-length extension options. `ethernet_t` can represent a standard Ethernet frame header structure type defined in the P4 language according to a specific protocol specification; `ethernet` represents an Ethernet frame header instance in the `my_headers_t` structure, used to carry the complete header information for the Layer 2 (Data Link Layer). `ipv4_t` represents a standard IPv4 packet header structure type defined in the P4 language according to a specific protocol specification; `ipv4` represents an IPv4 packet header instance in the `my_headers_t` structure, used to carry the complete header information for the Layer 3 (Network Layer). `tcp_h` represents a TCP fixed header structure type defined in the P4 language according to a specific protocol specification; `tcp` represents a TCP fixed header instance in the `my_headers_t` structure, used to carry the basic TCP header information for the Layer 4 (Transport Layer). `tcp_option_4byte_h` represents a custom 4-byte aligned TCP option field structure type in the P4 language; `tcp_options_4byte_before` represents a 4-byte aligned TCP option field instance in the `my_headers_t` structure, using 10 sets of 4-byte structures to store a maximum of 40 bytes of TCP options, adapting to the hardware's 32-bit alignment access requirements. `tcp_option_2byte_h` represents a custom 2-byte TCP option field structure type in the P4 language; `tcp_options_2byte_before` represents a 2-byte TCP option field instance in the `my_headers_t` structure, used to handle short-format TCP option fields that are not 4-byte aligned. `tcp_option_1byte_h` represents a custom 1-byte TCP option field structure type in the P4 language; `tcp_options_1byte_before` represents a 1-byte TCP option field instance in the `my_headers_t` structure, which can be used to handle single-byte, lengthless TCP padding options. tcp_option_mss_h represents the custom MSS-specific TCP option field structure type in the P4 language; tcp_options_mss represents the MSS option instance in the my_headers_t structure, used for independent storage and fast operation of MSS option fields.It is evident that the design of my_headers_t closely revolves around the line-speed forwarding and high-efficiency processing requirements of programmable hardware forwarding chips. Through a structured layout categorized by length, it enables precise parsing, fast access, and convenient modification of the TCP header extension option fields, effectively avoiding the performance loss caused by non-aligned access and ensuring the processing efficiency and stability of programmable hardware forwarding chips in high-speed forwarding scenarios.

[0061] This combinatorial, structured design covers all possible combinations of the total length of option fields preceding the target option field in the header extended option field. For example, when the total length of option fields preceding the target option field in the header extended option field is 4, a 4-byte data structure can be selected for storage; when the total length of option fields preceding the target option field in the header extended option field is 11, two 4-byte, one 2-byte, and one 1-byte data structures can be selected for storage. For instance, during runtime parsing, the alignment truncation field can be stored in the storage block mapped by the 4-byte data structure, the preceding short byte field can be stored in the storage block mapped by the 2-byte data structure or the 1-byte data structure (depending on the actual length of the preceding short byte field); the target option field itself is stored in the storage block mapped by a dedicated data structure.

[0062] By using the parsing result storage rules, various option fields (first option field, second option field, third option field) can be bound to the above data structure one by one. The programmable hardware forwarding chip can directly read and write according to the fixed mapping relationship without dynamic address calculation, thereby achieving efficient collaborative storage of parsing results.

[0063] (3) Process mechanism coordination: This mechanism achieves near-line-speed high-performance forwarding by deeply embedding the target option field processing, checksum field update, and packet reconstruction of the header extended option field into the programmable hardware forwarding pipeline through a hardware pipelined collaboration of the entire process of "parsing-matching-modifying-verifying-updating".

[0064] ① Parsing and caching collaboration: During the message reception phase, the data packet is stored in the message buffer, and the header extended option field is extracted to the pre-buffer. The data packet parsing mechanism is invoked, and the target option field, alignment truncation field, and pre-short byte field are parsed out by iterative positioning of the reference option field, identification detection, and termination by the parser counter. The fixed header, target option field, and pre-short option field (including the second and third option fields) are then structured and stored in the header buffer according to the parsing result storage mechanism, providing hardware-accessible parsing results for subsequent processing.

[0065] ② Matching and Modification Condition Determination Coordination: Based on the matching action table for the target option field built into the programmable hardware forwarding chip, it accurately determines whether the target option field needs to be modified, and directly implements the modification in the header buffer when modification is required, realizing hardware-level condition filtering and precise modification.

[0066] ③ Checksum recalculation collaboration: Since the fixed header of the data packet contains a checksum field, after the target option field is modified in the header buffer, the checksum field can be recalculated in the hardware at high speed by using its old and new values ​​through simple addition and subtraction, without the need for software intervention or traversing the packet.

[0067] ④ Efficient reassembly: At the end of the pipeline (such as the message reassembly and transmission stage), the output message can be quickly assembled from the header buffer (the neatly arranged new header) and the message buffer (containing unparsed content fields) like assembling building blocks.

[0068] Through the aforementioned collaborative design, this solution achieves a leap in processing performance from the CPU's Gbps level to hardware line speeds (100Gbps and above), resulting in a significant increase in throughput and extremely low and stable forwarding latency. While maintaining peak hardware performance, it gains the ability to efficiently process protocol extension fields with variable length and non-fixed structure at the hardware level, breaking through the rigid limitations of traditional hardware parsing. This solution offloads complex protocol processing tasks from the general-purpose CPU to a programmable hardware forwarding chip, greatly reducing CPU load and ensuring the stable operation of network device control and management plane system functions.

[0069] As can be seen, this solution is not a simple hardware porting of a software method, nor a partial patching of hardware capabilities. Rather, it involves a top-down redesign of an entire system-level processing paradigm and coordination rules, addressing the physical reality of "hardware alignment constraints." This paradigm successfully combines the flexibility of the protocol with the high performance of the hardware, achieving a goal that neither software nor hardware solutions could achieve alone: ​​simultaneously obtaining the flexibility to handle complex protocols and the ultimate performance of line-rate forwarding on a programmable hardware forwarding chip.

[0070] Please see Figure 3 This is a schematic diagram of the architecture of a data packet processing system provided in this application. The processing system includes a source device, a network device (at least one), and a destination device. The network device integrates a programmable hardware forwarding chip to achieve high-performance packet processing. The source device and the destination device can communicate and interact through the network device.

[0071] This system architecture uses a data flow of "source device → network device (including programmable hardware forwarding chip) → destination device". The source device initiates the data packet transmission and is responsible for generating and sending the data packet (including header extension options fields). The network device, as an intermediate processing node, is responsible for receiving data packets sent by the source device (such as the first data packet) and implementing a fully hardware-based processing flow of "parsing-matching-modification-verification-assembly" through a programmable hardware forwarding chip, overcoming the performance bottlenecks of traditional software processing. The destination device is the receiver of the data packet and is responsible for receiving and processing data packets forwarded by the network device (such as the second data packet).

[0072] This system architecture supports concurrent communication between multiple source devices and multiple destination devices. It can contain multiple layers (such as edge access layer and aggregation layer) according to the network topology, and each layer can deploy network devices (such as switches and routers) with integrated programmable hardware forwarding chips.

[0073] The source device and the target device may include, but are not limited to, personal computers, servers (physical servers or cloud servers), smartphones, Internet of Things devices (sensors, smart home appliances), vehicle terminals, industrial control equipment, etc. The embodiments of this application do not limit the type and quantity of the source device and the target device.

[0074] Figure 3 This is merely an illustrative representation of a possible system architecture for the technical solution of this application, and does not limit the system architecture of the technical solution of this application. That is, the technical solution of this application can also be applied to other forms of system architecture. For example, the number of terminal devices can be multiple.

[0075] In this application embodiment, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations. The acquisition of personal information must be based on the knowledge or consent of the individual (or have a legal basis for information acquisition), and subsequent data use and processing should be carried out within the scope of laws and regulations and the authorization of the personal information subject.

[0076] The following section provides a detailed description of the data message processing scheme proposed in this application.

[0077] Please see Figure 4 This is a flowchart illustrating a data packet processing method provided in an embodiment of this application. The method is applied to a network device equipped with a programmable hardware forwarding chip. The processing method is executed by the programmable hardware forwarding chip and includes the following steps S41-S43: S41. Obtain the first data packet received by the network device. The first data packet includes a header extension option field, which is an option field with variable length and non-fixed structure.

[0078] The first datagram can be any datagram received by a network device through an input interface. The header information of the first datagram includes a fixed header (such as an Ethernet header, IPv4 header, TCP or UDP (User Datagram Protocol) header) and header extension option fields. The header extension option fields are usually located in the fixed header of the network layer or transport layer, such as in the TCP header or IPv4 header.

[0079] S42. Based on the hardware alignment constraints of the programmable hardware forwarding chip, the header extension option field is parsed to obtain the parsing result, which includes the target option field in the header extension option field.

[0080] Programmable hardware forwarding chips are hardware chips in network devices specifically designed for high-speed packet forwarding. They can realize packet parsing, modification, and forwarding through hardware logic, supporting near-line-speed performance. Hardware alignment constraints refer to the inherent operational granularity limitations determined by the chip's underlying physical design (such as bus width, register bit width, and data path architecture). All data reading, writing, and processing must be performed in units of fixed byte lengths (defined as the first byte length, such as 4 bytes or 8 bytes, which are preset hardware parameters at the chip's factory) to avoid hardware processing conflicts or performance losses caused by byte misalignment. In other words, the role of hardware alignment constraints is to clarify the hardware alignment operation granularity of the programmable hardware forwarding chip; the byte length of the hardware alignment operation granularity is the first byte length.

[0081] For example, a programmable hardware forwarding chip includes data packet parsing rules designed based on hardware alignment constraints. The data packet parsing rules are dedicated parsing logic adapted to the hardware operation characteristics. They can be used to indicate the first option field (i.e., the byte range completely corresponding to the target option field) occupied by the target option field in the header extended option field, based on the length of the first byte and according to the option field truncation and concatenation method.

[0082] In one embodiment, based on the hardware alignment constraints of the programmable hardware forwarding chip, the header extension option field is parsed to obtain the parsing result, including the following steps 1.1-1.3: Step 1.1: Iteratively determine the i-th reference option field and detect the identifier of the target option field in the i-th reference option field.

[0083] Following the instructions of the data packet parsing rules, the i-th reference option field is determined sequentially from the header extended option field, and it is determined whether the i-th reference option field contains the identifier of the target option field, where i is a positive integer (i=1,2,3...) representing the current parsing iteration number.

[0084] The identifier of an option field is a unique characteristic value used to identify that option field. It is usually the first byte of the option field, such as the "Kind" field value defined in the TCP protocol options: Kind=2 for the MSS option field, Kind=4 for the SACK option field, etc. During the parsing process, it is necessary to first check whether the starting byte (or specified position) of the i-th reference option field matches the identifier of the target option field to determine whether the target option field has been matched.

[0085] The i-th reference option field refers to the "baseline option field" used for iteratively locating the target option field during the parsing process. It is the smallest option unit used for identification and detection, divided according to hardware rules. Its determination rules must follow hardware alignment constraints, as follows: (1) i=1: The i-th reference option field is the byte range occupied by the first option field in the header extended option field (i.e., the first complete option field starting from the beginning of the header extended option field); (2) i>1 and there are remaining bytes after the (i-1)th reference option field is truncated: When the length of the (i-1)th reference option field is not an integer multiple of the length of the first byte, the truncation operation will produce remaining bytes that are less than the length of the first byte (the number of remaining bytes < the length of the first byte). At this time, the i-th reference option field is formed by concatenating "the remaining bytes" with "the next option field of the (i-1)th reference option field in the header extended option field" (supports both logical concatenation and physical concatenation). (3) i>1 and there are no remaining bytes after the (i-1)th reference option field is truncated: When the length of the (i-1)th reference option field is an integer multiple of the length of the first byte, there are no remaining bytes after the truncation operation. In this case, the i-th reference option field is directly the complete byte range occupied by the next option field of the (i-1)th reference option field in the header extended option field.

[0086] In one embodiment, the programmable hardware forwarding chip integrates a pre-buffer and a message buffer. The message buffer can be a large-capacity on-chip buffer or a large-capacity off-chip buffer, used to completely store the received first data packet; the pre-buffer can be a small-scale on-chip high-speed SRAM buffer (typically 8 bytes, 16 bytes, 32 bytes, etc.), supporting a read-ahead mechanism and random access at any offset within the buffer, and can be used to temporarily buffer header extended option field data, reducing parser access latency. The process of determining the i-th reference option field from the header extended option field and detecting the identifier of the target option field may include the following operations: (1) The header extended options field is loaded into the front buffer: For example, header extension option fields stored in the packet buffer can be read into the front buffer. The starting position of the header extension option fields in the first data packet can be calculated using the length field and data offset field of the fixed header (such as the Ethernet header or IPv4 header). Programmable hardware forwarding chips can implement data loading in the following three ways: Hardware prefetching method: The chip's internal dedicated prefetching engine automatically triggers the loading operation based on the message arrival signal before the parser starts parsing. The prefetching engine reads consecutive bytes in batches from the beginning of the header extended option field, using the length of the first byte as the unit, and writes them to the pre-buffer to ensure that the data required when the parser starts is ready, achieving wait-free access; DMA (Direct Memory Access) data transfer method: Data transfer is completed independently without consuming the parser's computing resources through the chip's built-in DMA controller. The DMA controller directly moves the specified range of option field data into the front buffer according to the preset source address (the starting address of the header extended option field in the message buffer), destination address (the starting address of the front buffer), and transfer length, achieving asynchronous and efficient data loading; The parser actively reads data in the following way: The parser (a functional device in a programmable hardware forwarding chip used to perform the packet parsing stage) dynamically initiates a read request to the packet buffer based on the current parsing progress. It reads the header extension option field data required for the next stage into the pre-buffer before performing parsing, thus improving the flexibility of data reading.

[0087] The advantage of a front buffer is that it supports random reading of data already loaded in the cache at any offset. The parser can directly access bytes at any position in the cache without having to read them sequentially from the beginning, providing low-latency support for iterative traversal of option fields.

[0088] (2) Identifier for prefetching the next option field: After the aforementioned data loading is complete, the identifier of the next option field of the (i-1)th reference option field is pre-fetched from the pre-buffer. Here, "pre-fetching" refers to the process where the programmable hardware forwarding chip directly locates the address and reads the data through dedicated logic circuits, without waiting for the parser to complete the current field processing. This is a pipelined operation that can further reduce parsing latency. The pre-fetching logic is as follows: i=1: The (i-1)th reference option field does not exist. The "next option field" is the first option field of the header extended option field, and its starting position is the starting address of the front buffer (which is consistent with the starting position of the header extended option field). i>1: Based on the end position of the (i-1)th reference option field recorded in the previous parsing process (calculated from the start address + total length), directly determine the start position of the next option field = the end address of the (i-1)th reference option field + 1 (unit: byte offset).

[0089] Since the identifier of the option field (such as the Kind value) is usually located in the first byte of the option field, the programmable hardware forwarding chip can read 1 byte of data from the starting position determined above in the front buffer. This byte is the "identifier of the next option field".

[0090] (3) Reference option field determination and identifier matching judgment: If the identifier of the pre-read next option field matches the identifier of the target option field, then the i-th reference option field is determined based on the next option field, and it is determined that the i-th reference option field contains the identifier of the target option field. If the identifier of the pre-read next option field does not match the identifier of the target option field, then the i-th reference option field is determined based on the next option field, and it is determined that the i-th reference option field does not contain the identifier of the target option field.

[0091] The following examples illustrate how the i-th reference option field is determined, broken down by scenario: Scenario 1: i=1 (first reference option field): The starting position of the first option field in the front buffer is equal to the starting address of the header extended option field (which has been synchronized to the front buffer via data loading). The parser can read the "Length" field of the option field from this starting position (such as the 1-byte Length value immediately following the Kind field in TCP options, used to identify the total byte length of the option field, including the Kind and Length fields themselves). The total length of the first option field (i.e., Length bytes) is calculated based on the value of the Length field. The first reference option field is defined as a continuous byte range in the front buffer from "starting position to starting position + total length - 1", which completely covers the entire content of the first option field.

[0092] Scenario 2: i > 1 and there are remaining bytes after truncating the (i-1)th reference option field (which need to be concatenated): This scenario supports two splicing methods, as detailed below: Method 1: Logical concatenation (low hardware overhead) Assume that the length of the (i - 1)-th reference option field is L, and the parser truncates it according to the first-byte length K (the purpose of truncation is to adapt to hardware alignment constraints and ensure that the processed data is an integer multiple of K). The remaining number of bytes r = L % K (where r > 0 and r < K). The programmable hardware forwarding chip can record the logical interval corresponding to the remaining bytes in the way of "address offset + length marker" (that is, record the start address of the remaining bytes = the start address of the (i - 1)-th reference option field + (L - r), and the length = r bytes); at the same time, determine the start logical address of the next option field of the (i - 1)-th reference option field = the end address of the (i - 1)-th reference field + 1, and read the Length field of this next option field to determine its corresponding logical interval (start address + its own length); logically splice the "logical interval corresponding to the remaining bytes" and the "logical interval corresponding to the next option field" to form a continuous logical address interval, and this interval is the i-th reference option field. The entire splicing process can maintain the logical addresses and length information of the two segments of data only through hardware registers, without performing any physical movement, shifting, or recombination operations on the packet data, and relying on address mapping to achieve "logical continuous access".

[0093] Method 2: Physical splicing (can be used as an alternative) Assume that the length of the (i - 1)-th reference option field is L, and the remaining number of bytes after truncation according to the first-byte length K is r = L % K (r > 0 and r < K); the programmable hardware forwarding chip can temporarily store these r remaining bytes in a dedicated hardware temporary register (this register can be an on-chip high-speed storage block for temporarily caching misaligned bytes to avoid occupying the space of the front buffer); the parser can find the next option field of the (i - 1)-th reference option field through address offset (its start position = the end address of the (i - 1)-th reference field + 1); read the Length field of the next option field from this start position to determine its total number of bytes; physically splice the "remaining bytes r" temporarily stored in the hardware temporary register and the "complete data of the next option field" (read according to the number of bytes specified by the Length field) in sequence to form a continuous physical data, and the byte interval corresponding to this data is the i-th reference option field, and its total length = r + the length of the next option field.

[0094] If every 4 bytes is used as a reference option field, and the identifier of the target option field is checked segment by segment, the target option field is prone to being distributed across 4-byte boundaries due to the variable-length format of TCP option fields. This can lead to problems such as segmentation errors, data incompleteness, abnormal recognition logic, and even hardware processing logic crashes. For example, the type, length, or data fields of the MSS option field, SACK option field, or timestamp option field may fall into two adjacent 4-byte reference option fields. Without concatenation, the programmable hardware forwarding chip may fail to fully recognize the target option field or incorrectly identify non-target fields as target option fields, resulting in packet parsing errors and field modification failures. Therefore, concatenation can ensure the data integrity, format alignment, and lack of loss of key information in the target option field. It also solves the parsing anomalies caused by segmented, incomplete, and cross-segment storage of option fields under the fixed 4-byte alignment granularity of hardware, ensuring that the programmable hardware forwarding chip can accurately recognize and process the target option field.

[0095] Scenario 3: i > 1 and there are no remaining bytes after truncating the (i-1)th reference option field (no concatenation required): The parser locates the next option field of the (i-1)th reference option field by address offset (starting position = ending address of the (i-1)th reference field + 1); reads the Length field of the next option field from this starting position and calculates its total length; the i-th reference option field is defined as the continuous byte range in the pre-buffer from "the starting position of the next option field to the starting position + total length - 1", which is the complete content of the next option field, without any concatenation operation.

[0096] Step 1.2: Processing logic for the i-th reference option field hitting the target option field: If the i-th reference option field contains the identifier of the target option field, then the first option field occupied by the target option field in the i-th reference option field (i.e., the complete byte range of the target option field, including the identifier, length, and data fields) is added to the parsing result.

[0097] For example, when there is a preceding byte before the target option field in the i-th reference option field, the preceding byte refers to the byte in the i-th reference option field that is before the target option field identifier. It is usually composed of the remaining bytes concatenated from the preceding byte. The third option field needs to be determined based on the option field occupied by this preceding byte. The byte length of the third option field is defined as the length of the second byte, and the length of the second byte is less than the length of the first byte (because the preceding byte is a non-aligned remaining byte, it is less than K). This third option field can be added to the parsing result to ensure that the parsing result completely contains all valid data before the target option field.

[0098] Step 1.3, Logic for handling cases where the target option field was not matched: If the i-th reference option field does not contain the identifier of the target option field, then the i-th reference option field is truncated in units of the first byte length K (the length of the truncated data is an integer multiple of K, which meets the hardware alignment constraints). The byte range obtained after truncation is defined as the second option field (its byte length = the first byte length K). The second option field is added to the parsing result (to retain the processed non-target option data). Then, i = i + 1 (the iteration number is incremented), and the operation of "determining the i-th reference option field and detecting the identifier of the target option field in the i-th reference option field" is re-executed until the entire header extended option field is traversed or the target option field is hit.

[0099] In one embodiment, the programmable hardware forwarding chip may include a counter for the first data packet. This counter is a programmable counting unit (a hardware module capable of implementing counting logic) allocated to the first data packet within the programmable hardware forwarding chip, used to monitor the parsing progress of the header extended option fields. The counter for the first data packet is set with a preset length threshold, equal to the length of the header extended option fields. This preset length threshold indicates the total number of bytes in the header extended option fields within the first data packet and can serve as a basis for determining parsing termination. The length of the third byte of the option fields added to the parsing result can be obtained. The third byte length refers to the actual byte length of the option fields added to the parsing result each time. For example, when the first option field is added to the parsing result, the third byte length is equal to the byte length of the target option field; when the second option field is added to the parsing result, the third byte length is equal to the first byte length; and when the third option field is added to the parsing result, the third byte length is equal to the second byte length. The length of the parsed bytes in the counter of the first data packet is increased by the third byte length. The length of parsed bytes is a dynamically recorded value by a counter, initially set to 0. Each time an option field (first, second, or third option field) is added to the parsing result, the byte length of that option field (i.e., the length of the third byte) is incremented. If the incremented length of parsed bytes equals the preset length threshold in the counter of the first datagram, it means that all bytes of the header extended option field have been traversed, and the target option field has not yet been found. Therefore, it is determined that the target option field does not exist in the header extended option field, and the step of determining the i-th reference option field from within the header extended option field is stopped. This is an automatic determination of the "traversal boundary" at the hardware level, requiring no software intervention and ensuring parsing efficiency.

[0100] In one embodiment, the programmable hardware forwarding chip includes a header buffer containing multiple storage blocks, each with a length of one byte. The physical form of the storage blocks is derived from the storage architecture design of the programmable hardware forwarding chip. For example, if the total size of the header buffer is 64 bytes and the length of the first byte is K = 4 bytes, then it can be divided into 16 storage blocks (64 ÷ 4 = 16), each storage block being 4 bytes in size and independently addressed (e.g., the address of the first storage block in the header buffer is 0x00-0x03, the address of the second storage block in the header buffer is 0x04-0x07, and so on). It is evident that each storage block has aligned boundaries (starting address is an integer multiple of K), a fixed size (all K bytes), and independent addressing (accessed via block number or base address + offset). The programmable hardware forwarding chip includes parsing result storage rules designed based on hardware alignment constraints. These parsing result storage rules are used to record the storage blocks allocated to each data structure in the header data structure definition. In other words, the physical partitioning of the storage block is merely a "blank container," and its functional definition (what parsing results to store) can be achieved through a logical mapping between the parsing result storage rules and the header data structure definition. In the firmware or configuration of the programmable hardware forwarding chip, three types of data structures can be declared through the header data structure definition, each corresponding to one of the three parsing results. For example, the header data structure definition may include: a first data structure in units of the target option field's byte length, used to extract and store the first option field (the target option field itself); a second data structure in units of the first byte length, used to extract and store the second option field (aligned truncation field, fixed length = K); and a third data structure in units of the second byte length, used to extract and store the third option field (preceding short byte field, shorter than K). For example, the `my_headers_t` code in the above example contains 10 second data structures, one 2-byte third data structure, one 1-byte third data structure, and one MSS as the first data structure for the target option field. The parsing result storage rules are one of the configurations of the programmable hardware forwarding chip, recording the "binding relationship between data structures and storage blocks." For example, when the header data structure definition is compiled into the programmable hardware forwarding chip, a storage block can be statically allocated in the header buffer for each data structure in the header data structure definition. For instance, 10 second data structures tcp_option_4byte_h (4 bytes) can be allocated to the 1st to 10th storage blocks in the header buffer respectively; the third data structure tcp_option_2byte_h (2 bytes) can be allocated to the 11th storage block in the header buffer; the third data structure tcp_option_1byte_h (1 byte) can be allocated to the 12th storage block in the header buffer; and the first data structure tcp_option_mss_h (4 bytes) can be allocated to the 13th storage block in the header buffer.The correspondence between "data structure type → memory block address or memory block number" can be recorded through hardware registers or configuration tables (such as TCAM (Ternary Content Addressable Memory Entry) entries) for direct lookup by programmable hardware forwarding chips.

[0101] Adding a first option field to the parsing result includes: storing the first option field in a storage block allocated for the first data structure in the header cache according to the parsing result storage rules; for example, this storage block can be marked as valid. Adding a second option field to the parsing result includes: storing the second option field in a storage block allocated for the second data structure in the header cache according to the parsing result storage rules; for example, this storage block can be marked as valid. Adding a third option field to the parsing result includes: storing the third option field in a storage block allocated for the third data structure in the header cache according to the parsing result storage rules; for example, this storage block can be marked as valid.

[0102] Marking a block as valid means using a status bit (such as a "valid bit") or a flag field to indicate that a valid parsing result has been stored in the memory block. This avoids reading invalid data during subsequent processing (such as modification, verification, and recalculation). For example, a programmable hardware forwarding chip can equip each memory block with a 1-bit status register (called a "valid bit register") to mark whether the memory block is valid (e.g., a value of 1 indicates that it is valid).

[0103] Therefore, the parsing result storage rule can statically bind "data structure type → storage block address". The programmable hardware forwarding chip can directly access the data in the header buffer without dynamically calculating the offset (the software program needs to traverse byte by byte to find the address), which greatly reduces the access latency. The header data structure definition can cover the total length of all possible option fields before the target option field through "multi-type data structure combination", so that there is no need to reserve a large unit for the total length of each possible option field, and it can parse header extended option fields of arbitrary byte length. At the same time, this application can fill the storage block with the second option field (that is, the space utilization of the storage block reaches 100%), and when traversing to the target option field, through the padding mechanism, the third option field is used to adapt the non-aligned or short byte length of the preceding byte before the target option field, and the target option field itself (the first option field) is stored in a dedicated storage block to achieve non-redundant, hardware-aligned storage of variable-length option fields.

[0104] Please see Figure 5 This is a flowchart illustrating a data packet parsing method provided in an embodiment of this application. The following description uses the target option field as the MSS option field, with the first byte being 4 bytes long, to illustrate the parsing process of the header extended option field. This parsing process includes: 1. Initialize parsing parameters. For example, set the current option type_cur in the first reference option field to the option type of the first option field in the header extended option field, the current option length len_cur to the byte length of the first option field in the header extended option field, and initialize the parsed byte length to 0. The preset length threshold is the total length of the header extended option field.

[0105] 2. Enter the loop process, obtain the current option type_cur in the i-th reference option field, and determine whether type_cur is an MSS option type.

[0106] 3. If the current option type_cur is an MSS option type, extract the MSS option field and the preceding short byte field (byte length less than 4 bytes) into the parsing result to complete the accurate extraction and parsing of the MSS option field.

[0107] 4. If the current option type_cur is not an MSS option type, the i-th reference option field is truncated in 4-byte units, the aligned truncated field (4 bytes in length) is extracted into the parsing result, and the parsed byte length in the counter is updated to complete the parsing and length statistics of the current non-MSS option.

[0108] 5. Determine whether the length of the parsed bytes is equal to the preset length threshold.

[0109] 6. If the length of the parsed bytes is equal to the preset length threshold, the parsing process ends, and all bytes of the header extended option field are parsed.

[0110] 7. If the length of the parsed bytes is not equal to the preset length threshold, then continue to obtain the type_next and length len_next of the next option field of the i-th reference option field.

[0111] 8. Update the current option type_cur to type_next, update the current option length len_cur to len_cur=len_cur%4 (remaining bytes)+len_next, and execute the above steps to obtain the current option type_cur in the i-th reference option field and determine whether type_cur is an MSS option type, until the parsed byte length reaches the preset length threshold or the target option field is extracted.

[0112] As can be seen, the extraction mechanism of aligned truncation fields can avoid unaligned memory access, so that programmable hardware forwarding chips do not need to perform byte shifting and masking operations, eliminating pipeline pauses and meeting pipeline timing requirements. At the same time, the design of an independent MSS option parsing branch can accurately capture the preceding short byte field and the MSS field body, without destroying the semantics of the header extended option field. By cooperating with the aligned truncation processing, a balance can be achieved between lossless parsing of critical fields and efficient processing of non-critical fields.

[0113] Byte shifting refers to the process of shifting unaligned data left or right at the byte level using logic circuits to adjust the position of fields to meet the alignment requirements of subsequent processing (such as parsing and matching). Suppose an option field starts at address 0x03 (1-byte offset) and has a length of 2 bytes (0x03-0x04). Since 0x03 is not a 4-byte aligned address (the nearest 4-byte aligned address is 0x00 or 0x04), the 4 bytes of data containing the option field (such as 0x00-0x03 and 0x04-0x07) will be retrieved. Then, the shifting circuit will extract 1 byte from address 0x03 and 1 byte from address 0x04, concatenating them into a complete 2-byte option field. Masking is a follow-up processing step after byte shifting. It involves using a logical AND operation to filter out bytes of non-desirable option fields, retaining only the valid field content. Both byte shifting and masking operations are multi-cycle combinational logic operations. When the hardware pipeline waits for the shifting and masking of unaligned data to complete, subsequent packet parsing must be paused, causing pipeline stalls. Pipeline stalls directly lead to a decrease in the number of packets processed per unit time and an increase in forwarding latency. In high-throughput scenarios, this can significantly reduce line-rate forwarding capabilities, failing to meet the high-performance forwarding requirements of backbone networks and data centers.

[0114] S43. When it is determined that the target option field meets the modification conditions, the target option field is modified, and the first data packet is updated based on the modified target option field to obtain the second data packet.

[0115] The first data packet contains a fixed header, which may include an Ethernet header, an IPv4 header, and a TCP header. This fixed header includes a checksum field used to verify packet integrity; the checksum must be recalculated after any changes to the packet fields. A programmable hardware forwarding chip can parse the first data packet starting from its beginning position. In this case, the fixed header in the first data packet can be parsed and stored in the header buffer. For example, the `my_headers_t` code mentioned above can implement the standardized extraction and storage logic for the fixed header consisting of the Ethernet header, IPv4 header, and TCP header.

[0116] Please see Figure 6This is a flowchart illustrating a message reassembly method provided in an embodiment of this application. The following is a summary of the process. Figure 6 The process of generating the second data message is explained.

[0117] In one embodiment, when it is determined that the target option field meets the modification conditions, the target option field is modified, and the first data packet is updated based on the modified target option field to obtain the second data packet, including the following steps 2.1-2.2: Step 2.1: When it is determined that the target option field meets the modification conditions, modify the target option field and recalculate the checksum field based on the modified target option field.

[0118] Programmable hardware forwarding chips can contain a matching action table for target option fields. This matching action table is a built-in rule base (such as ACL rules) of the programmable hardware forwarding chip. The matching action table contains at least one matching rule and a corresponding modification action rule for each matching rule. The matching rule acts as a "modification trigger scenario determiner," and the effective conditions of the modification action rule can be precisely controlled through header protocol fields. The modification action rule refers to the field parameter configuration rule that corresponds one-to-one with the matching rule, explicitly specifying the standard parameter values ​​that the target option field should update, providing a unified reference for field modification. When it is determined that the target option field meets the modification conditions, the target option field is modified. This may include: extracting header protocol fields from the fixed header in the header buffer. Header protocol fields are key fields used to identify packet transmission characteristics and determine packet processing strategies; for example, header protocol fields may include, but are not limited to: source IP address, destination IP address, source port, destination port, protocol number, tunnel identifier, etc. By extracting header protocol fields, the transmission link and service type to which the packet belongs can be accurately matched, providing a reliable basis for the matching determination and parameter modification of the target option field. The target matching rule for the header protocol field is determined from the matching action table. Based on the modification action rule corresponding to the target matching rule, the recommended field parameters for the target option field are determined. The target matching rule refers to the matching rule selected from the matching action table built into the programmable hardware forwarding chip that matches the extracted header protocol field features. For example, when the actual value of the header protocol field extracted by the chip (e.g., protocol number = 6 (TCP), source port = 80 (HTTP)) meets all the conditions of a certain matching rule in the matching action table (e.g., the matching rule is "protocol number = 6 and source port = 80"), then that matching rule is determined as the target matching rule. The recommended field parameters for the target option field are parameter values ​​set for the target option field based on preset conditions such as network transmission optimization requirements, link bandwidth limitations, and protocol standard specifications. These parameter values ​​are verified by the system to ensure the stability and efficiency of packet transmission. The actual field parameters of the target option field are obtained from the header buffer. The actual field parameters refer to the field parameters (i.e., the Data content) of the target option field in the first data packet. If the recommended field parameters of the target option field do not match the actual field parameters of the target option field, then the target option field is determined to meet the modification conditions. For example, if the target option field is an MSS option field, and the recommended field parameter of the target option field is less than the actual field parameter of the target option field, then the target option field meets the modification conditions. Similarly, if the target option field is a SACK option field, and the recommended field parameter is "Disable SACK function," while the actual field parameter is "Enable SACK function," then the modification conditions are met. In this case, the actual field parameter of the target option field in the header cache can be updated to the recommended field parameter of the target option field.

[0119] In one embodiment, recalculating the checksum field based on the modified target option field includes: obtaining the actual field parameters of the target option field and the actual field parameters of the checksum field (i.e., the field parameters of the checksum field in the first data packet, i.e., the Data content) from the header buffer. The difference between the actual field parameters of the checksum field and the actual field parameters of the target option field is calculated to obtain the intermediate field parameters of the checksum field; that is, the intermediate field parameters of the checksum field = the actual field parameters of the checksum field - the actual field parameters of the target option field. If the actual field parameters of the target option field in the header buffer are updated to the recommended field parameters of the target option field, the recommended field parameters of the target option field and the intermediate field parameters of the checksum field are summed to obtain the recommended field parameters of the checksum field; that is, the recommended field parameters of the checksum field = the recommended field parameters of the target option field + the intermediate field parameters of the checksum field. The actual field parameters of the checksum field in the header buffer can be updated to the recommended field parameters of the checksum field.

[0120] Example illustrating hardware operation (using TCP MSS options as an example, first byte length = 4 bytes, hardware alignment constraint is 4-byte operation granularity): The programmable hardware forwarding chip can read the actual field parameters of the MSS option field (e.g., hexadecimal 0x05DC) from the header buffer; and read the actual field parameters of the checksum field (e.g., hexadecimal 0xABCD) from the header buffer. The programmable hardware forwarding chip performs difference calculation through the ALU (Arithmetic and Logic Unit): the intermediate field parameter of the checksum field = 0xABCD - 0x05DC = 43981 - 1500 = 42481 (hexadecimal 0xA651). When the target option field is updated to the recommended field parameters (e.g., hexadecimal 0x05B4), the programmable hardware forwarding chip again performs summation through the ALU: the recommended field parameter of the checksum field = 0xA651 + 0x05B4 = 42481 + 1460 = 43941 (hexadecimal 0xAC05). The programmable hardware forwarding chip can update the actual value (0xABCD) of the checksum field in the header buffer to the recommended value (0xAC05) to complete the recalculation.

[0121] This application can utilize the incremental checksum calculation capability provided by the programmable hardware forwarding chip to update the checksum field without recalculating the entire message checksum. Instead, it achieves efficient updates through "differential adjustment," which can effectively improve message processing efficiency.

[0122] Step 2.2: Based on the modified target option field and the recalculated checksum field, update the first data packet to obtain the second data packet.

[0123] After modifying the target option field and recalculating the checksum field, the header buffer of the programmable hardware forwarding chip contains a fixed header after recalculating the checksum field, the modified target option field, and option fields (such as the second and third option fields) in the header extended option fields preceding the target option field. Simultaneously, the packet buffer of the programmable hardware forwarding chip stores the first data packet. In one embodiment, updating the first data packet based on the modified target option field and the recalculated checksum field to obtain the second data packet may include: retrieving the fixed header after recalculating the checksum field, the modified target option field, and option fields in the header extended option fields preceding the target option field from the header buffer. For example, the programmable hardware forwarding chip can read these data in parallel from the header buffer by parsing the result storage rules and using a static binding relationship of "data structure type → storage block address". The content fields following the target option field in the first data packet are read from the packet buffer. For example, the programmable hardware forwarding chip can read the content fields following the target option field in DMA burst transfer mode using the base address of the packet buffer plus the end offset of the target option field, avoiding byte-by-byte access. The second data packet is assembled based on the fixed header after recalculating the checksum field, the modified target option field, the option field in the header extended option field preceding the target option field, and the content field in the first data packet following the target option field. For example, a programmable hardware forwarding chip (its de-parser, used for packet reassembly and transmission) can write these four parts of data into the output buffer of the packet buffer in the order of the original packet structure, ensuring that the assembled packet meets hardware forwarding requirements. The entire process is pipelined in parallel without software intervention. The output buffer can be a dedicated sub-region within the packet buffer.

[0124] Therefore, this solution achieves efficient processing of data packets containing variable-length header extension option fields through a programmable hardware forwarding chip. It centers on a streamlined, collaborative process of "parsing-storage-modification-verification-assembly under hardware alignment constraints," transforming the variable-length protocol structure into a fixed sequence of hardware-executable operations to achieve near-line-speed forwarding performance. The parsing result storage mechanism (classified data structure + static address mapping) improves storage utilization, avoiding the space waste of traditional solutions. Dynamic modification and efficient verification of target option fields are achieved through a matching action table and incremental checksum recalculation (difference-summation algorithm), reducing computational overhead. Simultaneously, complex tasks such as data parsing and modification are offloaded to hardware, significantly reducing CPU load and ensuring stable operation of the device's control and management planes. This approach balances protocol flexibility with high hardware performance, overcomes software processing performance bottlenecks, and meets the demands of modern networks for high throughput, low latency, and high scalability.

[0125] The methods of the embodiments of this application have been described in detail above. In order to facilitate better implementation of the above methods of the embodiments of this application, the apparatus of the embodiments of this application is provided below.

[0126] Please see Figure 7 This is a schematic diagram of a data packet processing apparatus provided in an embodiment of this application. The data packet processing apparatus includes: The message parsing unit 71 is used to obtain the first data packet received by the network device. The first data packet includes a header extension option field, which is an option field with variable length and non-fixed structure. The message parsing unit 71 is also used to parse the header extension option field based on the hardware alignment constraints of the programmable hardware forwarding chip, and obtain the parsing result, which includes the target option field in the header extension option field. The reassembly unit 72 is used to modify the target option field when it is determined that the target option field meets the modification conditions, and update the first data packet based on the modified target option field to obtain the second data packet.

[0127] In one embodiment, the programmable hardware forwarding chip includes data packet parsing rules designed based on hardware alignment constraints. The hardware alignment constraints are used to indicate that the byte length of the hardware alignment operation granularity of the programmable hardware forwarding chip is a first byte length. The data packet parsing rules are used to indicate that the first option field occupied by the target option field is located from the header extended option field based on the first byte length and according to the option field truncation and splicing method. The message parsing unit 71 parses the header extension option field based on the hardware alignment constraints of the programmable hardware forwarding chip, and obtains the parsing result, including: According to the instructions of the data packet parsing rules, determine the i-th reference option field from the header extended option field, and determine whether the i-th reference option field contains the identifier of the target option field, where i is a positive integer; If the i-th reference option field contains the identifier of the target option field, then the first option field occupied by the target option field in the i-th reference option field is added to the parsing result; Wherein, if i=1, then the i-th reference option field is the option field occupied by the first option field in the header extended option field; if i>1, and there are remaining bytes after the i-1 reference option field is truncated in units of the first byte length, then the i-th reference option field is the option field obtained by concatenating the remaining bytes and the next option field of the i-1 reference option field in the header extended option field; if i>1, and there are no remaining bytes after the i-1 reference option field is truncated in units of the first byte length, then the i-th reference option field is the option field occupied by the next option field of the i-1 reference option field in the header extended option field.

[0128] In one embodiment, the message parsing unit 71 is further configured to: If the i-th reference option field does not contain the identifier of the target option field, then the i-th reference option field is truncated in units of the first byte length to obtain the second option field in the header extended option field that is located before the target option field. The second option field is then added to the parsing result; the byte length of the second option field is the same as the length of the first byte. Let i = i + 1, and execute the step of determining the i-th reference option field from the extended option field in the header.

[0129] In one embodiment, the message parsing unit 71 is further configured to: When there is a preceding byte before the target option field in the i-th reference option field, the third option field in the header extended option field is determined based on the option field occupied by the preceding byte. The byte length of the third option field is the length of the second byte, and the length of the second byte is less than the length of the first byte. Add the third option field to the parsing result.

[0130] In one embodiment, the programmable hardware forwarding chip further includes a front buffer and a message buffer, wherein the first data packet is stored in the message buffer; The message parsing unit 71 determines the i-th reference option field from the header extended option field, and determines whether the i-th reference option field contains the identifier of the target option field, including: Read the header extended option fields from the message buffer into the front buffer; Pre-read the identifier of the next option field of the (i-1)th reference option field in the pre-buffer; If the identifier of the next option field of the (i-1)th reference option field is the identifier of the target option field, then the i-th reference option field is determined based on the next option field of the (i-1)th reference option field, and it is determined that the i-th reference option field contains the identifier of the target option field.

[0131] In one embodiment, the message parsing unit 71 is further configured to: If the identifier of the next option field of the (i-1)th reference option field is not the identifier of the target option field, then the i-th reference option field is determined based on the next option field of the (i-1)th reference option field, and it is determined that the i-th reference option field does not contain the identifier of the target option field.

[0132] In one embodiment, the programmable hardware forwarding chip further includes a counter for the first data packet, the counter for the first data packet being set with a preset length threshold, the preset length threshold being equal to the length of the header extension option field; the packet parsing unit 71 is further configured to: Get the length of the third byte of the option field added to the parsed result; Increase the length of the parsed bytes in the counter of the first data packet by the length of the third byte; If the length of the parsed bytes after the increase is equal to the preset length threshold in the counter of the first data packet, it is determined that there is no target option field in the header extension option field, and the step of determining the i-th reference option field from the header extension option field is stopped.

[0133] In one embodiment, the programmable hardware forwarding chip includes a header buffer containing multiple storage blocks of a first byte length; the programmable hardware forwarding chip includes a parsing result storage rule designed based on hardware alignment constraints, the parsing result storage rule being used to record the storage blocks allocated to each data structure in the header data structure definition; the header data structure definition includes a first data structure of a target option field in bytes, a second data structure of a first byte length, and a third data structure of a second byte length. The message parsing unit 71 adds the first option field to the parsing result, including: storing the first option field in the storage block allocated for the first data structure in the header buffer according to the parsing result storage rules; The message parsing unit 71 adds the second option field to the parsing result, including: storing the second option field in the storage block allocated for the second data structure in the header buffer according to the parsing result storage rules; The message parsing unit 71 adds the third option field to the parsing result, including: storing the third option field in the storage block allocated for the third data structure in the header buffer according to the parsing result storage rules.

[0134] In one embodiment, the first data message further includes a fixed header, which includes a checksum field; When the reassembly unit 72 determines that the target option field meets the modification conditions, it modifies the target option field and updates the first data packet based on the modified target option field to obtain the second data packet, including: When the target option field is determined to meet the modification conditions, the target option field is modified, and the checksum field is recalculated based on the modified target option field. Based on the modified target option field and the recalculated checksum field, the first data packet is updated to obtain the second data packet.

[0135] In one embodiment, the programmable hardware forwarding chip further includes a matching action table for the target option field. The matching action table contains at least one matching rule and a modification action rule corresponding to each matching rule. The first data packet also includes a fixed header. The programmable hardware forwarding chip includes a header buffer, which stores the fixed header and the target option field. When the recombination unit 72 determines that the target option field meets the modification conditions, it modifies the target option field, including: Extract the header protocol fields from the fixed header from the header buffer; Determine the target matching rule that the header protocol field conforms to from the matching action table, and determine the recommended field parameters of the target option field based on the modification action rule corresponding to the target matching rule; Retrieve the actual field parameters of the target option field from the header cache; If the recommended field parameter of the target option field does not match the actual field parameter of the target option field, then the target option field is determined to meet the modification conditions, and the actual field parameter of the target option field in the header cache is updated to the recommended field parameter of the target option field.

[0136] In one embodiment, the programmable hardware forwarding chip includes a header buffer that stores a fixed header and a target option field. The recombination unit 72 is modified to recalculate the checksum field based on the modified target option field, including: Retrieve the actual field parameters of the target option field and the actual field parameters of the checksum field from the header cache; The difference between the actual field parameter of the checksum field and the actual field parameter of the target option field is calculated to obtain the intermediate field parameter of the checksum field; If the actual field parameter of the target option field in the header cache is updated to the recommended field parameter of the target option field, then the recommended field parameter of the target option field and the intermediate field parameter of the checksum field are summed to obtain the recommended field parameter of the checksum field. Update the actual field parameters of the checksum field in the header cache to the recommended field parameters of the checksum field.

[0137] In one embodiment, the programmable hardware forwarding chip includes a header buffer containing a fixed header after recalculating the checksum field, a modified target option field, and an option field in the header extended option field that precedes the target option field. The programmable hardware forwarding chip also includes a message buffer where the first data packet is stored. The reassembly unit 72 updates the first data packet based on the modified target option field and the recalculated checksum field to obtain the second data packet, including: Retrieve the fixed header after recalculating the checksum field from the header cache, the modified target option field, and the option field in the header extended option field that precedes the target option field; Read the content field following the target option field from the first data packet from the message buffer; The second data packet is assembled based on the fixed header after the recalculated checksum field, the modified target option field, the option field in the header extended option field before the target option field, and the content field in the first data packet after the target option field.

[0138] According to one embodiment of this application, Figure 7 The data packet processing apparatus shown can be constructed by combining each unit into one or more other units, or by further dividing one or more units into functionally smaller units. This achieves the same operation without affecting the technical effect of the embodiments of this application. In other embodiments of this application, the data packet processing apparatus may also include other units. In practical applications, these functions can also be implemented with the assistance of other units, and can be implemented by multiple units working together. According to another embodiment of this application, a computer program (including program code) capable of performing the steps involved in the corresponding methods described above can be run on a computer device (such as a network device including processing elements and storage elements such as programmable hardware forwarding chips, random access storage media, and read-only storage media) to construct a device such as... Figure 7 The data packet processing apparatus shown herein, and the model-based data processing method described in the foregoing embodiments of this application, are described. The computer program may be recorded on, for example, a computer-readable storage medium, loaded onto the aforementioned computing device via the computer-readable storage medium, and executed therein.

[0139] Based on the same inventive concept, the principle and beneficial effects of the data packet processing device provided in the embodiments of this application are similar to the principle and beneficial effects of the data packet processing method in the embodiments of this application. For details, please refer to the principle and beneficial effects of the method implementation. For the sake of brevity, these will not be repeated here.

[0140] Please see Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The internal structure of the computer device 80 specifically includes one or more processors 81, a memory 82, and a communication interface 83. The processors 81, memory 82, and communication interface 83 can be interconnected through a bus 84 or other equivalent connection methods. This embodiment of the application illustrates the connection via a bus 84 as an example. This connection method has the characteristics of low transmission latency, high stability, and flexible expansion, and can adapt to the collaborative work needs of hardware components of different sizes.

[0141] The processor 81, serving as the core computing unit and global control core of the computer device 80, may include high-performance programmable hardware forwarding chips (such as application-specific integrated circuits (ASICs) and network processors (NPUs) with line-speed processing capabilities). These chips, through hardware-based pipelined architecture, parallel processing units, and dedicated protocol parsing modules, can overcome the performance bottlenecks of traditional general-purpose processors. Specifically, the processor 81 is responsible for efficiently executing a series of data processing-related methods, such as packet parsing, protocol identification, header modification, route lookup, and traffic forwarding, by calling hardware-specific computer programs (such as bitstream files compiled from the P4 programming language, customized forwarding rule tables, hardware microcode, and protocol parsing templates) pre-stored in the memory 82. During processing, it can dynamically schedule hardware resources according to business needs to ensure that the single-packet processing latency is controlled at the microsecond or even nanosecond level, meeting the line-speed forwarding requirements of high-speed links.

[0142] The memory 82 serves as the storage medium for the computer device 80. It can be used to store the computer programs, fixed protocol standard parameters, and preset configuration policies (such as security access control rules) that are dedicated to the aforementioned hardware. It can also cache various temporary data generated during operation, including but not limited to dynamically generated runtime forwarding tables, intermediate state information during message parsing, cached data of messages to be forwarded, temporary configuration values ​​of hardware registers, and traffic statistics. This provides data support for the high-speed operation of the processor 81 and avoids the impact of data read delays on overall processing efficiency. For example, the storage architecture of memory 82 can adopt a hierarchical design pattern of "built-in memory + extended memory": the built-in memory may include hardware-level storage units integrated in the programmable hardware forwarding chip (such as header buffer, front buffer, message buffer, etc.). This type of storage unit has the characteristics of fast access speed, low latency and direct connection to the processor bus. It can be used to store frequently accessed data (such as message header information, current parsing status, common forwarding rules, etc.) to ensure the high-speed data read and write requirements of the processor. The extended memory may include external storage modules supported by computer device 80 (such as high-speed solid-state drives, hard disk arrays, external memory cards, etc.). This type of storage device has the advantages of large storage capacity, low cost and scalability. It can be mainly used to store large-capacity computer programs, historical business data, log files, configuration backups and other non-frequently accessed data. In addition, the memory 82 can also provide independent storage space for deploying the network operating system, hardware drivers (such as communication interface drivers, bus drivers, chip firmware, etc.), device configuration files and temporary business data (such as session status information, traffic statistics logs, etc.) of the computer device 80. Its storage capacity and access speed can be flexibly configured according to the business needs of the actual application scenario, and this application does not limit them.

[0143] The communication interface 83, as a key interface component for data interaction between the computer device 80 and external networks and other devices, can receive input data packets from external networks and send the output data packets processed by the processor 81 to the target network or device, realizing bidirectional data transmission and communication between the computer device and external networks. The communication interface 83 can optionally include standard wired interfaces and wireless communication interfaces (such as Wi-Fi interfaces, Bluetooth interfaces, etc.), and supports adaptation and data transmission of various mainstream network communication protocols such as TCP, IP, and Ethernet. It has good compatibility and scalability, and can flexibly connect to different types of network topologies and communication scenarios.

[0144] Bus 84 serves as a communication bridge between various hardware components within computer device 80. It can be used to realize high-speed communication connections between processor 81, memory 82, and communication interface 83. It can not only transmit data information between components (such as message data, configuration data, statistical data, etc.), but also transmit control signals (such as start signals, interrupt signals, synchronization signals, etc.), ensuring the coordinated work and timing synchronization between processor 81, memory 82, and communication interface 83, guaranteeing the integrity, accuracy, and real-time performance of data transmission, and avoiding system performance bottlenecks caused by insufficient bus bandwidth or transmission delay.

[0145] For example, processor 81 can perform the following operations by running a computer program stored in memory 82: The first data packet received by the network device is obtained. The first data packet includes a header extension option field, which is an option field with variable length and non-fixed structure. Based on the hardware alignment constraints of the programmable hardware forwarding chip, the header extension option field is parsed to obtain the parsing result, which includes the target option field in the header extension option field. When the target option field is determined to meet the modification conditions, the target option field is modified, and the first data packet is updated based on the modified target option field to obtain the second data packet.

[0146] In one embodiment, the processor 81 parses the header extension option field based on the hardware alignment constraints of the programmable hardware forwarding chip to obtain the parsing result, including: According to the instructions of the data packet parsing rules, determine the i-th reference option field from the header extended option field, and determine whether the i-th reference option field contains the identifier of the target option field, where i is a positive integer; If the i-th reference option field contains the identifier of the target option field, then the first option field occupied by the target option field in the i-th reference option field is added to the parsing result; Wherein, if i=1, then the i-th reference option field is the option field occupied by the first option field in the header extended option field; if i>1, and there are remaining bytes after the i-1 reference option field is truncated in units of the first byte length, then the i-th reference option field is the option field obtained by concatenating the remaining bytes and the next option field of the i-1 reference option field in the header extended option field; if i>1, and there are no remaining bytes after the i-1 reference option field is truncated in units of the first byte length, then the i-th reference option field is the option field occupied by the next option field of the i-1 reference option field in the header extended option field.

[0147] In one embodiment, processor 81 is further configured to: If the i-th reference option field does not contain the identifier of the target option field, then the i-th reference option field is truncated in units of the first byte length to obtain the second option field in the header extended option field that is located before the target option field. The second option field is then added to the parsing result; the byte length of the second option field is the same as the length of the first byte. Let i = i + 1, and execute the step of determining the i-th reference option field from the extended option field in the header.

[0148] In one embodiment, processor 81 is further configured to: When there is a preceding byte before the target option field in the i-th reference option field, the third option field in the header extended option field is determined based on the option field occupied by the preceding byte. The byte length of the third option field is the length of the second byte, and the length of the second byte is less than the length of the first byte. Add the third option field to the parsing result.

[0149] In one embodiment, the programmable hardware forwarding chip further includes a front buffer and a message buffer, wherein the first data packet is stored in the message buffer; Processor 81 determines the i-th reference option field from the header extended option field, and determines whether the i-th reference option field contains the identifier of the target option field, including: Read the header extended option fields from the message buffer into the front buffer; Pre-read the identifier of the next option field of the (i-1)th reference option field in the pre-buffer; If the identifier of the next option field of the (i-1)th reference option field is the identifier of the target option field, then the i-th reference option field is determined based on the next option field of the (i-1)th reference option field, and it is determined that the i-th reference option field contains the identifier of the target option field.

[0150] In one embodiment, processor 81 is further configured to: If the identifier of the next option field of the (i-1)th reference option field is not the identifier of the target option field, then the i-th reference option field is determined based on the next option field of the (i-1)th reference option field, and it is determined that the i-th reference option field does not contain the identifier of the target option field.

[0151] In one embodiment, the programmable hardware forwarding chip further includes a counter for the first data packet, the counter for the first data packet being set with a preset length threshold, the preset length threshold being equal to the length of the header extension option field; the processor 81 is further configured to: Get the length of the third byte of the option field added to the parsed result; Increase the length of the parsed bytes in the counter of the first data packet by the length of the third byte; If the length of the parsed bytes after the increase is equal to the preset length threshold in the counter of the first data packet, it is determined that there is no target option field in the header extension option field, and the step of determining the i-th reference option field from the header extension option field is stopped.

[0152] In one embodiment, the programmable hardware forwarding chip includes a header buffer containing multiple storage blocks of a first byte length; the programmable hardware forwarding chip includes a parsing result storage rule designed based on hardware alignment constraints, the parsing result storage rule being used to record the storage blocks allocated to each data structure in the header data structure definition; the header data structure definition includes a first data structure of a target option field in bytes, a second data structure of a first byte length, and a third data structure of a second byte length. The processor 81 adds the first option field to the parsing result, including: storing the first option field in the storage block allocated for the first data structure in the header cache according to the parsing result storage rules; The processor 81 adds the second option field to the parsing result, including: storing the second option field in the storage block allocated for the second data structure in the header cache according to the parsing result storage rules; Processor 81 adds the third option field to the parsing result, including: storing the third option field in the storage block allocated for the third data structure in the header cache according to the parsing result storage rules.

[0153] In one embodiment, the first data message further includes a fixed header, which includes a checksum field; When processor 81 determines that the target option field meets the modification conditions, it modifies the target option field and updates the first data packet based on the modified target option field to obtain a second data packet, including: When the target option field is determined to meet the modification conditions, the target option field is modified, and the checksum field is recalculated based on the modified target option field. Based on the modified target option field and the recalculated checksum field, the first data packet is updated to obtain the second data packet.

[0154] In one embodiment, the programmable hardware forwarding chip further includes a matching action table for the target option field. The matching action table contains at least one matching rule and a modification action rule corresponding to each matching rule. The first data packet also includes a fixed header. The programmable hardware forwarding chip includes a header buffer, which stores the fixed header and the target option field. When processor 81 determines that the target option field meets the modification conditions, it modifies the target option field, including: Extract the header protocol fields from the fixed header from the header buffer; Determine the target matching rule that the header protocol field conforms to from the matching action table, and determine the recommended field parameters of the target option field based on the modification action rule corresponding to the target matching rule; Retrieve the actual field parameters of the target option field from the header cache; If the recommended field parameter of the target option field does not match the actual field parameter of the target option field, then the target option field is determined to meet the modification conditions, and the actual field parameter of the target option field in the header cache is updated to the recommended field parameter of the target option field.

[0155] In one embodiment, the programmable hardware forwarding chip includes a header buffer that stores a fixed header and a target option field. Processor 81 recalculates the checksum field based on the modified target option field, including: Retrieve the actual field parameters of the target option field and the actual field parameters of the checksum field from the header cache; The difference between the actual field parameter of the checksum field and the actual field parameter of the target option field is calculated to obtain the intermediate field parameter of the checksum field; If the actual field parameter of the target option field in the header cache is updated to the recommended field parameter of the target option field, then the recommended field parameter of the target option field and the intermediate field parameter of the checksum field are summed to obtain the recommended field parameter of the checksum field. Update the actual field parameters of the checksum field in the header cache to the recommended field parameters of the checksum field.

[0156] In one embodiment, the programmable hardware forwarding chip includes a header buffer containing a fixed header after recalculating the checksum field, a modified target option field, and an option field in the header extended option field that precedes the target option field. The programmable hardware forwarding chip also includes a message buffer where the first data packet is stored. Processor 81 updates the first data packet based on the modified target option field and the recalculated checksum field to obtain the second data packet, which includes: Retrieve the fixed header after recalculating the checksum field from the header cache, the modified target option field, and the option field in the header extended option field that precedes the target option field; Read the content field following the target option field from the first data packet from the message buffer; The second data packet is assembled based on the fixed header after the recalculated checksum field, the modified target option field, the option field in the header extended option field before the target option field, and the content field in the first data packet after the target option field.

[0157] Based on the same inventive concept, the principle and beneficial effects of the computer device provided in the embodiments of this application in solving the problem are similar to the principle and beneficial effects of the data packet processing method in the embodiments of this application in solving the problem. Please refer to the principle and beneficial effects of the implementation of the method. For the sake of brevity, they will not be repeated here.

[0158] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0159] This application also provides a computer-readable storage medium storing a computer program for the aforementioned data packet processing method. The computer program includes computer instructions. When one or more processors load and execute these computer instructions, the data packet processing method described in the embodiments can be implemented, and will not be repeated here. The beneficial effects of using the same method will also not be repeated here. It is understood that the computer instructions can be deployed on one or more computer devices capable of communicating with each other for execution.

[0160] The aforementioned computer-readable storage medium can be the data packet processing apparatus provided in the foregoing embodiments or the internal storage block of the aforementioned computer device, such as the hard disk or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium can include both internal storage blocks and external storage devices of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0161] This application also provides a computer program product, which includes a computer program or computer instructions, which, when executed by a processor, implement the above-described data message processing method.

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

Claims

1. A method for processing data packets, characterized in that, The method is applied to a network device, which is configured with a programmable hardware forwarding chip, and the method is executed by the programmable hardware forwarding chip. The method includes: The network device receives a first data packet, the first data packet including a header extension option field, the header extension option field being an option field with variable length and non-fixed structure; Based on the hardware alignment constraints of the programmable hardware forwarding chip, the header extension option field is parsed to obtain a parsing result, which includes the target option field in the header extension option field. When it is determined that the target option field meets the modification conditions, the target option field is modified, and the first data packet is updated based on the modified target option field to obtain the second data packet.

2. The method as described in claim 1, characterized in that, The programmable hardware forwarding chip includes data packet parsing rules designed based on the hardware alignment constraints. The hardware alignment constraints are used to indicate that the byte length of the hardware alignment operation granularity of the programmable hardware forwarding chip is a first byte length. The data packet parsing rules are used to indicate that, based on the first byte length and according to the option field truncation and splicing method, the first option field occupied by the target option field is located from the header extended option field. The hardware alignment constraints based on the programmable hardware forwarding chip are used to parse the header extension option field to obtain the parsing result, including: According to the instructions of the data packet parsing rules, determine the i-th reference option field from the header extended option field, and determine whether the i-th reference option field contains the identifier of the target option field, where i is a positive integer; If the i-th reference option field contains the identifier of the target option field, then the first option field occupied by the target option field in the i-th reference option field is added to the parsing result; Wherein, if i=1, the i-th reference option field is the option field occupied by the first option field in the header extended option field; if i>1, and there are remaining bytes after the (i-1)-th reference option field is truncated in units of the first byte length, the i-th reference option field is the option field obtained by concatenating the remaining bytes and the next option field of the (i-1)-th reference option field in the header extended option field; if i>1, and there are no remaining bytes after the (i-1)-th reference option field is truncated in units of the first byte length, the i-th reference option field is the option field occupied by the next option field of the (i-1)-th reference option field in the header extended option field.

3. The method as described in claim 2, characterized in that, The method further includes: If the i-th reference option field does not contain the identifier of the target option field, then the i-th reference option field is truncated in units of the first byte length to obtain the second option field in the header extended option field that is located before the target option field, and the second option field is added to the parsing result; the byte length of the second option field is the first byte length; Let i = i + 1, and perform the step of determining the i-th reference option field from the header extended option field.

4. The method as described in claim 2, characterized in that, The method further includes: When there is a preceding byte before the target option field in the i-th reference option field, a third option field located before the target option field in the header extended option field is determined based on the option field occupied by the preceding byte. The byte length of the third option field is the second byte length, and the second byte length is less than the first byte length. Add the third option field to the parsing result.

5. The method as described in claim 2, characterized in that, The programmable hardware forwarding chip also includes a front buffer and a message buffer, wherein the first data packet is stored in the message buffer; The step of determining the i-th reference option field from the header extended option field and determining whether the i-th reference option field contains the identifier of the target option field includes: Read the header extended option field from the message buffer into the front buffer; The identifier of the next option field of the (i-1)th reference option field is pre-read in the pre-buffer; If the identifier of the next option field of the (i-1)th reference option field is the identifier of the target option field, then the i-th reference option field is determined based on the next option field of the (i-1)th reference option field, and it is determined that the i-th reference option field contains the identifier of the target option field.

6. The method as described in claim 5, characterized in that, The method further includes: If the identifier of the next option field of the (i-1)th reference option field is not the identifier of the target option field, then the i-th reference option field is determined based on the next option field of the (i-1)th reference option field, and it is determined that the i-th reference option field does not contain the identifier of the target option field.

7. The method according to any one of claims 2-6, characterized in that, The programmable hardware forwarding chip also includes a counter for the first data packet, and the counter for the first data packet is set with a preset length threshold, which is equal to the length of the header extension option field. The method further includes: Obtain the length of the third byte of the option field added to the parsed result; The length of the parsed bytes in the counter of the first data packet is increased by the length of the third byte; If the length of the parsed bytes after the increase is equal to the preset length threshold in the counter of the first data packet, then it is determined that the target option field does not exist in the header extension option field, and the step of determining the i-th reference option field from the header extension option field is stopped.

8. The method according to any one of claims 2-4, characterized in that, The programmable hardware forwarding chip includes a header buffer, which contains multiple storage blocks with a length of the first byte; the programmable hardware forwarding chip includes a parsing result storage rule designed based on the hardware alignment constraint, which is used to record the storage blocks allocated to each data structure in the header data structure definition; The header data structure definition includes a first data structure in units of the byte length of the target option field, a second data structure in units of the first byte length, and a third data structure in units of the second byte length. Adding the first option field to the parsing result includes: storing the first option field in the storage block allocated for the first data structure in the header cache according to the parsing result storage rules; Adding the second option field to the parsing result includes: storing the second option field in the storage block allocated for the second data structure in the header cache according to the parsing result storage rules; Adding the third option field to the parsing result includes: storing the third option field in the storage block allocated for the third data structure in the header cache according to the parsing result storage rules.

9. The method as described in claim 1, characterized in that, The first data packet also includes a fixed header, which includes a checksum field; When it is determined that the target option field meets the modification conditions, the target option field is modified, and the first data packet is updated based on the modified target option field to obtain the second data packet, including: When it is determined that the target option field meets the modification conditions, the target option field is modified, and the checksum field is recalculated based on the modified target option field; Based on the modified target option field and the recalculated checksum field, the first data packet is updated to obtain the second data packet.

10. The method as described in claim 9, characterized in that, The programmable hardware forwarding chip also includes a matching action table for the target option field. The matching action table contains at least one matching rule and a modification action rule corresponding to each matching rule. The first data packet also includes a fixed header. The programmable hardware forwarding chip includes a header buffer, which stores the fixed header and the target option field. The step of modifying the target option field when it is determined that the target option field meets the modification conditions includes: Extract the header protocol fields from the fixed header from the header buffer; The target matching rule that the header protocol field conforms to is determined from the matching action table, and the recommended field parameters of the target option field are determined based on the modification action rule corresponding to the target matching rule; Obtain the actual field parameters of the target option field from the header cache; If the recommended field parameter of the target option field does not match the actual field parameter of the target option field, then the target option field is determined to meet the modification conditions, and the actual field parameter of the target option field in the header cache is updated to the recommended field parameter of the target option field.

11. The method as described in claim 9, characterized in that, The programmable hardware forwarding chip includes a header buffer, which stores the fixed header and the target option field. The recalculation of the checksum field based on the modified target option field includes: Obtain the actual field parameters of the target option field and the actual field parameters of the checksum field from the header cache. The difference between the actual field parameter of the checksum field and the actual field parameter of the target option field is calculated to obtain the intermediate field parameter of the checksum field; If the actual field parameter of the target option field in the header cache is updated to the recommended field parameter of the target option field, then the recommended field parameter of the target option field and the intermediate field parameter of the checksum field are summed to obtain the recommended field parameter of the checksum field. Update the actual field parameters of the checksum field in the header cache to the recommended field parameters of the checksum field.

12. The method according to any one of claims 9-11, characterized in that, The programmable hardware forwarding chip includes a header buffer, which contains a fixed header after recalculating the checksum field, a modified target option field, and an option field in the header extended option field that precedes the target option field. The programmable hardware forwarding chip also includes a packet buffer, in which the first data packet is stored. The process of updating the first data packet based on the modified target option field and the recalculated checksum field to obtain the second data packet includes: Obtain from the header cache the fixed header after recalculating the checksum field, the modified target option field, and the option field in the header extended option field that precedes the target option field; Read the content field following the target option field from the first data packet from the message buffer; The second data packet is assembled based on the fixed header after recalculating the checksum field, the modified target option field, the option field in the header extended option field that precedes the target option field, and the content field in the first data packet that follows the target option field.

13. A data packet processing apparatus, characterized in that, The device is applied to a network device, the network device being configured with a programmable hardware forwarding chip, the device being executed by the programmable hardware forwarding chip, and the device comprising: The message parsing unit is used to obtain a first data packet received by the network device. The first data packet includes a header extension option field, which is an option field with variable length and non-fixed structure. The message parsing unit is further configured to parse the header extension option field based on the hardware alignment constraints of the programmable hardware forwarding chip, and obtain a parsing result, wherein the parsing result includes the target option field in the header extension option field; The modification and reassembly unit is used to modify the target option field when it is determined that the target option field meets the modification conditions, and update the first data packet based on the modified target option field to obtain the second data packet.

14. A computer device, characterized in that, include: Processor, memory, and communication interface; The processor is connected to the memory and the communication interface, wherein the communication interface is used to provide network communication functions, the memory is used to store program code, and the processor is used to call the program code to execute the data packet processing method as described in any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including computer instructions, which, when executed by a processor, perform the data packet processing method as described in any one of claims 1 to 12.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including computer instructions, which, when executed by a processor, perform the data packet processing method as described in any one of claims 1 to 12.

Images