A method, system and device for implementing TSO multi-protocol compatibility verification

Abstract

The application discloses a kind of verification method, system and equipment for realizing TSO multi-protocol compatibility, the verification method includes: by the key parameter of pre-setting to message structure each layer assignment value determination corresponding layer message type, to generate message and simulate network card fragmentation;Message editing command is generated and added to the first piece of message;Message transmission and reception are carried out;The message edited operation is carried out in reference model to the message received completely to simulate the operation of DUT;The fragment processed by the reference model is compared with the fragment processed by DUT one by one, to complete TSO verification.The verification method proposed in the application is for TSO verification, the message type of each layer of message structure can be configured, so that various protocol types of message can be generated, and the message editing command is generated by configuration, to realize the message fragmentation verification of TSO multi-protocol compatibility.

Description

Technical Field

[0001] This invention belongs to the field of chip verification technology, specifically relating to a verification method, system, and device for achieving TSO multi-protocol compatibility. Background Technology

[0002] TCP Segment Offload (TSO) is a technique that reduces CPU load by fragmenting transmitted data packets using the network interface card (NIC). NICs supporting TSO will split the data portion of a packet into several smaller fragments, and modify the header parameters (including the IP layer's Total Length and TCP's Sequence Number) relative to each fragment. Finally, each fragment has its header added to form a new independent packet, thus achieving the fragmentation function. This also requires hardware support for TCP checksum calculation, scattering, and aggregation.

[0003] However, TSO is primarily designed for TCP packets and cannot flexibly handle multiple protocols. Therefore, GSO (Generic Segmentation Offload) emerged as a technology with enhanced functionality.

[0004] GSO is more versatile than TSO, overcoming the limitations of a single message type. It is not only for TCP message processing but also compatible with any protocol. Furthermore, GSO is implemented in software, eliminating the need for hardware.

[0005] Therefore, existing TSO verification technologies are usually only used to detect TCP packets. For designs with special requirements, existing TSO verification technologies lack versatility, while GSO verification technology is not suitable for hardware-based TSO verification. Summary of the Invention

[0006] To address the problem that existing TSO verification technologies are incompatible with multiple protocols and lack versatility, this invention provides a verification method, system, and device for achieving multi-protocol compatibility of TSO. This invention can realize functions such as multi-protocol packet sending, thereby enabling TSO testing of multiple protocol types.

[0007] This invention is achieved through the following technical solution:

[0008] A verification method for achieving TSO multi-protocol compatibility, the verification method comprising:

[0009] By assigning values ​​to key parameters pre-set at each layer of the message structure, the message type of the corresponding layer is determined, thereby generating messages and simulating network card fragmentation;

[0010] Generate message editing commands and add them to the message header;

[0011] To transmit and receive messages;

[0012] The received messages are sent to the reference model for message editing to simulate the operation of the DUT;

[0013] The TSO verification is completed by comparing the slices processed by the reference model with the slices processed by the DUT one by one.

[0014] Existing TSO verification technologies typically only detect TCP packets and cannot be applied to other packet types, lacking versatility. While GSO verification technologies are compatible with multiple protocol types, they are not suitable for TSO verification that relies on hardware-based fragmentation. The verification method proposed in this invention, specifically for TSO verification, can generate packets of various protocol types by configuring the packet types at each layer of the packet structure. Furthermore, by configuring packet editing commands, it achieves TSO multi-protocol compatible packet fragmentation verification.

[0015] As a preferred embodiment, the assignment of values ​​to key parameters pre-set at each layer of the message structure in this invention specifically includes:

[0016] The key parameters of each layer of the message structure are assigned values ​​through an internal randomization process;

[0017] Alternatively, the corresponding message type can be generated and the key parameters of the corresponding layer can be assigned by judging the conditions.

[0018] The verification method proposed in this embodiment can generate messages of various protocol types internally for universal verification; it can also generate specific types of messages by inputting external parameters according to the actual verification object, making it suitable for specific verification environments.

[0019] As a preferred embodiment, the simulated network interface card (NIC) fragmentation of the present invention specifically includes:

[0020] A dynamic array is set for the corresponding constructed message structure; the size of the dynamic array is determined by the number of fragments;

[0021] Each slice is stored in the dynamic array;

[0022] The number of fragments is randomly generated, depending on the size of the message data portion and the fragment length; or the number of fragments is determined by externally input message length and fragment length.

[0023] The verification method proposed in this embodiment can realize TSO verification with different fragment lengths, and the fragment length can be generated randomly internally or determined by external parameter input, which has strong applicability.

[0024] In a preferred embodiment, the message editing commands generated by the present invention include: ordinary editing commands and TSO editing commands;

[0025] The ordinary editing command is used to update the header portion of the fragment;

[0026] The TSO edit command is used to modify specific message header parameters. The TSO edit command includes:

[0027] A. Perform operations on the offset 1 bit to modify the PSH and FIN fields of the TCP layer for each fragment;

[0028] B. Accumulate the 16-bit / 24-bit count after the offset, which is used to modify the ID field of the IPv4 layer and the Sequence Number field of the BTH layer;

[0029] C. Replace the 16 bits after the offset with the packet length plus a specified value, which is used to modify the Total Length field of the IPv4 layer;

[0030] D. Accumulate the fragment length count for the 32 bits after the offset, which is used to modify the Sequence Number field of the TCP layer;

[0031] E. Replace the 8 bits after the offset with the specified value, which is used to modify both the PSH and FIN fields simultaneously.

[0032] This embodiment can implement message header modification commands for various protocols, thereby enabling verification of message header field modifications for various protocols.

[0033] In a preferred embodiment, the parameters of the ordinary editing command and the TSO editing command of the present invention are determined by internal random generation or by external input parameters.

[0034] In a preferred embodiment, the transmission and reception of messages according to the present invention specifically includes:

[0035] Set custom signals as markers at the beginning and end of each segment;

[0036] When transmitting data, the length of each segment is stored in advance. After the segment length count is satisfied, the segment end signal is set and the corresponding segment information is transmitted. At the same time, the index of the transmitted data is incremented to ensure that the next transmitted data is the data of the next segment.

[0037] In a preferred embodiment, when transmitting data, the present invention fills the part that is not a full frame with random data and sets parameters to indicate the valid data part, and transmits the indicator parameters along with the fragmentation information.

[0038] Conversely, when receiving a message, it is necessary to extract the indicator parameters in the message information as indicators to extract valid data; after each fragmentation end signal is encountered, the currently received data is packaged into a small packet and stored in an array, while the data information of the corresponding fragment and the whole packet is updated.

[0039] To fully simulate TSO fragmentation, the verification method proposed in this embodiment transmits message information by adding random data to the portion of the message that is not a full clock cycle and setting an indicator parameter to indicate valid data.

[0040] In a preferred embodiment, the present invention sends the received message to a reference model for message editing, specifically including:

[0041] Extract the elements of the sliced ​​array and process them sequentially.

[0042] Before processing each segment, the message editing commands contained in the first segment need to be extracted;

[0043] Each fragment first performs a TSO edit operation on the new_header attached to the edit command to obtain the corresponding message header; then it performs a checksum calculation to update the field; finally, it uses a normal edit command to replace or insert the obtained new_header into the corresponding position in the fragment data to obtain a complete small packet.

[0044] Secondly, this invention proposes a verification system for achieving TSO multi-protocol compatibility, the verification system comprising:

[0045] The packet sending module is configured to perform the following operations: determine the packet type of the corresponding layer by assigning values ​​to the key parameters preset in each layer of the packet structure, thereby generating packets and simulating network interface card fragmentation; generate packet editing commands and add them to the packet header;

[0046] A transceiver module, configured to perform the following operations: transmitting and receiving messages;

[0047] The reference module is configured to perform the following operations: sending the received messages to the reference model for message editing to simulate the operation of the DUT;

[0048] The comparison module is configured to perform the following operation: compare the fragments processed by the reference model with the fragments processed by the DUT one by one, thereby completing the TSO verification.

[0049] Thirdly, the present invention provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in the present invention.

[0050] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0051] 1. Compared with existing TSO verification technologies that only verify TCP packets, the verification method proposed in this invention can generate packets of various protocol types by configuring the packet types at each layer of the packet structure. At the same time, by configuring the packet editing command, it can realize TSO multi-protocol compatible packet fragmentation verification, which has high applicability.

[0052] 2. The verification method proposed in this invention can realize the verification of message header modification of various protocols, TSO verification of different message lengths and different fragment lengths through internal random method or external parameter input configuration method. Attached Figure Description

[0053] The accompanying drawings, which are included to provide a further understanding of embodiments of the invention and form part of this application, do not constitute a limitation thereof. In the drawings:

[0054] Figure 1 This is a flowchart of the verification method according to an embodiment of the present invention.

[0055] Figure 2 This is a schematic diagram of the message structure in an embodiment of the present invention.

[0056] Figure 3 This is a schematic diagram of the segmentation in an embodiment of the present invention.

[0057] Figure 4 This is a block diagram illustrating the principle of the verification system according to an embodiment of the present invention. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the embodiments and accompanying drawings. The illustrative embodiments and descriptions of the present invention are only used to explain the present invention and are not intended to limit the present invention.

[0059] Example:

[0060] Existing TSO verification technologies typically only detect TCP packets and cannot be applied to other packet types, lacking versatility. Furthermore, verification technologies for GSO are not suitable for TSO verification that relies on hardware-based fragmentation. Therefore, this embodiment proposes a verification method that achieves multi-protocol compatibility for TSO. This proposed verification method is specifically for TSO verification and can be generated...

[0061] Specifically, such as Figure 1 As shown, the verification method proposed in this embodiment includes the following steps:

[0062] Step 1: Determine the message type of the corresponding layer by assigning values ​​to the key parameters that are pre-set for each layer of the message structure, thereby generating messages and simulating network card fragmentation;

[0063] Step 2: Generate message editing commands and add them to the message header;

[0064] Step 3: Transmit and receive messages.

[0065] Step 4: Send the received messages to the reference model for message editing to simulate the operation of the DUT.

[0066] Step 5: Compare the slices processed by the reference model with the slices processed by the DUT one by one to complete the TSO verification.

[0067] Furthermore, due to the need for compatibility with multiple protocols, the composition of messages needs to consider the combination of multi-layered structures. Specifically, for example... Figure 2 As shown, during message generation, random parameters are set for each layer to select a specified type. For example, the L3 layer sets the parameter `ip_ver` to represent the layer type. If `ip_ver` is set to 0, it represents an IPv4 message; if `ip_ver` is set to 1, it represents an IPv6 message. Similarly, the type of all layers can be randomized by using random key parameter values. Alternatively, based on specific application scenarios, judgment conditions can be used to generate corresponding message types and assign key parameter values ​​for corresponding layers. Furthermore, the key parameters of the obtained message structure are also used to generate corresponding editing commands.

[0068] It should be noted that, Figure 2 The BTH at layer L5 has a special structure that can connect via UDP or directly to IPv6. When constructing the BTH, it's important to consider the inclusion relationship between each layer of the message structure, typically using random parameters from the outermost layer to the innermost layer (from layer L2 to layer L6).

[0069] After generating the packet, it needs to be fragmented beforehand to simulate network interface card (NIC) fragmentation. Specifically, the packet fragmentation method is as follows: Under the constructed packet structure `xaction_a`, a dynamic array of type `xaction_a` is created. The size of the array is determined by the number of fragments, which can be randomly generated internally, depending on the size of the packet data portion and the fragment length. Both the packet length and fragment length can be passed as external parameters to indirectly specify the number of fragments. The fragmented packets can be stored in the array, while the payload of the packet structure itself can be 0.

[0070] Once the required message structure is obtained, it is necessary to understand which header parameters need to be modified for different fragments after fragmentation, such as... Figure 3As shown, fragments are typically categorized into three types: header, middle, and tail. The header fragment generally comes in two types: with a header and without a header. Since the header fragment's structure is equivalent to the entire packet's structure, the case with a header is the most common, meaning the entire packet consists of H (Header) + P (Payload). The case where the header fragment does not contain a header is more special, meaning the entire packet is entirely P; the middle fragment consists entirely of data, and the data length is uniform, so the processing method is the same; the tail fragment's length is variable and may be split into extremely small packets, thus significantly affecting the range of editing commands.

[0071] In this embodiment, the relevant TSO design environment is mainly divided into two types of editing commands: the first is the normal editing command (i.e., normal cmd), and the second is the TSO editing command (TSO cmd).

[0072] For ordinary editing commands, there are generally two operations: replacement and insertion, mainly updating the header of fragments. When TSO fragments are reassembled into smaller packets, different operations are performed for the first, middle, and last fragments. For the first fragment, since it usually carries a header, only the header needs to be replaced with `new_header`. For the middle and last fragments, since they only contain data, `new_header` needs to be inserted to form a complete packet. The verification parameters for ordinary editing commands include the offset position of the insertion point within the packet, the length of the editing command, and the offset position of the editing command. Different header lengths can be updated for fragment headers through external parameters or internal randomization.

[0073] TSO editing commands are primarily used to modify specific message header parameters. The main types of TSO editing commands are:

[0074] (1) Perform operations on the offset 1 bit to modify the PSH and FIN fields of the TCP layer for each fragment;

[0075] (2) Accumulate the 16-bit / 24-bit count after offset, and use it to modify the ID field of the IPv4 layer and the Sequence Number field of the BTH layer;

[0076] (3) Replace the 16 bits after the offset with the packet length plus the specified value, which is used to modify the TotalLength of the IPv4 layer;

[0077] (4) Accumulate the fragment field count for the offset 32 ​​bits to modify the Sequence Number of the TCP layer;

[0078] (5) Replace the 8 bits after the offset with the specified value, which can be used to modify the PSH and FIN parameters at the same time.

[0079] For the five TSO edit commands mentioned above, verifying each edit command individually requires complete randomization, such as random offset positions, fragment enable settings to be modified, and destination values. However, when verifying commands strongly related to the protocol, it is necessary to accurately assign values ​​to key parameters based on the constructed message type. It should be noted that the entire packet header, i.e., the header of the first fragment, is generally constructed as the initial value, so in most cases, no TSO edit command operations are performed on the first fragment.

[0080] In addition to the two editing commands, checksum calculation also needs attention, including calculations for IPv4 Header Checksum, TCP Checksum, and UDP Checksum. All checksum calculation commands can be simplified to calculating the start offset, end offset, and checksum field offset. When validating checksum commands, these three parameters can be completely randomized. However, it's crucial that the parameter constraints are within the packet length, and that the checksum field offset is included in the calculation to be used as the initial value for the checksum field (applicable in special scenarios where the checksum of a portion of the packet data is pre-calculated and used as the initial value).

[0081] Furthermore, after constructing the message and editing commands, it needs to be transmitted online via the driver. Since the slices have been pre-saved in the xaction array, only array elements need to be extracted for transmission. To distinguish the beginning and end of each slice, custom signals need to be placed at the beginning and end of each slice as markers.

[0082] When transmitting data, the length of each segment can be stored in advance. Once the segment length count is met, a segment end signal is set, and the corresponding segment information is transmitted. Simultaneously, the index of the transmitted data is incremented to ensure that the next transmitted segment is the next data segment. However, in this method, if the segment data length is not a full clock cycle, the portion exceeding the segment length will be all zeros. Therefore, to fully simulate the TSO segmentation scenario, the portion not exceeding a full clock cycle needs to be filled with random data (Bubble), while the valid data portion is indicated by a custom parameter (represented by trans_len in this embodiment) and transmitted along with the segment information. For example, if each clock cycle transmits 64 bytes of data, and trans_len is 30 bytes, it means that only the first 30 bytes of data in that clock cycle are valid data.

[0083] Conversely, when receiving messages, it is necessary to extract the `trans_len` parameter from the message information to extract valid data, thereby achieving the "bubble squeezing" behavior. After each fragmentation end signal is encountered, the currently received data is packaged into a small packet and stored in an array. At the same time, the data information of the corresponding fragment and the entire packet also needs to be updated.

[0084] Furthermore, the received messages are sent to the reference model to simulate the DUT (Design Under Test) operation. Since the received messages are already stored in fragments, it is only necessary to extract the elements of the fragment array and process them sequentially. Before processing each fragment, the message editing commands attached to the first fragment need to be extracted to obtain the editing operations required for each fragment. Each fragment first needs to perform a TSO editing operation on the new_header attached to the editing command to obtain the corresponding message header; then, a checksum calculation is performed to update the fields; finally, the obtained new_header is replaced or inserted into the corresponding position in the fragment data using a normal editing command to obtain a complete small packet.

[0085] The edited packets are compared one by one with the edited packets in the DUT (Design Under Test, e.g., a network card with TSO functionality) to achieve a complete TSO verification operation.

[0086] The verification method proposed in this embodiment is compatible with packet sending and header editing commands for multiple protocols, enabling TSO verification for various protocol types and improving the versatility of TSO verification technology. Furthermore, the verification method proposed in this embodiment has the function of randomly testing different fragment lengths and is applicable to testing scenarios where the first fragment does not carry a header.

[0087] Based on the same technical concept described above, this embodiment also proposes a verification system for achieving TSO multi-protocol compatibility, specifically as follows: Figure 4 As shown, the verification system proposed in this embodiment includes:

[0088] The packet sending module is configured to perform the following operations: determine the packet type of the corresponding layer by assigning values ​​to the key parameters preset in each layer of the packet structure, thereby generating packets and simulating network interface card fragmentation; generate packet editing commands and add them to the packet header;

[0089] The transceiver module is configured to perform the following operations: transmitting and receiving messages;

[0090] The reference module (RM module) is configured to perform the following operations: send the received messages to the reference model for message editing to simulate the operation of the DUT;

[0091] The comparison module is configured to perform the following operation: compare the fragments processed by the reference model with the fragments processed by the DUT one by one, thereby completing the TSO verification.

[0092] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0093] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0094] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0095] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0096] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A verification method for achieving TSO multi-protocol compatibility, characterized in that, The verification method includes: By assigning values ​​to key parameters pre-set at each layer of the message structure, the message type of the corresponding layer is determined, thereby generating messages and simulating network card fragmentation; Generate message editing commands and add them to the message header; To transmit and receive messages; The received messages are sent to the reference model for message editing to simulate the operation of the DUT; The TSO verification is completed by comparing the slices processed by the reference model with the slices processed by the DUT.

2. The verification method for achieving TSO multi-protocol compatibility according to claim 1, characterized in that, Assigning values ​​to key parameters that are pre-defined at each layer of the message structure, specifically including: The key parameters of each layer of the message structure are assigned values ​​through an internal randomization process; Alternatively, the corresponding message type can be generated and the key parameters of the corresponding layer can be assigned by judging the conditions.

3. The verification method for achieving TSO multi-protocol compatibility according to claim 1, characterized in that, Simulated network interface card (NIC) fragmentation specifically includes: A dynamic array is set for the corresponding constructed message structure; the size of the dynamic array is determined by the number of fragments; Each slice is stored in the dynamic array; The number of fragments is randomly generated, depending on the size of the message data portion and the fragment length; or the number of fragments is determined by externally input message length and fragment length.

4. The verification method for achieving TSO multi-protocol compatibility according to claim 1, characterized in that, The generated message editing commands include: general editing commands and TSO editing commands; The ordinary editing command is used to update the header portion of the fragment; The TSO edit command is used to modify specific message header parameters. The TSO edit command includes: A. Perform operations on the offset 1 bit to modify the PSH and FIN fields of the TCP layer for each fragment; B. Accumulate the 16-bit / 24-bit count after the offset, which is used to modify the ID field of the IPv4 layer and the SequenceNumber field of the BTH layer; C. Replace the 16 bits after the offset with the packet length plus a specified value, which is used to modify the Total Length field of the IPv4 layer; D. Accumulate the fragment length count for the 32 bits after the offset, which is used to modify the Sequence Number field of the TCP layer; E. Replace the 8 bits after the offset with the specified value, which is used to modify both the PSH and FIN fields simultaneously.

5. The verification method for achieving TSO multi-protocol compatibility according to claim 4, characterized in that, During verification, the parameters of the ordinary editing command and the TSO editing command are determined either by internal random generation or by external input parameters.

6. The verification method for achieving TSO multi-protocol compatibility according to claim 1, characterized in that, The transmission and reception of messages specifically includes: Set custom signals as markers at the beginning and end of each segment; When transmitting data, the length of each segment is stored in advance. After the segment length count is satisfied, the segment end signal is set and the corresponding segment information is transmitted. At the same time, the index of the transmitted data is incremented to ensure that the next transmitted data is the data of the next segment.

7. The verification method for achieving TSO multi-protocol compatibility according to claim 6, characterized in that, When transmitting data, fill the part that is not a full frame with random data, and set parameters to indicate the valid data part. The indicator parameters are transmitted along with the fragment information. Conversely, when receiving a message, it is necessary to extract the indicator parameters in the message information as indicators to extract valid data; after each fragmentation end signal is encountered, the currently received data is packaged into a small packet and stored in an array, while the data information of the corresponding fragment and the whole packet is updated.

8. The verification method for achieving TSO multi-protocol compatibility according to claim 7, characterized in that, After receiving the message, it is sent to the reference model for message editing operations, which specifically include: Extract the elements of the sliced ​​array and process them sequentially. Before processing each segment, the message editing commands contained in the first segment need to be extracted; Each fragment first performs a TSO edit operation on the new_header attached to the edit command to obtain the corresponding packet header; then it performs a checksum calculation to update the field; finally, it uses a normal edit command to replace or insert the obtained new_header into the corresponding position in the fragment data to obtain a complete small packet.

9. A verification system for achieving TSO multi-protocol compatibility, characterized in that, The verification system includes: The packet sending module is configured to perform the following operations: determine the packet type of the corresponding layer by assigning values ​​to the key parameters preset in each layer of the packet structure, thereby generating packets and simulating network interface card fragmentation; generate packet editing commands and add them to the packet header; A transceiver module, configured to perform the following operations: transmitting and receiving messages; The reference module is configured to perform the following operations: sending the received messages to the reference model for message editing to simulate the operation of the DUT; The comparison module is configured to perform the following operation: compare the fragments processed by the reference model with the fragments processed by the DUT one by one, thereby completing the TSO verification.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1-8.

Images