A method for generating a packet header checksum and a method for generating a packet header

Abstract

Embodiments of the present disclosure provide a packet header checksum generation method and a packet header generation method. The packet header checksum generation method comprises: obtaining, from a packet header vector, a protocol information unit corresponding to each valid field to be contained in a packet header; determining whether the protocol information unit is valid, and if not, the protocol information unit does not participate in the generation of the packet header checksum; when the length of the protocol information unit is different from the length of a checksum field, modifying the protocol information unit into a checksum calculation unit with the same length as the checksum field by padding or splitting, and when the length of the protocol information unit is consistent with the length of the checksum field, taking the protocol information unit as the checksum calculation unit; and preprocessing each checksum calculation unit according to preset checksum configuration information, and generating a packet header checksum. The present disclosure can support the generation of checksums of packet headers of various protocol combinations without changing hardware.

Description

Technical Field

[0001] This disclosure relates to the field of communication technology, and more specifically, to a method for generating a packet header checksum and a method for generating a packet header using the method. Background Technology

[0002] As network technologies and protocols continue to evolve, traditional packet generators are typically designed for fixed protocol formats. For example, for a given combination of Ethernet, IP, and transport layer protocols, the hardware packet generation module is designed to output packet headers with a fixed order and structure. The packet header usually contains a checksum field, used by the receiving end to verify the integrity of the packet data. Traditional switches or routers typically design dedicated hardware logic to calculate checksums for fixed protocol formats. For example, for IPv4 packets, the hardware calculates the checksum by summing each 16-bit word of the IP header. This fixed-function checksum calculation unit can only handle predefined protocol formats.

[0003] When protocols change or new protocols are introduced, traditional packet generators, relying on established protocol structures, often cannot adapt and require redesigned and reimplemented hardware. They lack a universal solution for checksum calculations across arbitrary packet formats. Whenever protocol fields change, the program must be rewritten and compiled, making dynamic configuration at runtime impossible. This significantly reduces the efficiency of network devices in supporting new protocols. Implementing a universal checksum algorithm using pure software logic increases pipeline overhead and impacts line-rate forwarding.

[0004] Therefore, existing technologies lack a solution that can flexibly select packet header fields to participate in checksum calculation based on hardware design and configuration. Summary of the Invention

[0005] To generate checksums suitable for configurable packet headers without modifying hardware, a first aspect of this disclosure provides a method for generating packet header checksums. The method includes: obtaining protocol information units (PAUs) from a packet header vector corresponding to each valid field to be included in the packet header; determining whether the PAU is valid, and if invalid, not participating in the generation of the packet header checksum; when the length of the PAU differs from the length of the checksum field, modifying the PAU into a checksum calculation unit with the same length as the checksum field by padding or splitting, and when the length of the PAU is the same as the length of the checksum field, using the PAU as the checksum calculation unit; preprocessing each checksum calculation unit according to preset checksum configuration information, and generating the packet header checksum using the preprocessed checksum calculation units.

[0006] In the packet header vector, the length of Protocol Information Units (PINs) can vary to accommodate information from different protocol fields. Each protocol field can occupy one or more PINs. The position of a PIN in the packet header vector is recorded in the field list. To exclude unused or invalid PINs, the field list may also include flags indicating whether each PIN is valid. The length of a valid PIN is adjusted to equal the length of the checksum field for checksum calculation.

[0007] This disclosure applies to message generation systems with configurable protocols. When the message protocol changes, the checksum calculation for the new valid fields can be adapted by adjusting the configuration information without modifying the hardware structure. By padding or splitting the protocol information units to adjust them into checksum calculation units with the same length as the checksum field, the hardware adder can directly perform accumulation operations with fixed-width units as input, thereby achieving pipelined processing. Even if the field lengths of different protocols differ, there is no need to modify the adder's operational logic.

[0008] Optionally, according to the packet header checksum generation method of the first aspect of this disclosure, when the length of the protocol information unit is half the length of the checksum field, the padding flag is inverted after each padding of the protocol information unit, and the protocol information unit is alternately padded to the high and low bits of the checksum calculation unit according to the padding flag. This method does not require the use of a multiplexer, thus reducing hardware latency.

[0009] Optionally, according to the packet header checksum generation method of the first aspect of this disclosure, the preset checksum configuration information is stored in a field list, each entry in the field list corresponds to a field, and the checksum configuration information includes a flag indicating whether the protocol information unit is valid, a flag for the preprocessing, and the location of the protocol information unit stored in the packet header vector. A checksum configuration information can be set for each protocol information unit, and the configuration information can be automatically modified to adapt to the new protocol when the protocol changes.

[0010] Optionally, according to the packet header checksum generation method of the first aspect of this disclosure, the preprocessing includes performing one of the following preprocessing steps based on a flag used for the preprocessing: preventing the checksum calculation unit from participating in the generation of the packet header checksum, maintaining the original value of the checksum calculation unit unchanged, and shifting the checksum calculation unit one bit to the left. When the protocol information unit is not a valid protocol information unit included in the valid fields of the field list, a preprocessing flag can be set to prevent it from participating in the generation of the packet header checksum. When the protocol information unit is a valid protocol information unit included in the valid fields of the field list, the preprocessing method can be determined based on the number of times it appears in the field list.

[0011] Optionally, according to the method for generating a packet header checksum according to the first aspect of this disclosure, generating the packet header checksum includes performing a two's complement accumulation operation on the pre-processed checksum calculation unit; and controlling the checksum calculation unit to participate in the two's complement accumulation operation as an addend or subtractor according to the checksum configuration information. The two's complement accumulation operation is to perform binary addition on the checksum calculation unit and add the carry-back from the highest bit back to the lowest bit. This method has a high error detection rate and is suitable for pipelined processing.

[0012] A second aspect of this disclosure provides a configurable packet header generation method, comprising: extracting a plurality of protocol type fields from a packet header vector according to a domain diagram; comparing each of the plurality of protocol type fields with one or more candidate type values, and using the result of each comparison as a type validity indicator in a type validity indicator pool; extracting all the type validity indicators corresponding to a field in the domain diagram from the type validity indicator pool and performing logical operations on them to generate a field validity indicator indicating whether the field is valid; generating the packet header checksum according to any of the preceding packet header checksum generation methods; and for fields where the field validity indicator is valid, filling and adding the packet header checksum in the order specified in the domain diagram to generate a packet header.

[0013] According to the method of this disclosure, the domain diagram can be adjusted as needed, thereby flexibly handling different protocol combinations. After the domain diagram is adjusted, the domain list will be adjusted accordingly, and the valid domains, after being sequentially concatenated, will correspond to a protocol sequence in the domain diagram. Each protocol type field corresponds to a different candidate type value. Based on the determined domain diagram and domain list, the candidate type values ​​are known and can be pre-stored in a register. After comparing each of the plurality of protocol type fields with one or more candidate type values, it can be determined whether each protocol type field has a matching candidate type value. Each type validity indicator indicates invalidity or validity, so each comparison result can be represented using only one bit, for example, 0 for invalidity and 1 for validity. The type validity indicator pool includes all type validity indicators. Since a field may correspond to one or more type validity indicators, when determining whether the field is valid, all relevant type validity indicators need to be considered, and logical operations can be performed on these type validity indicators according to the situation of each field. Logical operations include, for example, Boolean logical operations such as AND and OR.

[0014] Optionally, according to the configurable packet header generation method of the second aspect of the present disclosure, extracting the plurality of protocol type fields from the packet header vector according to a predetermined domain graph includes extracting a plurality of data units of fixed length including the plurality of protocol type fields from the packet header vector, and extracting the plurality of protocol type fields from the plurality of data units. One data unit may extract one or more protocol type fields. Compared to directly reading protocol type fields based on an address, this method adds a hardware pipeline processing stage, optimizes hardware timing, and thus improves the reading speed.

[0015] Optionally, according to the configurable packet header generation method of the first aspect of the present disclosure, the type validity indicator pool further includes a packet header vector validity indicator, which is used to indicate whether the storage unit of the packet header vector is valid. When the packet header vector validity indicator indicates that its corresponding storage unit is invalid, the type validity indicator of the protocol type field stored in the storage unit is invalid. This embodiment further adds the packet header vector validity indicator to the type validity indicator pool, which can be used to filter invalid fields and prevent data residue from affecting the judgment of the next frame, thereby improving the accuracy and efficiency of field validity judgment.

[0016] Optionally, according to the configurable packet header generation method of the first aspect of the present disclosure, wherein filling the packet header in the order specified in the domain graph for a field whose validity is indicated as valid includes extracting a protocol information field corresponding to the valid field from the packet header vector based on the position of the valid field stored in the packet header vector and the length of the field.

[0017] Optionally, the configurable packet header generation method according to the first aspect of the present disclosure may use a first register for extracting the plurality of protocol type fields and generating a type validity indication from the plurality of protocol type fields. The number of rows in the first register is not less than the number of the plurality of protocol type fields, and each row includes a first logical operation selection code, a reference position selection field, a preset mask, and a candidate type value. The first logical operation selection code in each row represents the logical operation performed between the protocol type field corresponding to the row and the one or more candidate type values. The reference position selection field in each row represents the position information of the data unit in the packet header vector where the protocol type field corresponding to the row is located. Each preset mask is used to extract a protocol type field from one of the plurality of data units in the packet header vector.

[0018] Optionally, the configurable packet header generation method according to the first aspect of the present disclosure can further use a second register to generate field validity indications from type validity indications. The number of rows in the second register is equal to the number of fields in the field graph. Each row includes a second logical operation selection code and a type validity indication position selection field. The type validity indication position selection field in each row indicates the position of all type validity indications corresponding to a field in the field graph. The second logical operation selection code in each row indicates the logical operation performed between the type validity indications in that row. The first and second logical operations can be Boolean logical operations.

[0019] The embodiments of this disclosure, on the one hand, flexibly determine the existence of each protocol field in the generated packet header through a field validity indication signal generation mechanism; on the other hand, they design a method for generating checksums, which allows support for new field graphs by modifying the register configuration of the field list without hardware modifications, effectively solving the problem of flexible packet header reassembly. The method of this disclosure can be implemented in hardware in a pipelined manner, supporting line-rate packet generation and processing, enabling the system to maintain flexibility without reducing throughput. This is of great significance for high-speed network environments (such as backbone network switching equipment, data service centers, etc.).

[0020] Implementing any apparatus or method of this disclosure does not necessarily require achieving all of the advantages described above simultaneously. Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description and embodiments, or may be learned by practicing this disclosure. The objects and advantages of embodiments of this disclosure may be realized and obtained by means of the structures pointed out in the description, claims, and drawings. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings of the embodiments will be briefly introduced below. Obviously, the drawings described below only relate to some embodiments of this disclosure, and are not intended to limit this disclosure.

[0022] Figure 1 A flowchart illustrating a method for generating a packet header according to an embodiment of the present disclosure is shown;

[0023] Figure 2 A flowchart of a method for generating a checksum according to an embodiment of the present disclosure is shown;

[0024] Figure 3 A flowchart illustrating a method for generating data cells that match the length of a checksum field according to an embodiment of this disclosure is shown.

[0025] Figure 4 A flowchart of a method for generating a packet header according to another embodiment of the present disclosure is shown;

[0026] Figure 5 A flowchart of a method for generating a packet header according to another embodiment of the present disclosure is shown;

[0027] Figure 6 A schematic diagram of a message header vector structure according to an embodiment of the present disclosure is shown;

[0028] Figure 7 A schematic diagram of a portion of the domain list structure according to an embodiment of the present disclosure is shown;

[0029] Figure 8 A schematic diagram of an apparatus for generating packet headers according to an embodiment of the present disclosure is shown. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. Various different embodiments can be combined with each other to constitute other embodiments not shown in the following description. All other embodiments obtained by those skilled in the art based on the described embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0031] Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms “first,” “second,” and similar terms used in this disclosure and the claims do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, the terms “an” or “a” and similar terms do not necessarily indicate a quantity limitation. The terms “comprising” or “including” and similar terms mean that the element or object preceding the word covers the element or object listed following the word and its equivalents, without excluding other elements or objects. The terms “connected” or “linked” and similar terms are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. The terms “upper,” “lower,” “left,” “right,” etc., are used only to indicate relative positional relationships, and these relative positional relationships may change accordingly when the absolute position of the described object changes.

[0032] The Packet Header Vector (PHV) in this disclosure is a hardware register array or storage structure used to store the packet parsing results. The field list is a configuration table or register table used to describe the configuration of each field in the packet header vector and the configurations involved in the packet assembly process.

[0033] The message header vector can be implemented as a hardware register array or memory structure to store the parsing results of the message header. During the parsing of received messages, type indication information of each protocol layer, protocol-related fields, metadata, etc., can be stored in the message header vector. For example, the message header vector can contain 224 storage units (or slots), and the row width of each slot can vary, with a total bit width of 4096. Figure 6 A schematic diagram of a message header vector structure according to an embodiment of this disclosure is shown, wherein the total bit width is 4096 bits, with 224 rows, and the number of bits per slot can vary, for example, between 8 bits, 16 bits, and 32 bits. Since the number of bits occupied by different protocols may vary, different storage capacities can be set for the slots of the message header vector to accommodate the fields written, thereby improving storage space utilization and efficiency. For example, the message header vector can store various protocol-related information fields at different locations with different lengths, such as the destination MAC address and source MAC address for Ethernet, VLAN type indication information and VLAN type, IPv4 type indication information, header length, source address, destination address, protocol fields, etc. Through a predetermined configuration, the information fields of different protocols can be mapped to different offset positions in the message header vector for flexible subsequent retrieval. These format configurations can be stored in a domain list. The number of entries in the domain list corresponds to the number of domains in the domain graph.

[0034] As mentioned above, when writing the message header vector, the storage capacity of each slot may not be the same to match the length of the information fields of each protocol. However, when reading data during the header assembly process, data is read from the message header vector in a fixed length. For example, if reading is done in 8-bit units, the 4096-bit capacity of the message header vector is divided into 512 lines for reading; if reading is done in 16-bit units, the message header vector is divided into 256 lines for reading. The field list records the position of each protocol information field corresponding to the valid fields stored in the message header vector.

[0035] To determine which memory locations in the current message header vector are valid and which are empty or contain residual old data after each parsing step, a message header vector validity indicator can be assigned to the message header vector. This indicator shows whether each slot in the message header vector is valid. The number of message header vector validity indicators is no greater than the number of slots. For memory locations where validity checks are not required, no corresponding validity indicator needs to be set. For example, the message header vector validity indicator for each slot can occupy 1 bit, indicating whether the corresponding memory location is valid.

[0036] The packet header generation device disclosed herein is a hardware module that can dynamically generate packet header data conforming to various network protocol specifications. In the configurable packet header generation device, a packet consists of several protocol fields, each corresponding to a field of a network protocol. The legal combinations of these fields are defined by a domain graph. The domain graph is used to represent the hierarchical relationships and jump rules between protocol fields. The domain graph uses nodes to represent each protocol field (such as Ethernet (Eth), VLAN, IPv4, TCP / UDP), and can form a tree structure of protocols starting from the physical layer. The next layer protocol that each node (each field) may connect to refers to the next layer protocol that may be selected in the direction from the physical layer to the application layer. The domain graph can represent all possible combinations of legal protocols, and each node (domain) may connect to multiple nodes. The order of the fields follows predetermined rules. For example, VLAN domains always appear after Eth domains and before IPv4; (2) IPv4 always precedes TCP and UDP; (3) UDP and TCP can never appear at the same time, and there is no relative order between them; (4) This top-down and left-right relationship makes the order of each domain relative to other domains fixed. Therefore, all domains in the domain diagram are arranged and combined in order from top to bottom and from left to right to form a combination of all domains. The configuration of this combination of all domains is recorded in the domain list (represented by FL (Field List) in the attached figure). When assembling packets, invalid domains in the domain list are removed to form a protocol sequence. The configuration information representing a specific packet header can be obtained by corresponding to the protocol sequence. A domain diagram can use a domain list to represent the strict order between domains. A domain diagram can include multiple protocol sequences. Different packets can correspond to different protocol sequences, and each protocol sequence can correspond to a path in the domain diagram. The type indication information contained in each domain indicates which domain is the next one associated with that domain. When assembling the packet header, invalid domains are removed and valid domains are combined. A field list can effectively represent the field structure of a message, providing a data structure basis for programmable message generation.

[0037] Figure 7A partial structural diagram of a field list according to an embodiment of this disclosure is shown. The number of entries in the field list is the same as the number of fields in the field diagram. The data structure of the field list is used to store the definition information of each field, including but not limited to the protocol type number corresponding to each field, the position information of the field in the packet header vector, the length of the field in the packet header, the checksum calculation method of the field, etc. The field list provides the necessary configuration and format for the generation of the packet header, so that the assembly process can be flexibly performed according to the field diagram. After the field diagram is determined, the field list can be pre-configured according to the field diagram to support new protocol types or different field arrangements, thereby improving the configurability of the system. Each field list entry (FLE, Field List Entry) in the field list corresponds to one field. Each entry in the field list may include checksum configuration information (e.g., checksum of protocol information elements corresponding to one or more packet header vectors for each field) of the protocol information element. Figure 7 Each line contains PHV_CFG0 to PHV-CFG3, and the location information of the protocol information field occupied by each field in the message header vector. Figure 7 The protocol information unit (PIN) includes the Locations field in the header, as well as the length information of each field in the header (FLE_LENGTH). A PIN is a line of protocol-related information recorded in the header vector. The length of a PIN is related to the length of each line in the header vector and may vary. Protocol information fields can be of fixed length.

[0038] Each checksum configuration information includes a flag (EN) indicating whether each protocol information unit is valid, how each protocol information unit participates in the checksum calculation (Checkum Unit cfg), and the message header vector number (PHV No) of that protocol information unit.

[0039] Figure 1 A flowchart illustrating a method for generating a packet header with a checksum according to an embodiment of this disclosure is shown. To generate a packet header during packet assembly, this disclosure first designs a configurable field validity (valid field) determination mechanism. This mechanism generates a validity indication for a field by parsing and logically combining the type indication information of that field, thereby determining whether the field should appear in the final packet. Next, a checksum is generated for the valid fields for header generation. Specifically, the method for generating a packet header includes the following steps:

[0040] In step S11, multiple protocol type fields are obtained from the message header vector according to the predetermined domain diagram. The protocol type fields may correspond to type indication information of specific domains, and each domain's type indication information may correspond to one or more protocol type fields. Protocol type fields are fields related to the characteristic values ​​of the protocol. Here, the specific location of the protocol type fields in the message header vector needs to be stored in a register, and the required protocol type fields can be further obtained from the specific location stored in the message header vector using a mask. Protocol type fields are protocol type-related information stored in the PHV, and the number of bits they occupy is not fixed.

[0041] Specific fields can be all fields in the domain diagram or a subset of fields in the domain diagram. Optionally, when one or more fields in the domain diagram are pre-determined to be used for assembling the packet header, in order to improve efficiency, the validity of this or these fields can be removed, and the corresponding field validity indicator can be directly set to valid, thus eliminating the need to obtain the corresponding protocol type field from the packet header vector.

[0042] In step S12, each protocol type field is compared with one or more candidate type values, and each comparison result serves as a type valid indicator (represented by TVI in the accompanying drawings). Since each domain may have more than one node (i.e., domain) to which it can selectively connect (e.g., IPv4 can connect to TCP or UDP), each protocol type field will be compared with one or more candidate type values. The number of candidate values ​​compared is related to the number of nodes in the next-level domains connected to that domain in the domain graph. The type values ​​can be feature values ​​representing characteristic fields of the protocol, which are known for each protocol. The candidate type values ​​and the logical operations for the comparisons can be pre-stored in registers.

[0043] Each comparison result is recorded as a type validity indicator corresponding to that protocol type field. For example, each comparison result can be represented by 1 bit. After comparing all protocol type fields, all comparison results are compiled into a type validity indicator pool. The type validity indicator pool can be stored in a specific register or memory structure.

[0044] In step S13, logical operations are performed on all valid type indicators corresponding to a field to generate a field validity indicator (represented by FVI (Field Valid Indicator) for each field). The method of logical operation is related to the relationship between the protocol type fields of that field. For example, if a field is valid only if every protocol type field is valid, an AND operation can be used. After the field diagram is determined, the field list is determined, and the method of logical operation is predetermined for each field. Each field validity indicator can be 1 bit, for example, 1 indicates valid and 0 indicates invalid.

[0045] In step S14, the configuration and protocol information units (with lengths corresponding to the slot size of the packet header vector as described above) corresponding to the valid fields are obtained from the packet header vector according to the field validity indicator and the field list, and a checksum for the packet header is generated. Here, a valid field refers to a field whose field validity indicator indicates that it is valid, for example, a valid field is a field whose field validity indicator is 1.

[0046] In step S15, the configuration of the corresponding valid fields is obtained from the header vector according to the field validity indication, and the header is generated by combining the checksum of the header. Optionally, if one or more fields in the field diagram are pre-determined to be used to assemble the header, these fields are necessarily valid, and their corresponding information in the header vector will also be used to generate the header. For valid fields, the protocol information fields to be extracted are determined according to the length information in the field list, and extracted according to the position information of these fields. The protocol information fields of these valid fields are then concatenated in order, and the header is obtained by combining the generated checksum.

[0047] The method described in the above embodiments can support any combination of different network protocols and efficiently assemble packets without modifying the hardware or software.

[0048] Figure 2 A flowchart illustrating a method for generating checksums according to an embodiment of this disclosure is shown. In step 21, the protocol information unit corresponding to each valid field is read from the message header vector according to the field validity indication. One field may correspond to multiple protocol information units.

[0049] If the protocol information unit (PAU) and the checksum field have different lengths, the PAU can be padded or split to obtain a checksum calculation unit with the same length as the checksum field. If the length of the PAU is the same as the checksum field, the PAU serves as the checksum calculation unit and participates in subsequent checksum calculations. As mentioned above, the length of the PAU stored in the message header vector is related to each protocol and can vary. Since the checksum length is fixed, the length of the PAU must first be normalized to obtain a checksum calculation unit with the same length as the checksum. For example, when the PAU in the message header vector is 8 bits and the checksum length is 16 bits, the 8-bit PAU can be padded into the high or low bits of the 16 bits to enable hardware pipelined processing. When the PAU in the message header vector is 32 bits and the checksum length is 16 bits, the PAU can be split into two checksum calculation units.

[0050] In step S22, preprocessing is performed on each checksum calculation unit according to a predetermined domain list. Preprocessing of the checksum calculation unit may include determining how the unit participates in the checksum calculation based on the checksum configuration information in the domain list. For example, if the configuration information is 0, the checksum calculation unit may not participate in the checksum calculation, and the output value after preprocessing is 0. If the configuration information is 1, the checksum calculation unit participates in the checksum calculation with its original value, and the output value after preprocessing is its original value. If the configuration information is 2, the checksum calculation unit will be used twice in the checksum calculation, so the output value after preprocessing is twice that of the checksum calculation unit, or the checksum calculation unit is shifted left by one position. The configuration information used for preprocessing can be determined based on whether the protocol information unit exists and / or the number of times it appears in the valid domains of the domain list. When a protocol information unit is not a valid protocol information unit included in the valid domains of the domain list, a corresponding flag can be set so that it does not participate in the generation of the packet header checksum. When a protocol information unit is a valid protocol information unit included in the valid domains of the domain list, the preprocessing method can be determined based on the number of times it appears in the domain list. For example, if an element appears once, the configuration information can be set to 1; if it appears twice, the configuration information can be set to 2. The configuration information is not limited to the three methods mentioned above; that is, the preprocessing method is not limited to these three methods, and it can also be cyclically shifted left and padded more times as needed. Optionally, a protocol information unit may also appear in entries corresponding to different domains in the domain list.

[0051] In step S23, the preprocessed checksum calculation unit performs the prescribed operation. For example, the checksum calculation unit performs a two's complement accumulation operation. The two's complement accumulation operation performs binary addition and adds the carry-over from the highest bit back to the lowest bit.

[0052] Figure 3 Implementation shown Figure 2 A schematic flowchart of step S21 in the process, which determines whether the protocol information unit is valid and makes the length of the protocol information unit in the message header vector match the checksum field.

[0053] In step S211, for a field in the field list, its validity is determined based on the field validity indicator. If it is an invalid field, the configuration line remains unchanged (step S212), and the next field is evaluated. A configuration line generally refers to a control signal line in hardware that transmits control information; here, it determines the connection method of the data path. If it is a valid field, proceed to step S213.

[0054] In step S213, it is determined whether a protocol information unit in the domain list entry of the valid domain is valid. If the checksum and configuration information corresponding to the protocol information unit indicates that the protocol information unit is invalid (e.g., the protocol information unit has no stored content, and the EN flag of the protocol information unit is 0), step S214 is executed, the configuration line remains unchanged, and the process proceeds to step S217. In step S217, it is determined whether all protocol information units in the domain list entry have been processed ( Figure 7 The example shows that each domain list entry includes at most four protocol information units. If not, return to S213 to continue processing the next protocol information unit. If yes, it means that all protocol information units in the valid domain have been processed, and the processing of the valid domain ends (step S218), and the next domain is judged.

[0055] If it is determined in step S213 that the protocol information unit is valid (e.g., its EN flag is 1), then step S215 is executed. In step S215, if the protocol information unit length is half or less of the checksum length, the protocol field is padded with checksum calculation units of the same length as the checksum field; if the protocol information unit length is a multiple of the checksum field length, the protocol information unit is split into checksum calculation units of the same length as the checksum; if the protocol information unit length is equal to the checksum field length, the protocol information unit is used as a checksum calculation unit. Since the slot size of each slot in the message header vector is fixed, the above operation does not require a multiplexer.

[0056] To fill shorter protocol information units into data units of the same length as the checksum field, a padding flag can be set, indicating the current padding position of the received protocol information unit. The protocol information unit determines its position in the checksum calculation unit based on the padding flag. The padding flag can be inverted or accumulated to adjust the padding position of the next protocol information unit. For example, if multiple 8-bit protocol information units are to be filled into a 16-bit checksum calculation unit, the padding flag is inverted after each received protocol information unit, causing the multiple 8-bit protocol information units to be alternately filled between high and low bits, facilitating subsequent checksum calculation.

[0057] In step S216, a configuration line is set so that the checksum calculation unit participates in the checksum calculation.

[0058] In step S217, if all protocol information units in the domain list have been processed, the processing of the valid domain ends (step S218), and the next domain is judged; otherwise, the process returns to step S213.

[0059] Repeat the above steps until all fields have been processed.

[0060] Figure 4 A flowchart illustrating a method for generating domain validity indication information according to another embodiment of this disclosure is shown. This embodiment is similar to... Figure 1 The difference in the illustrated embodiment lies in the way multiple protocol type fields are extracted from the message header vector. Figure 4 In this embodiment, the protocol type pool is first extracted from the message header vector, and then the protocol type field is extracted from the protocol type pool. The protocol type field may correspond to the type indication information of multiple specific fields in the domain graph, and the type indication information of each field may correspond to one or more protocol type fields.

[0061] In step S41, data units containing protocol type fields are extracted from the message header vector to form a protocol type pool. As described above, the message header vector can be read in fixed data lengths. Therefore, data units related to protocol type fields can be read from the message header vector in fixed data lengths to form a protocol type pool. A data unit may include at least one protocol type field. The position or sequence number of these data units (i.e., the data units of the protocol type pool) in the message header vector can be stored in a register (e.g., the first register shown in Table 1 below).

[0062] The specified multiple fields can be all the fields in the domain diagram, or a subset of the fields in the domain diagram. Optionally, when one or more fields in the domain diagram are pre-determined to be used for assembling the packet header, the validity indication of the corresponding field can be set to valid directly without checking the validity of this or these fields, thus eliminating the need to obtain the corresponding data unit from the packet header vector.

[0063] In step S42, multiple protocol type fields are extracted from the protocol type pool. The first register shown in Table 1 records the position of each protocol information field in the data unit (e.g., via a mask, offset, or other means) stored in the message header vector. Therefore, protocol type fields can be extracted from the protocol type pool based on the field list via a mask or offset. A data unit in the protocol type pool may contain one or more protocol type fields.

[0064] Steps S43-S46 correspond to steps S12-S15, and can be found in the above description of steps S12-S15, so they will not be repeated here.

[0065] Figure 4 The embodiment shown first extracts a fixed-length data unit from the message header vector, and then further extracts the target protocol type field from the fixed data unit according to a predefined mask or offset. This method facilitates hardware pipeline processing. Compared with directly reading the protocol type field according to the address, it adds a hardware pipeline processing stage in the hardware implementation, optimizes the hardware timing, and thus improves the reading speed.

[0066] Figure 5 A flowchart illustrating a method for generating domain validity indication information according to another embodiment of the present disclosure is shown. This embodiment is similar to... Figure 1 The difference in the illustrated embodiment is that a message header vector validity indicator is added as a type validity indicator.

[0067] Specifically, steps S51, S52, S55, and S56 correspond to steps S11, S12, S14, and S15. Please refer to the above explanation of steps S11, S12, S14, and S15.

[0068] Step S53 describes that the type validity indicator pool further includes a message header vector validity indicator, which is used to indicate whether the storage unit related to the protocol in the domain graph in the message header vector is valid. The message header vector validity indicator is generally generated when the parser identifies the current message and writes it into the message header vector. It can be used to filter invalid fields and prevent data residue from affecting the judgment of the next frame. Therefore, the type validity indicator and the message header vector validity indicator can be combined into a type validity indicator pool.

[0069] In step S54, logical operations are performed on all type validity indicators corresponding to a field to generate a field validity indicator. If the type validity indicator related to a field obtained in step S52 indicates validity, while the message header vector validity indicator indicates that the message header vector portion corresponding to that type is invalid, then the field validity indicator for that field can be determined to be invalid through a preset logical operation method. Furthermore, when concatenating the packet header, only the rows of the message header vector corresponding to the field validity indicator need to be read, instead of scanning all rows of the message header vector, thus improving the efficiency of packet header generation.

[0070] Figure 5 The described embodiments can also be used Figure 4 Replacing step S51 with steps S41 and S42 in the process helps to achieve hardware pipeline processing.

[0071] Table 1

[0072]

[0073] Table 1 shows an example configuration of a first register for generating a type-validation indication according to an embodiment of this disclosure. This first register can be used for... Figure 4 or Figure 5 The method shown. The number of rows in the first register corresponds to the number of protocol type fields, and can usually be set to the maximum possible number of protocol type fields supported by the system. In each row, a number of storage units are reserved to store candidate type values, and the number can also be set to the maximum possible number of candidate type values. For example, in the example in Table 1, the first register contains 14 rows, and each row includes 4 storage units for storing candidate type values. In specific applications, the storage space of some rows or columns may not be actually used. As shown in the figure, the data structure of each row is the same, including the following fields: first logical operation selection code (OP code), reference position selection field (Reference Position Sel), reference mask (Reference Mask), and candidate type value (Type Value[0]-Type Value[3]). The reference position selection field indicates the position or sequence number of the data unit in the protocol type pool in the message header vector. The required protocol type field is obtained from the selected data unit by using the reference mask. The protocol type field selected in each row is compared with the candidate type value in the row (up to 4 in this example), and a type valid indication is obtained each time. The first logical operation selection code indicates the logical operation to be performed on the protocol type field and candidate type values ​​for that line, such as a Boolean logical operation like AND, OR, or LOCK. The first register configured above can be used to obtain a valid type indication for each protocol type field.

[0074] Table 2

[0075]

[0076] Table 2 shows an example configuration of a second register for generating field validity indicators according to one embodiment of the present disclosure. Each row of the second register includes the following fields: a second logical operation selection code (OP) and a type validity indicator location selection field (TVI_SEL). In this example, the number of type validity indicators for logical operations in each row can be less than or equal to 4. The number of storage units reserved for type validity indicators in each row of the second register can be determined based on the maximum number of type validity indicators that need to participate in the operation, and the number of rows in the second register corresponds to the number of fields in the field list.

[0077] The second logical operation selection code is used to represent the logical operation performed on the type validity indicators in the register, such as AND, OR, or other operations. By performing predetermined logical operations on the type validity indicators in the register, a corresponding number of field validity indicators are obtained. The size of the position selection field for the type validity indicators is determined based on the number of type validity indicators. For example, when the number of type validity indicators is 280, 9 bits can be allocated to the position selection field TVI_SEL for the type validity indicators.

[0078] Figure 8 The system includes a domain validity indicator (FVI) generation module 1001, a configuration generation module 1002, a checksum generation module 1003, and a packet header generation module 1004, which are connected in sequence. The domain validity indicator generation module receives the packet header vector and the first configuration information (FL1) in the domain list, and performs steps to generate the domain validity indicator, such as... Figure 1 Steps S11 to S13 in the process Figure 4 Steps S41 to S44 or Figure 5 Steps S51 to S54 in the configuration generation module 1001 are used to generate a domain validity indication. The first configuration information FL1 in the domain list may include at least the location information of the domain stored in the message header vector. The domain validity indication generation module 1001 sends the domain validity indication to the configuration generation module 1002.

[0079] The configuration generation module 1002 is used to generate the specific configuration information required for constructing the packet header. The configuration generation module 1002 receives a field validity indication and receives the packet header vector and the second configuration information (FL2) in the field list to generate the packet header configuration. The second configuration information may include at least the position information of the field in the packet header vector and its length information in the packet header. Based on the field validity indication and the second configuration information in the field list, the configuration generation module 1002 determines the storage position of the valid fields in the packet header vector, determines the concatenation order of the valid fields according to the field list, and outputs a packet header generation configuration signal.

[0080] The checksum generation module 1003 obtains the protocol information element corresponding to the valid field from the packet header vector according to the field validity indication, and generates the checksum of the packet header. It can perform... Figure 2 The steps are shown.

[0081] The packet header generation module 1004 generates configuration signals and checksums based on the packet headers output by the configuration generation module 1002 and the checksum generation module 1003. It reads the protocol information fields of valid protocol fields from the packet header vector and concatenates these fields with the checksums in the order of the field list to form a complete packet header. This packet header is then concatenated with the packet payload and output as packet data.

[0082] The message header vector information can be transmitted in parallel to the above modules or serially to the modules, as shown in the figure.

[0083] In one embodiment, the domain validity indication generation module, configuration generation module, checksum generation module, and packet header generation module can be implemented in hardware.

[0084] The specific quantities mentioned in the embodiments of this disclosure (e.g., the number of register rows, the capacity of PHV, the number of candidate type values, the number of fields, etc.) are for illustrative purposes and are not intended to limit this disclosure.

[0085] The embodiments of this disclosure automatically update the domain list and its configuration based on changes and rules in the domain diagram. The checksum calculation method, the length of each field, and its address are stored in a register. Therefore, it can be applied to different protocol configurations without changing the hardware logic. This disclosure can dynamically select the required domains for different protocol combinations and supports the merging and combination of arbitrary domain segments of data frames, effectively solving the difficulties of traditional schemes in flexible data frame reassembly. Simultaneously, it enables flexible configuration of the checksum calculation scheme based on a configurable packet header.

[0086] The embodiments of the present invention can be modified and altered in various ways without departing from the spirit and scope of the invention. Therefore, it should be understood that the scope of protection of the present invention should not be limited to the exemplary embodiments described above, but should cover the full scope defined by the claims and their equivalents.

Claims

1. A method for generating a packet header checksum, characterized in that, include: Obtain the protocol information unit corresponding to each valid field to be included in the message header from the message header vector; Determine whether the protocol information unit is valid; if invalid, the protocol information unit will not participate in the generation of the packet header checksum. When the length of the protocol information unit is different from the length of the checksum field, the protocol information unit is modified into a checksum calculation unit with the same length as the checksum field by padding or splitting. When the length of the protocol information unit is the same as the length of the checksum field, the protocol information unit is used as the checksum calculation unit. Each checksum calculation unit is preprocessed according to the preset checksum configuration information, and the preprocessed checksum calculation unit is used to generate the packet header checksum.

2. The method for generating a packet header checksum as described in claim 1, characterized in that, When the length of the protocol information unit is half the length of the checksum field, the filling flag is inverted after each filling of the protocol information unit, and the protocol information unit is alternately filled into the high and low bits of the checksum calculation unit according to the filling flag.

3. The method for generating a packet header checksum as described in claim 1, characterized in that, The preset checksum configuration information is stored in a domain list, where each entry in the domain list corresponds to a domain. The checksum configuration information includes a flag indicating whether the protocol information unit is valid, a flag for the preprocessing, and the location of the protocol information unit stored in the message header vector.

4. The method for generating a packet header checksum as described in claim 3, characterized in that, The preprocessing includes performing one of the following preprocessing operations based on a flag used for the preprocessing: causing the checksum calculation unit to not participate in the generation of the packet header checksum, maintaining the original value of the checksum calculation unit unchanged, and shifting the checksum calculation unit one bit to the left.

5. The method for generating a packet header checksum as described in claim 4, characterized in that, The process of generating the packet header checksum includes performing a two's complement addition operation on the preprocessed checksum calculation unit; and controlling the checksum calculation unit to participate in the two's complement addition operation as an addend or subtractor according to the checksum configuration information.

6. A method for generating a message header, characterized in that, include Based on the predetermined domain diagram, extract multiple protocol type fields from the message header vector; Each of the plurality of protocol type fields is compared with one or more candidate type values, and the result of each comparison is used as a type valid indicator in the type valid indicator pool; Extract all type valid indicators corresponding to a domain in the domain graph from the type valid indicator pool and perform logical operations on them to generate a domain validity indicator indicating whether the domain is valid; The packet header checksum is generated according to any one of claims 1-5. For fields whose validity indication is valid, fill them in according to the order specified in the field diagram and add the packet header checksum to generate the packet header.

7. The packet header generation method as described in claim 6, characterized in that, According to the predetermined domain diagram, extracting the plurality of protocol type fields from the message header vector includes extracting a plurality of data units of fixed length containing the plurality of protocol type fields from the message header vector, and extracting the plurality of protocol type fields from the plurality of data units.

8. The packet header generation method as described in claim 6, characterized in that, The type validity indicator pool also includes a message header vector validity indicator, which is used to indicate whether the storage unit of the message header vector is valid. When the message header vector validity indicator indicates that its corresponding storage unit is invalid, the type validity indicator of the protocol type field stored in the storage unit is invalid.

9. The packet header generation method as described in claim 6, characterized in that, For fields whose validity indication is valid, the packet header checksum is filled in and added in the order specified in the field diagram to generate a packet header that includes extracting the protocol information field corresponding to the valid field from the packet header vector based on the position of the valid field stored in the packet header vector and the length of the field.

10. The packet header generation method as described in claim 7, characterized in that, It also includes a first register, the number of rows of the first register being no less than the number of the plurality of protocol type fields, each row including a first logical operation selection code, a reference position selection field, a preset mask, and a candidate type value, wherein the first logical operation selection code of each row represents the logical operation performed between the protocol type field corresponding to the row and the one or more of the candidate type values, the reference position selection field of each row represents the position information of one of the data units in the plurality of data units of the message header vector where the protocol type field corresponding to the row is located, and each preset mask is used to extract a protocol type field from one of the plurality of data units of the message header vector.

Images