Packet programmable modification method, chip and network card

Abstract

The application provides a message programmable modification method, a chip and a network card, and relates to the technical field of message modification. The method comprises the following steps: receiving an original message and extracting quintuple information from the original message; taking the quintuple information as a lookup key to perform matching lookup in a preset action table, determining one or more programmable actions required to be executed by the original message and the execution sequence of each programmable action; determining the target hardware unit corresponding to each programmable action on a preset hardware pipeline according to the determined execution sequence; controlling the current message to pass through each target hardware unit in sequence to execute each programmable action; and outputting the modified message after all programmable actions are executed. The application does not need to design special hardware circuits for each field, and greatly reduces the consumption of register resources.

Description

Technical Field

[0001] This invention relates to the field of message modification technology, and in particular to a programmable message modification method, chip, and network interface card. Background Technology

[0002] In data communication networks, network devices need to perform various modification operations on received packets, such as deleting IP options, modifying TCP sequence numbers, and adding tunnel encapsulation. Traditional packet modification methods typically employ fixed-function hardware circuits, meaning that dedicated processing circuits and registers are set up for each field that may need modification. For example, a dedicated modification circuit is set up for the TTL field, and another dedicated circuit is set up for the Checksum field. This approach is acceptable when handling common fields, but as network protocols become increasingly complex and the types of fields requiring modification increase (such as various TCP options and IPv6 extension headers), configuring dedicated circuits for each field will lead to a sharp increase in the number of hardware registers, significantly increasing chip area and power consumption. Furthermore, fixed-function circuits cannot flexibly adapt to new modification requirements. Once the chip is fabricated, the packet modification function is fixed and cannot support user-defined new fields or new operation types. Therefore, existing technologies suffer from high hardware resource consumption, poor flexibility, and insufficient scalability. Summary of the Invention

[0003] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows: According to a first aspect of this application, a method for programmably modifying a message is provided, comprising the following steps: S100: Receive the original message and extract the five-tuple information from the original message. The five-tuple information includes the source IP address, destination IP address, source port number, destination port number, and protocol number. S200: Using the quintuple information as the search keyword, perform a matching search in a preset action table to determine one or more programmable actions that the original message needs to execute and the execution order of each programmable action; wherein, the preset action table is pre-configured by the user, and each entry in the action table contains a quintuple matching field and a corresponding action sequence identifier; each programmable action is associated with a set of pre-configured programmable parameters, the programmable parameters including: level selection parameter prg_sel, type parameter prg_type, offset parameter prg_ofst, length parameter prg_len, and data parameter prg_data; S300: Based on the determined execution order, determine the target hardware unit corresponding to each programmable action on the preset hardware pipeline; each target hardware unit is used to perform the corresponding field operation according to the corresponding associated programmable parameter group; S400: Control the current message to pass through each of the determined target hardware units in sequence to execute each programmable action; each programmable action uses the corresponding associated programmable parameter group to perform the corresponding field operation; the current message is the original message or an intermediate message processed by the previous programmable action; S500: After all programmable actions have been executed, the modified message is output.

[0004] According to another aspect of this application, a message programmable modification chip is also provided, characterized in that it includes: The hardware pipeline is equipped with multiple hardware units, each of which contains extract branches, modify branches and insert branches that work in parallel, and each branch is enabled independently according to the configuration. An action table storage unit is used to store an action table pre-configured by the user. Each entry in the action table contains a five-tuple matching field and a corresponding action sequence identifier. A programmable parameter storage unit is used to store a group of programmable parameters associated with each programmable action. The programmable parameters include: a hierarchy selection parameter prg_sel, a type parameter prg_type, an offset parameter prg_ofst, a length parameter prg_len, and a data parameter prg_data. The lookup and matching unit is used to receive the five-tuple information of the original message, and use the five-tuple information as the lookup key to perform a match search in the action table to determine one or more programmable actions that the original message needs to execute and the execution order of each programmable action. The hardware unit allocation unit is used to determine the target hardware unit corresponding to each programmable action on the hardware pipeline according to the determined execution order. The control unit is used to control the original message to pass through each of the determined target hardware units in sequence, so that each target hardware unit performs the corresponding field operation according to the corresponding associated programmable parameter group, and outputs the modified message after all programmable actions have been executed.

[0005] According to another aspect of this application, a network interface card (NIC) is also provided, including the message programmable modification chip described in the second aspect.

[0006] The present invention has at least the following beneficial effects: Compared with existing technologies, the message programmable modification method of this invention achieves software-defined message modification functions by introducing programmable parameters and preset action tables. Users only need to configure the action table to flexibly specify which modification operation to perform on which message, without designing dedicated hardware circuits for each field, greatly reducing the consumption of register resources. By determining the action sequence through a five-tuple lookup table and using hardware units on the hardware pipeline to execute each programmable action sequentially, the processing logic and hardware circuits are decoupled. The same set of hardware units can be reused to support different modification requirements for different messages, significantly improving the utilization efficiency of hardware resources. In addition, when it is necessary to support new protocol fields or new modification types, only the action table configuration needs to be updated without modifying the hardware design, which has good scalability and flexibility and can adapt to the ever-evolving network protocol requirements. Attached Figure Description

[0007] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0008] Figure 1 A flowchart illustrating a message programmable modification method provided in an embodiment of the present invention. Detailed Implementation

[0009] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0010] It should be noted that, based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Furthermore, this device and / or practice the method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0011] The following will refer to Figure 1 The flowchart shown illustrates a method for programmable message modification, introducing one such method.

[0012] The method for programmably modifying this message may include the following steps: S100: Receive the original message and extract the five-tuple information from the original message. The five-tuple information includes the source IP address, destination IP address, source port number, destination port number, and protocol number.

[0013] In this embodiment, when a network device (such as a network interface card) receives a complete packet, it first parses the packet. The parsing engine disassembles the packet layer by layer in the order of Ethernet frame, IP header, and transport layer header, extracting five key fields: source IP address, destination IP address, source port number, destination port number, and protocol number. These five fields are collectively called a quintuple, which can uniquely identify a network flow. For example, an arriving IPv4 TCP packet has a source IP of IP1, a destination IP of IP2, a source port of 12345, a destination port of 80, and a protocol number of 6 (representing TCP). The hardware parsing logic extracts these values ​​and temporarily stores them in an internal register.

[0014] The 5-tuple is the most commonly used flow identifier in the network. Extracting the 5-tuple can quickly determine the service flow to which the packet belongs in subsequent table lookups, thereby matching the predefined modification strategy and avoiding the high overhead of matching the entire packet content.

[0015] S200: Using the quintuple information as the search keyword, perform a matching search in a preset action table to determine one or more programmable actions that the original message needs to execute and the execution order of each programmable action; wherein, the preset action table is pre-configured by the user, and each entry in the action table contains a quintuple matching field and a corresponding action sequence identifier; each programmable action is associated with a set of pre-configured programmable parameters, the programmable parameters including: level selection parameter prg_sel, type parameter prg_type, offset parameter prg_ofst, length parameter prg_len, and data parameter prg_data.

[0016] Furthermore, step S200 includes the following steps: S210: Match the extracted quintuple information with the quintuple matching field of each item in the action table, and read the action sequence identifier corresponding to the matched item.

[0017] In this embodiment, after the hardware parsing engine extracts the five-tuple information (source IP, destination IP, source port, destination port, protocol number) of the packet, it sends the five-tuple as a lookup keyword to the preset action table lookup module. The action table is stored in the TCAM (Tri-State Content Addressable Memory) or hash table inside the chip, and each entry contains a five-tuple matching field and a corresponding action sequence identifier.

[0018] The matching field supports three matching modes: exact match (all fields must be exactly equal), mask match (some fields are ignored by using a mask, such as matching only the source IP network segment and ignoring the destination port), and wildcard match (any value). The lookup module compares the packet's 5-tuple with the matching fields of all entries in parallel. When an entry is matched (e.g., the 5-tuple is exactly the same as a rule), the hardware reads the action sequence identifier stored in that entry.

[0019] For example, a rule can be pre-configured: source IP=IP3, destination IP any, source port any, destination port=80, protocol number=6 (TCP), with action sequence identifier act_id=3. When a received packet has a source IP of IP4 (the first three segments of IP4 are the same as the first three segments of IP3), a destination port of 80, and a protocol of TCP, the rule is matched, and act_id=3 is read. If multiple entries are matched simultaneously (e.g., rules with different priorities exist), the hardware will select the one with the highest priority based on the preset priority field in the entry. The lookup process is completed within one clock cycle, ensuring it does not become a pipeline bottleneck.

[0020] This step completely delegates the complex message classification task to TCAM or hash table hardware, enabling high-throughput matching within a single cycle and avoiding the latency overhead of software table lookups. Support for mask matching allows users to flexibly define flow rules of arbitrary granularity (such as matching only IP prefixes or ignoring ports), adapting to various network strategies. The action sequence identifier, acting as an indirect pointer, avoids directly storing lengthy parameter sets in the action table, significantly saving storage space. It also allows multiple 5-tuple rules to share the same action sequence, facilitating batch configuration and updates.

[0021] S220: Obtain multiple programmable parameter groups arranged in sequence according to the action sequence identifier; wherein, each programmable parameter group corresponds to a programmable action; each programmable parameter group includes the corresponding prg_sel, prg_type, prg_ofst, prg_len, and prg_data.

[0022] After obtaining the action sequence identifier (e.g., act_id=3) from S210, the hardware immediately accesses another storage structure—the action parameter configuration table. This configuration table can be a separate RAM (Random Access Memory) or register array, storing a complete sequence of programmable parameter groups at the address of the action sequence identifier. Each action sequence consists of multiple programmable parameter groups arranged sequentially, with the i-th parameter group represented as: (prg_sel_i, prag_type_i, prag_ofst_i, prag_len_i, prag_data_i).

[0023] The hardware reads the entire sequence at once based on the action sequence identifier, or reads them one by one as needed. For example, the action sequence corresponding to act_id=3 contains two actions: Action 1 is to delete the IP option, with the parameter set (prg_sel=ori_outer_ip,prg_type=del,prg_ofst=160 (bit offset of IP header length),prg_len=32,prg_data=invalid); Action 2 is to modify the TCP sequence number, with the parameter set (prg_sel=mdf_inner_tp,prg_type=nmmdf,prg_ofst=32 (sequence number offset in TCP header),prg_len=32,prg_data=0x12345678). The hardware temporarily stores the obtained parameter sequence in an internal buffer and records the total number of actions N, and then hands it over to the pipeline scheduling unit for sequential processing. The action parameter configuration table can be dynamically updated by the user through the control plane, and action sequences can be modified or added without restarting the device.

[0024] This step enables centralized storage and flexible reuse of modification actions. The action parameter configuration table is separated from the action table, allowing the five-tuple rule table to remain concise, while complex modification action definitions only need to be stored once. Users can change message modification behavior through simple configuration changes (such as modifying values ​​in prag_data) without adjusting the hardware design. The parameter group adopts a unified format (prg_sel, prag_type, prag_ofst, prag_len, prag_data), providing good scalability. Adding new operation types in the future only requires adding new prag_type values, without affecting the existing hardware architecture. Simultaneously, obtaining the parameter group sequentially ensures the determinism of action execution, facilitating static scheduling in the hardware pipeline and avoiding the overhead of runtime dynamic parsing.

[0025] S300: Based on the determined execution order, determine the target hardware unit corresponding to each programmable action on the preset hardware pipeline; each target hardware unit is used to perform the corresponding field operation according to the corresponding associated programmable parameter group.

[0026] After determining the sequence and order of actions, the hardware needs to map each action to physical hardware resources. A hardware pipeline is pre-designed within the chip, with multiple hardware units arranged sequentially on the pipeline. Each hardware unit has the capability to execute any programmable action. Each programmable action is executed through its corresponding hardware unit.

[0027] Furthermore, the preset hardware pipeline in step S300 is equipped with multiple hardware units, each of which contains: extracting branches, modifying branches, and inserting branches, and the output of each branch can be enabled independently according to the configuration.

[0028] In one specific embodiment of the present invention, a plurality of hardware units (e.g., numbered 1 to 16) are pre-configured on the hardware pipeline. Each hardware unit contains three parallel functional branches: an extraction branch, a modification branch, and an insertion branch. The three branches receive input messages simultaneously, but are enabled independently according to the configuration. Only the enabled branch outputs its processing result to the subsequent logic of the unit.

[0029] Furthermore, determining the target hardware unit in step S300 includes the following steps: S310: Based on the user-pre-configured action-hardware unit mapping table, allocate N hardware units sequentially for the N actions to be performed on the original message. The allocated hardware unit number sequence is U1, U2, ..., U... N The condition U1 < U2 < ... < U N .

[0030] In this embodiment, the chip internally maintains a "mapped table of actions and hardware units" pre-configured by the user. This mapping table assigns a specific sequence of hardware unit numbers to each possible combination of action sequence length and type. When step S200 determines that the current message needs to perform N actions (N is determined by the action sequence, for example, N=2), the hardware reads the mapping table and allocates N hardware units to these N actions in execution order, obtaining the number sequence U1, U2, ..., U N The assignment must satisfy U1 < U2 < ... < U N That is, the numbers are strictly incremental, but not required to be consecutive (for example, U1=2, U2=5 can be assigned). During user configuration, it is ensured that these hardware units are not currently occupied by other packets (static scheduling, no overlap).

[0031] For example, suppose a hardware pipeline has 10 units, and the user has pre-configured mappings for the action sequence "delete IP option + modify TCP sequence number" (N=2) as U1=3 and U2=7. Then any packet requiring these two actions will be assigned to hardware units 3 and 7. The packet first completes the deletion operation at unit 3, and then is passed directly or via a bypass bus to unit 7 for modification. If a packet only needs to perform one action (N=1), the mapping table might assign U1=5. This static mapping is written during system initialization or policy updates, is read-only at runtime, and does not involve dynamic arbitration, thus avoiding complex bus contention logic.

[0032] With user-configured static mapping, the hardware does not need to perform dynamic resource arbitration at runtime. It can simply look up a table to determine the hardware unit corresponding to each action, which significantly reduces the complexity and latency of the chip control logic. The strictly increasing allocation sequence ensures that messages flow from low-numbered units to high-numbered units in the pipeline, which conforms to the physical layout order and avoids deadlock caused by reverse flow. The requirement for non-sequential numbering allows users to flexibly arrange resources according to the actual load. For example, frequently used actions can be concentrated in units with lower numbers, while less frequently used actions can be distributed to later units, optimizing the overall pipeline utilization. At the same time, static mapping naturally supports different messages using non-overlapping sets of units, laying the foundation for parallel processing.

[0033] S320: Each assigned hardware unit enables one or more internal branches according to the corresponding programmable parameter group: if the action needs to extract a field for subsequent use, the extraction branch is enabled and the extraction result is stored in the temporary register inside the hardware unit; if the action needs to modify a field, the modification branch is enabled; if the action needs to delete or add a field, the insertion branch is enabled.

[0034] After S310 determines the programmable parameter group corresponding to each hardware unit, the hardware writes each set of parameters into the configuration register of the corresponding unit. The three branches within each hardware unit—extract branch, modify branch, and insert branch—are always ready to receive input messages, but only explicitly enabled branches will pass their output to the unit's output terminal. The enabling logic is determined by prg_type, and the specific correspondence is as follows: If an action requires extracting fields for subsequent use (e.g., copying the CPS field, comparing CPC based on copied content, comparing PIC based on message information), then the extraction branch is enabled. The extraction branch reads the specified field from the message based on `prg_ofst` and `prg_len`, stores the field in a temporary register within the hardware unit, and records the register's index and content in the corresponding metadata of the message. Subsequent hardware units can retrieve the previously extracted data by reading this temporary register.

[0035] If an action requires modifying fields (e.g., modifying mmdf with a mask, modifying nmmdf without a mask, modifying cpm based on copied content, modifying pim based on message information, etc.), then the modification branch is enabled. The modification branch applies prag_data (and the mask) to the specified position in the message, directly overwriting the original fields, and the modified message becomes the output of that unit.

[0036] If the action requires deleting (del) or adding (add) a field, then the insert branch is enabled. The insert branch performs variable-length operations: when deleting, it truncates the field to the specified length; when adding, it inserts a new field (content from prag_data) at the specified position, and adjusts the message length field and subsequent offset accordingly. Since variable-length operations change the total length of the message, the insert branch also needs to update the cumulative offset adjustment delta that is passed with the message.

[0037] If an action requires both extraction and modification (e.g., copying and deleting cpd), then both the extract branch and the insert branch can be enabled simultaneously (the modification branch is disabled). The extract branch first stores the fields in a temporary register, while the insert branch performs the deletion operation. The outputs of the two branches are merged according to internal logic to form the final message.

[0038] If the action is only a comparison (such as mask comparison mcmp), then usually only the extract branch (reading fields for comparison) is enabled, without changing the message content, and the comparison result is stored in the status register.

[0039] Each hardware unit's three branches operate in parallel. Because they share the same input message, they can complete their respective operations within the same clock cycle. Then, an enable signal selects which branch's output to use as the unit's final output. For example, when the fetch and insert branches are enabled, the unit outputs the message processed by the insert branch, while a register retains the fetched fields. This parallel design allows compound operations (such as "copy and delete") to be completed in a single cycle within a hardware unit without needing to be split into two separate units.

[0040] For example: Suppose the first action of a message is cpd (copy source field and delete), with parameters prag_ofst=100 and prag_len=16. Hardware units (e.g., U1=3) are configured to enable fetch and insert branches. The fetch branch reads 16 bits from the message offset 100 bits and stores them in register temp0; simultaneously, the insert branch deletes the same 16-bit field from the message and outputs the shortened message. If a subsequent unit (e.g., U2=7) needs to perform cpm (modify another field with the copied content), it reads the value of register temp0 from the metadata and enables the modify branch to write that value to the specified location.

[0041] In the above steps, the multi-branch parallel architecture within a single hardware unit enables complex compound operations (copy + delete, extract + modify, etc.) to be completed in a single cycle within one unit, reducing pipeline stages and lowering processing latency. The extracted results are stored in a local temporary register and transmitted along with metadata, allowing any subsequent unit to access the previously extracted data, achieving cross-action data dependency without additional global caching. At the same time, the enabling mechanism allows a unit to dynamically select a functional branch based on the action type, enabling the reuse of the same hardware resources for different operation types and avoiding hardware redundancy caused by setting up dedicated units for each operation.

[0042] S400: Control the current message to pass through each of the determined target hardware units in sequence to execute each programmable action; each programmable action uses the corresponding associated programmable parameter group to perform the corresponding field operation; the current message is the original message or an intermediate message processed by the previous programmable action.

[0043] After the target hardware unit sequence is determined, the original message (or an intermediate message processed by the previous unit) is sent to the first target hardware unit U1 in the pipeline. Each hardware unit contains three parallel functional branches: an extract branch, a modify branch, and an insert branch. All three branches receive input messages simultaneously, but only output results according to the configured enabled branch. When a message arrives at a hardware unit, the unit performs an operation based on a set of programmable parameters pre-written into its registers.

[0044] Furthermore, the field operation types in step S400 include: deleting a field, mask comparison, no-mask comparison, mask modification, no-mask modification, adding a field, copying a field, copying and deleting a field, comparison based on copied content, modification based on copied content, addition based on copied content, comparison based on message information, modification based on message information, and addition based on message information; each programmable action executed in step S400 includes the following steps: S410: Determine the target level in the current message based on prg_sel.

[0045] In this embodiment, `prg_sel` (the layer selection parameter) is a predefined enumeration value used to specify which protocol layer or processing stage of the message the operation targets. Since the message may have undergone modifications by preceding actions in the pipeline (e.g., the outer tunnel header has been removed), the "current message" could be the original message or an intermediate message processed by a previous programmable action. The layer selection logic within the hardware unit parses the value of `prg_sel` and maps it to a specific base address pointer in the message memory.

[0046] Common layer definitions include: original outer MAC (ori_outer_mac), original outer IP (ori_outer_ip), original outer L4 (ori_outer_tp), original tunnel header (ori_tunnel), modified outer MAC (mdf_outer_mac), modified outer IP (mdf_outer_ip), modified outer L4 (mdf_outer_tp), modified tunnel header (mdf_tunnel), inner MAC (ori_inner_mac or mdf_inner_mac), inner IP, inner L4, and payload.

[0047] For example, if a user wants to modify the DSCP field in the original outer IP header, they configure `prg_sel=ori_outer_ip`. The hardware will find the starting address of the outer IP header in the packet buffer (this address is pre-recorded in the packet metadata by the parsing engine) as a reference point for subsequent offset calculations. If the user selects a non-existent layer (such as selecting an inner IP in a non-tunneled packet), the hardware will detect the error and disable the action to prevent erroneous modification.

[0048] The `prg_sel` parameter allows users to freely switch operation targets between different protocol layers (outer layer, inner layer, before and after tunneling) without needing to worry about the absolute position of each layer in the packet. It also supports the distinction between the original layer and the modified layer, enabling the same pipeline to process packets before and after decapsulation separately, adapting to the complex modification requirements of tunnel scenarios. The layer failure detection mechanism ensures that packet content will not be damaged when configuration errors occur, enhancing the robustness of the system.

[0049] S420: Determine the bit offset relative to the starting position of the target level based on prg_ofst, and determine the range of the operation field in conjunction with prg_len.

[0050] After determining the base address pointer of the target level, the hardware calculates the bit offset relative to the start position of that level using `prg_ofst` (an offset parameter). `prg_ofst` is a non-negative integer in bits. The hardware adds this offset to the base address pointer to obtain the absolute address of the first bit of the operation field in the message buffer. Then, it determines the bit width of the operation field, in bits, based on `prg_len` (a length parameter).

[0051] The maximum value of `prg_len` is limited depending on the operation type: 96 bits for mask comparison and modification, 192 bits for no-mask operations, and 192 bits for deletion and addition. If `prg_ofst` plus `prg_len` exceeds the actual length of that level (e.g., attempting to extract fields after the end of the IP header), the hardware will determine that the programmable action is invalid and will not make any modifications.

[0052] In addition, since the preceding actions may have performed deletion or addition operations, the message length may change. Therefore, when calculating the actual offset, the hardware also needs to add the cumulative offset adjustment amount delta that is passed with the message (see the variable length compensation mechanism later). That is, actual offset = base address + prg_ofst + delta.

[0053] The use of bit-level offset and length definition allows operations to be precise to any bit position, supporting the modification of non-integer byte fields (such as flag bits in the IP header); the length limit (96 / 192 bits) balances flexibility (covering common fields such as the 128 bits of the IPv6 address) and the economy of hardware implementation; offset out-of-bounds detection avoids invalid operations from damaging the packet; the introduction of cumulative offset adjustment ensures that subsequent actions can still be correctly located after a variable-length operation, guaranteeing the correctness of multi-action chains.

[0054] S430: Determine the operation type based on prag_type, and perform the corresponding field operation within the range of the operation field using the data provided by prag_data.

[0055] In this embodiment, the `prg_type` parameter determines the specific operation performed by the hardware unit on the specified field. This embodiment supports fourteen operation types, whose hardware implementations are detailed below.

[0056] Deleting a field (del): The hardware removes the field specified by prag_len from the message. After removal, the message content following that field is shifted forward to fill the gap. Simultaneously, the cumulative offset adjustment delta, which is carried over with the message, is updated by subtracting prag_len. For example, deleting the IP option (32 bits in length) reduces the total message length by 4 bytes.

[0057] Adding a field: The hardware inserts a new field of length `prg_len` at the position specified by `prg_ofst`. The inserted content is extracted from `prg_data`. After insertion, the packet content after the original position is shifted forward, and the cumulative offset adjustment `delta` is increased by `prg_len`. For example, adding a timestamp option (32 bits) to the TCP options field requires updating the TCP header length field simultaneously.

[0058] Mask Comparison (mcmp): The hardware extracts a field of length L = min(prg_len, 96) from the packet, and simultaneously parses the comparison value and mask (both 96 bits long, with the effective content high-order bits aligned) from prag_data. The comparison expression is (field&mask) == (value&mask). The result (true or false) is stored in a temporary status register without modifying the packet. For example, if only comparing the IP address prefix: mask is 0xFFFFFF00, value is 192.168.1.0, then only the high 24 bits are compared.

[0059] Maskless comparison (nmcmp): Extracts the field of length L=min(prg_len,192) and directly compares it with the value in prag_data, requiring them to be identical. The result is stored in the status register.

[0060] Mask Modification (MMDF): Modifies a field of length L = min(prg_len, 96). The hardware parses the value and mask from prag_data and executes new_field = (field & ~mask) | (value & mask). That is, only the bits with a mask value of 1 are modified, while the remaining bits remain unchanged. For example, modifying DSCP (6 bits) while leaving ECN (2 bits) unchanged: the mask is 0xFC (binary 11111100), and the value is the new DSCP value shifted left by 2 bits.

[0061] No-mask modification (nmmdf): Directly overwrite the value in prag_data for a field of length L=min(prg_len,192).

[0062] Copy Fields (cps): Extracts the specified field and stores it in the hardware unit's temporary register (without modifying the message) for subsequent use. The temporary register has multiple slots, each of which can identify its source.

[0063] Copy and Delete Field (cpd): Performs copying and deletion simultaneously: extracts the field into a temporary register, and then deletes the field from the message. Completed within a single unit, saving pipeline stages.

[0064] Content-based comparison (CPC): Extracts the current packet fields and compares them with the values ​​stored in the temporary register by a previous action. For example, if the TCP sequence number is copied using CPS, then CPC is used to compare whether another packet field matches it.

[0065] Copy-based modification (cpm): Writes the value in the temporary register to the currently specified field position, thus enabling copy-pasting of field content.

[0066] Addition based on copied content (CPA): Inserts the value in the temporary register as a new field into the specified position.

[0067] Comparison based on message information (pic): Extract internal message information (such as 5-tuple, ingress port number, timestamp, etc.) and compare it with prag_data. This information is pre-stored in metadata by the parsing engine.

[0068] Modification based on message information (pim): Rewrites a specified field using message information (such as the ingress port number).

[0069] Adding information based on message information (pia): Inserting message information as a new field.

[0070] In this embodiment, for operations requiring comparison, the result is stored in the status register, and subsequent actions (such as modification or addition) can be conditionally executed based on this result. Each hardware unit completes the above operations within one clock cycle according to the enabled branches. For example, if one unit is configured as mcmp, the extract branch reads the field and sends it to the comparator, and the comparison result is output to the status register; the modify and insert branches are disabled, and the message passes through as is. If another unit is configured as mmdf, the modify branch updates the field using mask logic, the other branches are disabled, and the modified message is output. For cppd, the extract and insert branches are enabled simultaneously, the extracted value is stored in the temporary register, and the insert branch performs deletion, outputting the shortened message.

[0071] The above steps cover the most common and complex operational needs for messages, from simple field deletion and modification to masked comparison / modification, and then to composite operations based on copied content and message information, all integrated under a unified parameter framework; the masking mechanism allows for fine-grained bit-level operations, greatly enhancing flexibility; copying and copy-based operation sequences (such as CPS followed by CPM) enable field content to be migrated within or between messages, realizing advanced data plane processing capabilities (such as rewriting TCP sequence numbers to previously saved values); all operations are completed within a single pipeline tick, ensuring line-rate processing; the introduction of status registers supports conditional execution, providing a foundation for complex strategies (such as "if a field equals X, then modify another field").

[0072] Furthermore, in step S430, when prag_type is masked comparison mcmp or maskless comparison nmcmp, the following steps are also included: For mask comparison, a comparison value `value` and a mask `mask` are defined. Both `value` and `mask` are extracted from `prg_data`, and the valid content is high-order aligned. The comparison length is `L = min(prg_len, 96)` bits. The comparison operation is represented as: `(field&mask) == (value&mask)`, where `field` is a bit field of length `L` extracted from a specified position in the message; `min()` is the minimum value function; and `&` is the bitwise AND operation. For maskless comparisons, the comparison length is L = min(prg_len, 192) bits, and the comparison operation is represented as: field == value; The comparison result is stored in a temporary status register for use in the conditional execution of subsequent programmable actions.

[0073] In this embodiment, when prag_type in step S430 is either masked comparison mcmp or maskless comparison nmcmp, the hardware executes the following comparison process.

[0074] First, the hardware determines the target level and starting offset in the current message based on `prg_sel` and `prg_ofst`, and determines the range of the fields to be compared based on `prg_len`. For masked comparison (MCMP), the comparison length `L` is the smaller of `prg_len` and 96 bits, i.e., `L = min(prg_len, 96)`. The hardware extracts the comparison value `value` and the mask `mask` from the `prg_data` parameter. The total bit width of `prg_data` is 192 bits (for masked comparison, the lower 96 bits are actually used to store the value, and the next lower 96 bits are used to store the mask, or compact encoding is used, but the core is that the effective content is aligned to the high bits). High bit alignment means that if `prg_len` is less than 96 bits, the effective bits of the value and mask are in the high bits, and the low bits are padded with zeros. For example, if `prg_len` = 8, and the user wants to compare a byte equal to 0x5A, then the high 8 bits of the value are 0x5A, and the low 88 bits are 0; the high 8 bits of the mask are 0xFF, and the low 88 bits are 0. The hardware extracts a bit field of length L (also high-order aligned) from the message. Then, perform a bitwise AND operation: perform a bitwise AND operation on field and mask to get field_masked = field&mask; perform a bitwise AND operation on value and mask to get value_masked = value&mask. Finally, compare whether the two are equal: (field&mask) == (value&mask). If they are equal, the comparison result is true (e.g., output logic 1), otherwise it is false (logic 0).

[0075] For unmasked comparison (nmcmp), the comparison length L = min(prg_len, 192) bits. `prg_data` is directly used as the comparison value (high-order aligned to the valid content). The hardware extracts the message field `field` (length L) and performs a direct equality comparison: `field == value`. For example, if `prg_len = 32` and `value = 0x12345678`, then the 32-bit field in the message must be exactly equal to 0x12345678.

[0076] After the comparison operation is complete, the hardware stores the comparison result (a Boolean value) in a temporary status register. This status register can be a single bit or a flag bit in the status vector. Each packet carries a private state field in the pipeline to record intermediate comparison results. Subsequent programmable actions can read the value of this status register by configuring conditional execution variants (e.g., conditional modification, conditional addition) in `prg_type` to determine whether to execute the action. For example, first, an `mcmp` operation might be performed to compare whether the DSCP in the IP header is a specific value, and the result is stored in the status register; subsequently, an `nmmdf` action might be configured as conditional execution, modifying the TCP sequence number only if the status register is true. The hardware checks this flag during conditional execution; if it is false, the operation is skipped, and the packet is passed directly to the next unit without modification.

[0077] In specific hardware implementations, the comparator unit is typically located within the fetch branch of the hardware unit. After reading the field, the fetch branch sends the field, value, and mask into a 192-bit arithmetic logic unit (ALU). For masked comparisons, the ALU first performs two bitwise AND operations, then outputs an equality signal through a 192-bit comparator; for comparisons without a mask, a direct comparison is performed. The comparison result stabilizes within the same clock cycle and is written to the status register field in the metadata structure transmitted with the message at the end of the cycle. Since the maximum limit of prag_len (96 / 192 bits) is much smaller than the typical data path width (e.g., 512 bits), the hardware can reuse the same comparator to handle comparisons of different lengths, simply by truncating or padding the high bits according to the valid bits of prag_len.

[0078] In this embodiment, through the masking mechanism, users can flexibly compare only specific bits in the fields (such as a single bit in the IP prefix or flags) while ignoring other irrelevant bits, greatly expanding the expressive power of the comparison operation and avoiding the need to set up dedicated circuits for each masking mode; the length limit of 96 / 192 bits covers most network fields (IPv6 address is 128 bits, TCP options are a maximum of 40 bytes), while controlling the bit width overhead of the hardware comparator; the rule of high-bit alignment of effective content simplifies hardware processing, eliminating the need to support arbitrary alignment methods and reducing design complexity; the comparison result is stored in the status register and used for subsequent action conditions, enabling the message processing logic to implement "if-then" branches, and users can implement complex strategies through configuration (such as "if field A equals X, then modify field B, otherwise delete field C") without changing the hardware pipeline structure; the entire comparison process is completed within one clock cycle without adding extra latency, ensuring line-speed processing capability.

[0079] Furthermore, in step S430, when prag_type is modified with a mask for mmdf or without a mask for nmmdf, the modification operation directly overwrites the original message at the original location.

[0080] When prag_type is modified with a mask for mmdf or without a mask for nmmdf in step S430, the hardware performs the modification operation, directly overwriting the new value at the original message position without changing the message length or moving the message content.

[0081] The specific implementation of mask modification (MMDF): For mask modification, the user specifies the length of the field to be modified using `prg_len`, with a length of L = min(prg_len, 96) bits. `prg_data` carries the modified value `value` and the mask, both with a valid length of L bits and high-order alignment (i.e., when `prg_len < 96`, the high L bits of `value` and `mask` are valid, and the low bits are padded with zeros). The hardware reads the current field `field` (with a length of L bits) from the specified position in the message (determined by `prg_sel` and `prg_ofst` combined with the cumulative offset adjustment). Then, it performs the following bitwise operation: `new_field = (field & ~mask) | (value & mask)`. This expression means that bits in `field` with a mask value of 0 remain unchanged, and bits with a mask value of 1 are overwritten by the corresponding bits in `value`. After the operation, the hardware writes `new_field` back to the same position in the message, completing the modification.

[0082] The specific implementation of maskless modification (NMMDF): For maskless modification, the length is L = min(prg_len, 192) bits. `prg_data` only contains the modified value (value, with the valid content aligned to the highest bit). The hardware directly extracts the packet field `field` and writes the entire `value` into that field location, i.e., `new_field = value`. For example, if a user needs to change the `SequenceNumber` field (32 bits) in the TCP header to 0x12345678, configure `prg_len = 32` and `value = 0x12345678`, and the hardware directly overwrites these 32 bits. Maskless modification does not retain any bits of the original field.

[0083] Masked modification supports partial field updates at the bit level, allowing users to precisely modify specific bits (such as modifying a flag bit individually) without reading the original field, greatly reducing the extra operations required for read-modify-write-back. Maskless modification provides the simplest overwrite, suitable for whole field replacement. Both modification methods share the same hardware data path, differing only in control logic, achieving resource reuse. Modification operations do not change the message length, thus avoiding the complexity of variable-length processing (such as offset adjustment), ensuring pipeline simplicity and efficiency. Since modification is an in-place overwrite, multiple modification actions can be executed independently and sequentially without interference, and the cumulative offset adjustment between actions automatically adapts to the impact of preceding variable-length operations, ensuring the correctness of multi-action chains. The entire modification process is completed within one clock cycle, meeting the requirements of line-rate processing.

[0084] Furthermore, when `prg_type` in step S430 is set to delete a field (`del`) or add a field (`add`), the message length changes, affecting the absolute position of all subsequent fields. To ensure that subsequent programmable actions can still correctly locate the desired operation field, this embodiment introduces a compensation mechanism for the cumulative offset adjustment amount `delta`.

[0085] In step S430, when prag_type is a delete field (del) or an add field (add), the method further includes the following steps: S440: For the deletion operation, remove a bit field of length prag_len from the message, with a deletion length of L_del, and update the cumulative offset adjustment delta = delta - L_del.

[0086] When the hardware unit performs a deletion operation, it first determines the starting position of the field to be deleted based on `prg_sel` and `prg_ofst`, and then determines the length of the field to be deleted (in bits) based on `prg_len`. Let the deletion length be `L_del`, which is equal to `prg_len` (but does not exceed 192 bits). The hardware removes `L_del` consecutive bits from the message starting from the beginning position. After removal, all message content originally following this field is shifted forward by `L_del` bits to fill the gap. The total message length is reduced by `L_del` bits accordingly. At the same time, the hardware updates the cumulative offset adjustment `delta` propagated in the pipeline with the message, with the update rule: `delta = delta - L_del`. The initial value of `delta` is 0, a signed integer, which can be positive or negative, and the bit width must be sufficient to cover the maximum net change (e.g., 12 bits can cover ±4096 bits).

[0087] By using signed subtraction with delta, the deletion operation can accurately record the amount of reduction in packet length, enabling subsequent hardware units to automatically compensate for the offset when calculating the actual access address without re-parsing packet boundaries. The removal operation and delta update are completed within the same hardware unit without adding extra pipeline stages, ensuring processing efficiency. Multi-level continuous deletion is supported, and delta accumulates multiple deletion lengths to ensure the correct final offset.

[0088] S450: For the increment operation, insert a bit field of length prg_len at the specified position. The inserted content is extracted from prg_data. The increment length is L_add. Update the cumulative offset adjustment delta = delta + L_add.

[0089] When the hardware unit performs an insert operation, it determines the insertion position (i.e., the bit offset within a certain level) based on `prg_sel` and `prg_ofst`, and extracts the field content to be inserted from `prg_data`. The insertion length is `prg_len` (let's call it `L_add`, maximum 192 bits). The hardware inserts the new field at this position by shifting all message content after that position backward by `L_add` bits, and then writing the `L_add` bits from `prg_data` into the vacated area. The total message length is increased by `L_add` bits accordingly. Simultaneously, the cumulative offset adjustment is updated: `delta = delta + L_add`.

[0090] The addition operation also compensates for the length increase through signed addition of delta, sharing the same compensation mechanism as the deletion operation, so that complex sequences of mixed deletion and addition can be handled correctly; the inserted content is directly obtained from prag_data without additional storage; the update of delta and the movement of message content are completed in the same cycle (or in the pipeline), meeting the line rate requirement.

[0091] S460: When subsequent programmable actions are executed, the actual offset prg_ofst_actual is obtained by adding the configured offset prg_ofst to the cumulative offset adjustment delta: prg_ofst_actual = prg_ofst + delta; where delta is initially 0 and is passed through the pipeline with the message.

[0092] When any subsequent hardware unit executes a programmable action (including comparison, modification, deletion, addition, etc.), the actual position of the operation field needs to be determined. Each hardware unit receives a message and its accompanying metadata (which includes the current delta value). The offset calculation logic of this unit performs the following operations: First, it reads the user-configured prag_ofst (a fixed offset relative to the starting position of the target level), then it reads the cumulative offset adjustment delta of the current message (obtained from all previous variable-length operations), and finally calculates the actual offset used: prag_ofst_actual = prag_ofst + delta.

[0093] It should be noted that both prg_ofst and delta are signed integers, but prg_ofst is usually non-negative, while delta can be positive or negative. The hardware uses prg_ofst_actual as the actual offset from the starting position of the target level to the starting bit of the operation field.

[0094] Offset correction after variable-length operations can be achieved through simple addition, avoiding complex location remapping tables or global message reconstruction. The delta is propagated step-by-step through the pipeline with the message, with each hardware unit independently calculating the actual offset, eliminating the need for central coordination. This method supports arbitrary combinations of deletion and addition; users do not need to worry about the impact of the operation order on the offset, only needing to configure the actions in the logical order. Offset out-of-bounds detection ensures security, preventing out-of-bounds access due to configuration errors. The entire compensation mechanism requires only one adder and one comparator in hardware, with minimal overhead, yet solves the core challenge of variable-length operations in programmable message modification.

[0095] S500: After all programmable actions have been executed, the modified message is output.

[0096] As the original message flows sequentially through all allocated hardware units, and each hardware unit completes the specified field operations (deletion, modification, addition, comparison, etc.) according to the corresponding programmable parameter set, the message has reached its final required form. At this point, the end module of the hardware pipeline retrieves the modified message from its internal buffer and performs necessary follow-up processing as needed (such as recalculating the IP header checksum, TCP / UDP checksum, or updating the message length field). Then, it sends the message to the output port to continue the subsequent forwarding or receiving process. This step ensures that all preset programmable modification actions are correctly applied and that the modified message meets expectations.

[0097] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0098] Embodiments of the present invention also provide a message programmable modification chip, comprising: The hardware pipeline is equipped with multiple hardware units, each of which contains extract branches, modify branches and insert branches that work in parallel, and each branch is enabled independently according to the configuration.

[0099] An action table storage unit is used to store action tables pre-configured by the user. Each entry in the action table contains a five-tuple matching field and a corresponding action sequence identifier.

[0100] A programmable parameter storage unit is used to store a group of programmable parameters associated with each programmable action. The programmable parameters include: a hierarchy selection parameter prg_sel, a type parameter prg_type, an offset parameter prg_ofst, a length parameter prg_len, and a data parameter prg_data.

[0101] The lookup and matching unit is used to receive the five-tuple information of the original message, and use the five-tuple information as the lookup key to perform a match search in the action table to determine one or more programmable actions that the original message needs to execute and the execution order of each programmable action.

[0102] The hardware unit allocation unit is used to determine the target hardware unit corresponding to each programmable action on the hardware pipeline according to the determined execution order.

[0103] The control unit is used to control the original message to pass through each of the determined target hardware units in sequence, so that each target hardware unit performs the corresponding field operation according to the corresponding associated programmable parameter group, and outputs the modified message after all programmable actions have been executed.

[0104] Embodiments of the present invention also provide a network interface card (NIC) including the message programmable modification chip described in the above embodiments.

[0105] While specific embodiments of the invention have been described in detail by way of examples, those skilled in the art should understand that the examples are for illustrative purposes only and are not intended to limit the scope of the invention. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the invention.

Claims

1. A method for programmable modification of messages, characterized in that, Includes the following steps: S100: Receive the original message and extract the five-tuple information from the original message. The five-tuple information includes the source IP address, destination IP address, source port number, destination port number, and protocol number. S200: Using the quintuple information as the search keyword, perform a matching search in a preset action table to determine one or more programmable actions that the original message needs to execute and the execution order of each programmable action; wherein, the preset action table is pre-configured by the user, and each entry in the action table contains a quintuple matching field and a corresponding action sequence identifier; each programmable action is associated with a set of pre-configured programmable parameters, the programmable parameters including: level selection parameter prg_sel, type parameter prg_type, offset parameter prg_ofst, length parameter prg_len, and data parameter prg_data; S300: Based on the determined execution order, determine the target hardware unit corresponding to each programmable action on the preset hardware pipeline; each target hardware unit is used to perform the corresponding field operation according to the corresponding associated programmable parameter group; S400: Control the current message to pass through each of the determined target hardware units in sequence to execute each programmable action; each programmable action uses the corresponding associated programmable parameter group to perform the corresponding field operation; the current message is the original message or an intermediate message processed by the previous programmable action; S500: After all programmable actions have been executed, the modified message is output.

2. The message programmable modification method according to claim 1, characterized in that, Step S200 includes the following steps: S210: Match the extracted quintuple information with the quintuple matching field of each item in the action table, and read the action sequence identifier corresponding to the hit item; S220: Obtain multiple programmable parameter groups arranged in sequence according to the action sequence identifier; wherein, each programmable parameter group corresponds to a programmable action; each programmable parameter group includes the corresponding prg_sel, prg_type, prg_ofst, prg_len, and prg_data.

3. The message programmable modification method according to claim 1, characterized in that, The field operations described in step S400 include the following types: field deletion, mask comparison, no-mask comparison, mask modification, no-mask modification, field addition, field copying, field copying and deletion, comparison based on copied content, modification based on copied content, addition based on copied content, comparison based on message information, modification based on message information, and addition based on message information. Each programmable action executed in step S400 includes the following steps: S410: Determine the target level in the current message based on prg_sel; S420: Determine the bit offset relative to the starting position of the target level based on prg_ofst, and determine the range of the operation field in conjunction with prg_len; S430: Determine the operation type based on prag_type, and perform the corresponding field operation within the range of the operation field using the data provided by prag_data.

4. The message programmable modification method according to claim 3, characterized in that, In step S430, when prag_type is masked comparison mcmp or maskless comparison nmcmp, the following steps are also included: For mask comparison, a comparison value `value` and a mask `mask` are defined. Both `value` and `mask` are extracted from `prg_data`, and the valid content is high-order aligned. The comparison length is `L = min(prg_len, 96)` bits. The comparison operation is represented as: `(field&mask) == (value&mask)`, where `field` is a bit field of length `L` extracted from a specified position in the message; `min()` is the minimum value function; and `&` is the bitwise AND operation. For maskless comparisons, the comparison length is L = min(prg_len, 192) bits, and the comparison operation is represented as: field == value; The comparison result is stored in a temporary status register for use in the conditional execution of subsequent programmable actions.

5. The message programmable modification method according to claim 3, characterized in that, In step S430, when prag_type is modified with a mask for mmdf or without a mask for nmmdf, the modification operation directly overwrites the original message at the original location.

6. The message programmable modification method according to claim 3, characterized in that, In step S430, when prag_type is a delete field (del) or an add field (add), the method further includes the following steps: S440: For the deletion operation, remove a bit field of length prag_len from the message, with a deletion length of L_del, and update the cumulative offset adjustment delta = delta - L_del; S450: For the increment operation, insert a bit field of length prg_len at the specified position. The inserted content is extracted from prg_data. The increment length is L_add. Update the cumulative offset adjustment delta = delta + L_add. S460: When subsequent programmable actions are executed, the actual offset prg_ofst_actual is obtained by adding the configured offset prg_ofst to the cumulative offset adjustment delta: prg_ofst_actual = prg_ofst + delta; where delta is initially 0 and is passed through the pipeline with the message.

7. The message programmable modification method according to claim 1, characterized in that, The preset hardware pipeline in step S300 is equipped with multiple hardware units. Each hardware unit contains: branch extraction, branch modification, and branch insertion, and the output of each branch can be enabled independently according to the configuration. Determining the target hardware unit in step S300 includes the following steps: S310: Based on the user-pre-configured action-hardware unit mapping table, allocate N hardware units sequentially for the N actions to be performed on the original message. The allocated hardware unit number sequence is U1, U2, ..., U... N The condition U1 < U2 < ... < U N ; S320: Each assigned hardware unit enables one or more internal branches according to the corresponding programmable parameter group: if the action needs to extract a field for subsequent use, the extraction branch is enabled and the extraction result is stored in the temporary register inside the hardware unit; if the action needs to modify a field, the modification branch is enabled; if the action needs to delete or add a field, the insertion branch is enabled. In step S400, the original message passes sequentially through the allocated hardware units U1, U2, ..., U... N After the previous unit finishes processing, it passes the message and associated metadata to the next unit; wherein, the metadata includes at least the cumulative offset adjustment amount and the extracted field content stored in each temporary register.

8. The message programmable modification method according to claim 1, characterized in that, The hardware pipeline supports parallel processing of multiple messages, with different messages being assigned to a set of non-overlapping hardware units.

9. A message programmable modification chip, characterized in that, include: The hardware pipeline is equipped with multiple hardware units, each of which contains extract branches, modify branches and insert branches that work in parallel, and each branch is enabled independently according to the configuration. An action table storage unit is used to store an action table pre-configured by the user. Each entry in the action table contains a five-tuple matching field and a corresponding action sequence identifier. A programmable parameter storage unit is used to store a group of programmable parameters associated with each programmable action. The programmable parameters include: a hierarchy selection parameter prg_sel, a type parameter prg_type, an offset parameter prg_ofst, a length parameter prg_len, and a data parameter prg_data. The lookup and matching unit is used to receive the five-tuple information of the original message, and use the five-tuple information as the lookup key to perform a match search in the action table to determine one or more programmable actions that the original message needs to execute and the execution order of each programmable action. The hardware unit allocation unit is used to determine the target hardware unit corresponding to each programmable action on the hardware pipeline according to the determined execution order. The control unit is used to control the original message to pass through each of the determined target hardware units in sequence, so that each target hardware unit performs the corresponding field operation according to the corresponding associated programmable parameter group, and outputs the modified message after all programmable actions have been executed.

10. A network interface card (NIC), characterized in that, Includes the message programmable modification chip as described in claim 9.

Images