A message processing method and related device

Abstract

This application provides a message processing method and related equipment to ensure the flexibility of protocol parsing. The method includes: receiving a network message; caching the network message in hardware; extracting the message header information of the network message according to a preset length; extracting the content of a preset offset field according to preset rules to generate a first key value; matching a first template; if the first key value does not match the first template, entering a slow path parsing process to generate a slow path parsing result according to pre-configured protocol parsing rules; generating a protocol descriptor based on the slow path parsing result; synchronously transmitting the protocol descriptor and corresponding message data to the host, so that the host can restore the slow path parsing result based on the protocol descriptor, and send the restored protocol topology information to the application.

Description

Technical Field

[0001] The embodiments of this application relate to the field of message processing, and more particularly to a message processing method and related equipment. Background Technology

[0002] In smart NIC offloading technology, hardware offloading of transport layer L4 (such as TCP / IP) and lower protocols has become the norm. However, for L5-L7 application layer protocols, the existing architecture mainly has two modes: one is the software full parsing mode, where the hardware only processes up to L4, sending all raw data to the host, and the CPU software stack parses the application layer protocol from scratch. This process consumes a lot of CPU cycles and causes data path delays. The other is the hardware black box mode, where some cutting-edge solutions attempt to embed the processing logic of specific application layer protocols (such as HTTP) in the hardware. Although the performance is high, the software cannot know the intermediate state and precise location of the hardware parsing, and cannot flexibly support new or custom protocols.

[0003] In summary, the lack of a standardized hardware and software interaction mechanism regarding protocol semantics in existing technologies leads to the inability of hardware parsing results to be effectively reused by software, resulting in wasted CPU resources and poor protocol scalability. Summary of the Invention

[0004] This application provides a message processing method and related equipment to ensure efficient interaction between hardware and software protocols, thereby guaranteeing the flexibility of protocol parsing.

[0005] The first aspect of this application provides a message processing method, including:

[0006] Receive network packets, cache the network packets in hardware, and extract the packet header information of the network packets according to a preset length;

[0007] Based on the message header information, according to preset rules, the content of the preset offset field is extracted to generate a first key value;

[0008] Use the first key value to match the first template;

[0009] If the first key value does not match the first template, the slow path resolution process is initiated to generate a slow path resolution result based on the pre-configured protocol resolution rules. The slow path resolution result includes at least the protocol type of the network packet at different protocol layers, the protocol number of the current layer protocol at each protocol layer, and the starting offset of the current layer protocol in the network packet.

[0010] Based on the slow path resolution results, a protocol descriptor is generated; wherein, the protocol descriptor contains a protocol type bitmap and a protocol number-offset pair;

[0011] The protocol descriptor and the corresponding message data are synchronously transmitted to the host so that the host can restore the slow path resolution result based on the protocol descriptor and send the restored protocol topology information to the application.

[0012] A second aspect of this application provides a message processing apparatus, comprising:

[0013] The receiving unit is used to receive network packets, cache the network packets in hardware, and extract the packet header information of the network packets according to a preset length.

[0014] The extraction unit is used to extract the content of a preset offset field based on the message header information and according to preset rules, and generate a first key value;

[0015] A matching unit is used to match a first template using the first key value;

[0016] The parsing unit is used to enter the slow path parsing process when the first key value does not match the first template, so as to generate a slow path parsing result according to the pre-configured protocol parsing rules; wherein, the slow path parsing result includes at least the protocol type of the network packet at different protocol layers, the protocol number of the current layer protocol of each protocol layer and the starting offset of the current layer protocol in the network packet;

[0017] The generation unit is used to generate a protocol descriptor based on the slow path resolution result; wherein the protocol descriptor includes a protocol type bitmap and a protocol number-offset pair;

[0018] The transmission unit is used to synchronously transmit the protocol descriptor and the corresponding message data to the host, so that the host can restore the slow path resolution result based on the protocol descriptor and send the restored protocol topology information to the application.

[0019] The message processing apparatus provided in the second aspect of the embodiments of this application is used to execute the message processing method described in the first aspect.

[0020] A third aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the message processing method of the first aspect or any implementation thereof.

[0021] A fourth aspect of this application provides an electronic device, comprising at least one processor and a memory connected to the processor, wherein:

[0022] The memory is used to store computer programs;

[0023] The processor is used to execute the computer program so that the electronic device can implement the message processing method of the first aspect or any implementation thereof.

[0024] The fifth aspect of this application provides a computer storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to perform the message processing method described in the first aspect or any implementation thereof.

[0025] As can be seen from the above technical solutions, the embodiments of this application have the following advantages: The message processing method disclosed in this application realizes the association and reporting of hardware parsing results and message data. Specifically, it offloads the repetitive work of protocol parsing to hardware, significantly saving host CPU resources. Simultaneously, the software driver can directly reconstruct the protocol stack based on the descriptors, avoiding the computational overhead and data path latency caused by parsing each protocol layer from scratch. Furthermore, the synchronous transmission of protocol descriptors and message data ensures efficient interaction of protocol semantics between software and hardware, improving network processing performance while maintaining the flexibility and scalability of protocol parsing. Attached Figure Description

[0026] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0027] Figure 1 This is a schematic diagram of the architecture of a message processing system disclosed in an embodiment of this application;

[0028] Figure 2 This is a flowchart illustrating a message processing method disclosed in an embodiment of this application;

[0029] Figure 3 This is a flowchart illustrating another message processing method disclosed in an embodiment of this application;

[0030] Figure 4 This is a flowchart illustrating another message processing method disclosed in an embodiment of this application;

[0031] Figure 5 This is a flowchart illustrating another message processing method disclosed in an embodiment of this application;

[0032] Figure 6 This is a flowchart illustrating another message processing method disclosed in an embodiment of this application;

[0033] Figure 7This is a schematic diagram of a network message protocol parsing process disclosed in an embodiment of this application;

[0034] Figure 8 This is a schematic diagram of an example Ethernet data packet disclosed in an embodiment of this application;

[0035] Figure 9 This is a schematic diagram of the structure of a message processing apparatus disclosed in an embodiment of this application;

[0036] Figure 10 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application. Detailed Implementation

[0037] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0038] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0039] It should be noted that the use of terms such as "first" and "second" in this application is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of those features. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, such a combination of technical solutions should be considered non-existent and not within the scope of protection claimed in this application.

[0040] To solve the technical problems of the prior art mentioned above, please refer to [link / reference]. Figure 1 , Figure 1 This is a schematic diagram of the architecture of a message processing system disclosed in an embodiment of this application.

[0041] Depend on Figure 1As shown, the message processing system disclosed in this application embodiment may include a host 101 and hardware 102. The host 101 may have various software installed (or other applications, such as a host driver). The hardware 102 is a smart network interface card (NIC) hardware (specifically, a hardware parsing engine). The hardware 102 not only performs deep protocol parsing of network packets but also reports the parsed protocol stack to the software on the host 101 in real time in a lightweight and standardized manner.

[0042] It should be understood that, such as Figure 1 The hardware 102 shown can be equipped with multiple functional modules, such as a hardware cache module, a hardware protocol parsing module, or a direct memory access (DMA) engine.

[0043] Upon receiving a network packet, hardware 102 can cache the network packet using a hardware caching module (e.g., RAM cache). The hardware caching module extracts a predetermined length from the network packet and transmits it to a hardware protocol parsing module for protocol parsing, thereby generating a protocol descriptor. Subsequently, the DMA engine transmits this protocol descriptor to host 101 via an I / O interface.

[0044] To further understand Figure 1 For the workflow of the message processing system shown in the diagram, please refer to [link / reference needed]. Figure 2 , Figure 2 This is a flowchart illustrating a message processing method disclosed in an embodiment of this application. It includes steps 201-206.

[0045] 201. Receive network packets, cache the network packets in the hardware, and extract the packet header information of the network packets according to the preset length.

[0046] In some embodiments, the hardware (e.g., a smart network interface card) receives network packets (e.g., Ethernet packets) from the network side and first writes the complete network packet into a hardware cache module (such as on-chip RAM or a FIFO buffer). The hardware cache module is used to temporarily store the packet to match the speed difference between the subsequent hardware protocol parsing module and the DMA engine transfer, ensuring data integrity.

[0047] In some embodiments, to balance parsing efficiency and hardware resource consumption, the hardware caching module extracts the packet header information according to a preset maximum Ethernet protocol parsing length (128 bytes in this embodiment). If the packet length is less than 128 bytes, the entire packet is extracted. The extracted header data is sent to the hardware protocol parsing module for further processing.

[0048] 202. Based on the message header information and according to preset rules, extract the content of the preset offset field and generate the first key value.

[0049] In some embodiments, the hardware protocol parsing module directly extracts the content of a field at a specific fixed offset position in the Ethernet header in order to quickly determine common message types.

[0050] Specifically, in this embodiment, the hardware logic extracts the field content at the following offset positions in parallel:

[0051] Offset 12-13: Usually corresponds to the Ethernet type field (EtherType) or the tag protocol identifier (TPID) of the VLAN tag.

[0052] Offset 16-17: If a VLAN tag exists, this corresponds to the actual protocol type (such as IPv4 / IPv6) or the TPID of the second-level VLAN after the VLAN tag.

[0053] Offset 20-21: If a second-level VLAN exists, this corresponds to the actual protocol type after the VLAN tag (such as IPv4 / IPv6).

[0054] The hardware concatenates or combines the contents of the three fields to generate the first key value. This key value is used for subsequent fast matching in the Ternary Content Addressable Memory (TCAM).

[0055] 203. Use the first key value to match the first template.

[0056] In some embodiments, a first key value is used to match a first template. Specifically, the first template is implemented by TCAM and stores a limited number of template entries for quickly determining whether a packet contains IPv4 / IPv6 protocols and one or two layers of VLAN tags.

[0057] In some embodiments, the first template stores a limited number of template entries, each corresponding to a common message encapsulation pattern. When the first key value generated in step 202 (composed of the three fields Offset 12-13, Offset 16-17, and Offset 20-21) is sent to the TCAM, the TCAM compares all stored template entries in parallel within a single clock cycle, for example:

[0058] For each bit of each template entry, if the bit is 0 or 1, the corresponding bit of the first key value must be equal to it;

[0059] If the bit is anything else, the comparison of that bit is ignored, and it is considered a match regardless of whether the bit corresponding to the first key value is 0 or 1.

[0060] 204. If the first key value does not match the first template, proceed to the slow path resolution process to generate the slow path resolution result according to the pre-configured protocol resolution rules.

[0061] In some embodiments, if a match is not found (i.e., the first key value does not match the first template), it indicates that the message type is unknown or belongs to a non-standard encapsulation, and the process jumps to slow path processing. At this time, in the slow path processing flow, the CAM table and node configuration table (see [reference needed]) can be used. Figure 3 The collaborative operation of the illustrated embodiment sequentially identifies the protocol type of network packets at each protocol layer and records the protocol number of each layer and its starting offset in the network packet.

[0062] Taking a packet structure of MAC→VLAN→IPv4→TCP→HTTPS as an example, the specific execution process of slow path resolution can involve five layers of resolution. For details, please refer to [link / reference needed]. Figure 7 and Figure 8 The illustrated embodiment.

[0063] After parsing is complete, the system iterates through the parsing results of each round of records, generates a protocol type bitmap (sets the position corresponding to cur_proto_type to 1 in the bitmap), and generates a protocol number list (proto_id) and a protocol offset list (proto_offset) in sequence.

[0064] In other feasible technical solutions, if a match is found, it indicates that the packet belongs to a common encapsulation type (such as "VLAN+IPv4"), and the process enters the fast path processing (see [reference]). Figure 4 (Example shown).

[0065] 205. Generate a protocol descriptor based on the slow path resolution results.

[0066] In some embodiments, during the slow path resolution process, the system assembles a compact protocol descriptor based on the resolution results. This descriptor uses a fixed-format data structure and includes:

[0067] A 64-bit protocol type bitmap field indicates the protocol layer types appearing in the message. Up to eight "protocol number + offset" pairs are allowed, each containing an 8-bit protocol number field and an 8-bit offset field, arranged sequentially in parsing order. The total descriptor length is 24 bytes (192 bits), aligned with the smallest granularity of PCIe (DMA) transfers to ensure optimal transmission efficiency.

[0068] In other feasible technical solutions, a parsing result can also be obtained during the fast path parsing process. In this case, the system can assemble a compact protocol descriptor based on the parsing results of the fast path and the slow path. Details will not be elaborated here.

[0069] 206. Synchronously transmit the protocol descriptor and the corresponding message data to the host so that the host can restore the slow path resolution result based on the protocol descriptor and send the restored protocol topology information to the application.

[0070] In some embodiments, after the protocol descriptor is generated, the DMA engine associates the protocol descriptor with the corresponding original packet data (which can be understood as the network packet initially received above) and synchronously transmits it to a pre-allocated receive queue in the host memory. The association between the descriptor and the data is bound by pointers or indexes maintained by the hardware to ensure a one-to-one correspondence during software reception. Then, after the host driver obtains the protocol descriptor and packet data from the receive queue, it first reads the protocol type bitmap in the protocol descriptor and determines the number and order of protocol layers appearing in the packet based on the set bits in the bitmap. Next, it extracts the protocol number and offset of each layer from the protocol descriptor to reconstruct the complete protocol stack topology information. Finally, it associates the parsing result with the packet data and sends it to the application through a standard interface (such as socket or netlink). The application does not need to parse the packet again and can directly use the protocol location information provided by the hardware for deep packet inspection, traffic classification, or protocol processing.

[0071] This embodiment discloses a message processing method that extracts protocol identifiers and generates descriptors layer by layer through hardware, offloading the repetitive and patterned protocol parsing work originally performed by software to the network interface card (NIC) chip. Upon receiving the descriptor, the host driver directly reconstructs the parsing result without re-traversing the message header, significantly freeing up computing resources for business logic processing. Furthermore, the hardware completes protocol parsing simultaneously with message reception, and the descriptor is synchronously sent along with the data. The software driver can determine the type of each protocol layer and its precise offset within the message without additional parsing calculations, eliminating the extra memory reads and instruction execution required for software parsing. Secondly, the protocol descriptor reports the hardware parsing results in a standardized format, allowing the software to completely reconstruct the hardware parsing process, achieving a balance between hardware acceleration and software flexibility. Moreover, the protocol descriptor and message data are synchronously transmitted via DMA, existing as an associative pair in the host memory, eliminating the need for additional synchronization or matching operations by the driver software. This design enables upper-layer applications to synchronously obtain the protocol semantic information provided by the hardware, just like accessing ordinary message data, without modifying the existing network protocol stack architecture. Developers only need to add descriptor resolution logic to the driver layer to seamlessly integrate hardware acceleration capabilities into existing systems, significantly reducing the migration costs of introducing hardware offloading technology.

[0072] Please see Figure 3 , Figure 3 This is a schematic flowchart of another message processing method disclosed in an embodiment of this application. It includes steps 301-310.

[0073] 301. Configure the CAM table.

[0074] In this embodiment, the pre-configured protocol parsing rules are implemented through two hardware configurable tables: the Node Configuration Table and the Content Addressable Memory Table (CAM).

[0075] In some embodiments, the CAM table includes at least the current node number of the current protocol at the current protocol layer, the current protocol number, the current protocol type bitmap information, the next protocol identifier pointing to the next protocol corresponding to the next protocol at the next protocol layer, the next node identifier, and whether the table lookup is terminated.

[0076] In some embodiments, CAM entries can be defined as shown in Table 1 below:

[0077]

[0078] With the above configuration, the hardware can quickly look up the table to determine the type of the current protocol, the bitmap position, and the next hop parsing node in each parsing cycle, based on the current node and the extracted protocol identifier.

[0079] 302. Configure the node configuration table.

[0080] In some embodiments, the node configuration table is used to define the method for extracting the "protocol identifier" in the current protocol layer. Each node corresponds to a protocol layer state. The node configuration table includes at least the current node number, the offset of the next protocol identifier within the current protocol, the field length of the next protocol identifier, and the current protocol length.

[0081] In some embodiments, the node configuration table is defined as shown in Table 2 below:

[0082]

[0083] With the above configuration, the hardware can extract an identifier pointing to the next layer protocol from a specified location in any protocol layer.

[0084] 303. Initialize the parsing process, set the current node identifier of the current protocol layer to the initial value, and set the current header offset to 0.

[0085] In this embodiment, the process of parsing network packets layer by layer is described in detail.

[0086] In some embodiments, when a network packet cannot be resolved via the fast path (i.e., the first template is not found or the second template hash table is not found), the system initiates a slow path resolution process. First, the resolution state is initialized.

[0087] Specifically, setting the current node identifier (nodeid) to 0 indicates that parsing begins from the preset initial parsing node (usually the MAC layer). Setting the current header offset (head_offset) to 0 indicates that the current protocol header starts from the first byte of the network packet. The initialization operation is performed by the hardware state machine and completed within a single clock cycle, ensuring a fast start of the parsing process.

[0088] 304. Extract the next protocol identifier from the specified offset position of the current message according to the current node identifier index node configuration table.

[0089] In some embodiments, the protocol identifier of the next layer protocol is extracted from a specified offset position in the packet based on the current node identifier (nodeid) index node configuration table. The node configuration table is one of the core configuration data structures of this invention, and each entry corresponds to a protocol layer node, as detailed in Table 2 above.

[0090] In some embodiments, taking MAC layer parsing as an example (nodeid=0):

[0091] Based on the entry in the node configuration table where Cur_node=0, the hardware can determine that Next_protocol_offset=96 bits and Next_protocol_field_len=16 bits. It reads data starting at byte 12 (head_offset + (Next_protocol_offset / 8) = 0 + 12 = 12) from the packet buffer. It then extracts 16 bits (2 bytes) of this data to obtain the protocol identifier for the next layer protocol.

[0092] In the MAC→VLAN→IPv4→TCP→HTTPS message in this embodiment, the protocol identifier extracted by the MAC layer is 0x8100 (representing the IEEE 802.1Q VLAN tag).

[0093] 305. Construct a third key value based on the current node identifier and the next protocol identifier, and look up the CAM table.

[0094] In some embodiments, a key value is constructed based on the current node identifier (nodeid) and the next protocol identifier (Next_protocol) extracted in step 304, and this key value is used to look up the CAM table. The CAM table is another core configuration data structure in this application embodiment, as detailed in Table 1.

[0095] In some embodiments, in the first round of parsing in this embodiment, the key value is (Cur_node=0, Next_protocol=0x8100), and the corresponding entry is found after searching the CAM table.

[0096] Furthermore, step 306 or step 310 are executed respectively based on the hit result.

[0097] 306. When the CAM table is hit, record the protocol number, protocol type and current header offset of the current protocol, and update the current header offset according to the current protocol length.

[0098] In some embodiments, if the CAM table is matched (i.e., the lookup is successful in step 305), the hardware performs a recording and update operation. Specifically, it needs to record the current protocol information and update the header offset.

[0099] In some specific embodiments, during the process of recording the current protocol information, it is necessary to (1) record the current protocol number (cur_proto_id): for example, the MAC layer protocol number is 1. (2) record the current protocol type bitmap position (cur_proto_type): for example, the corresponding bit 0 for the MAC layer. (3) record the current header offset (head_offset): the starting byte position of the current protocol header in the message. The above information is temporarily stored in the hardware result buffer for use in generating descriptors after parsing.

[0100] During the process of updating the header offset information, the header offset can be updated according to the Cur_len field of the current protocol in the node configuration table. For example, head_offset = head_offset + Cur_len. Taking the MAC layer as an example, Cur_len = 14 bytes, after the update head_offset = 0 + 14 = 14 bytes, pointing to the start position of the VLAN header.

[0101] 307. Determine whether the end-of-lookup flag in the CAM table is the final-level protocol flag.

[0102] In some embodiments, the lookup end flag (Is_last) in the CAM table entry is checked to see if it is a related final-level protocol flag. Then, step 308 or step 309 is executed according to the determination result.

[0103] 308. If the table lookup termination flag is a last-level protocol identifier, then the resolution is terminated.

[0104] In some embodiments, if Is_last=1 at this time, it means that the current protocol is the innermost protocol of the network message (such as the HTTPS layer), and there is no need to continue parsing. The layer-by-layer parsing process is terminated, and the process jumps to the descriptor generation step, that is, step 205 is executed.

[0105] 309. If the table lookup termination flag is not the last-level protocol flag, update the current node flag to the next node flag.

[0106] In some embodiments, if Is_last=0 at this time, it indicates that the current protocol is not the last-level protocol, and the next layer needs to be parsed. At this time, the current node identifier needs to be updated to Next_node in the CAM table entry, and the process returns to step 304 to start the next round of parsing.

[0107] In the MAC layer parsing of this embodiment, Is_last=0, so nodeid=1 (VLAN layer node) is updated, and the process returns to step S202 to continue parsing.

[0108] 310. If the CAM table is not found, the parsing process of the current message is terminated.

[0109] In some embodiments, if a lookup of the CAM table using the current key value fails (lookup failure in step 305), it indicates that the hardware cannot recognize the current protocol or the message format is abnormal. In this case, the hardware protocol parsing module immediately terminates the parsing process for the current message. The result buffer contains only the successfully parsed portion of the protocol information, and a truncated flag is set in the protocol descriptor to notify the host driver that the parsing is incomplete. Subsequently, after receiving the descriptor, the host driver can choose to fall back to software parsing for fallback processing, depending on its configuration.

[0110] To facilitate Figure 3 The illustrated embodiment is provided for understanding, using a complete parsing process example (MAC→VLAN→IPv4→TCP→HTTPS). See subsequent sections for details. Figure 8 The illustrated embodiment.

[0111] After parsing is complete, the result buffer stores the layer numbers and offsets of the five protocols in sequence:

[0112] Proto_id0=1, Proto_offset0=0 (MAC layer);

[0113] Proto_id1=3, Proto_offset1=14 (VLAN layer);

[0114] Proto_id2=32, Proto_offset2=18 (IPv4 layer);

[0115] Proto_id3=49, Proto_offset3=38 (TCP layer);

[0116] Proto_id4=103, Proto_offset4=58 (HTTPS layer).

[0117] At the same time, the bits corresponding to cur_proto_type (0, 1, 3, 13, 56) in the protocol type bitmap are set to 1 to generate the final bitmap value.

[0118] The message processing method disclosed in this embodiment employs a parsing mechanism of "extracting protocol identifiers → searching CAM → updating nodes → continuing iterations," automatically advancing to the next layer after each layer is parsed, until the Is_last flag is 1. This means that regardless of the number of nested layers in the protocol stack, as long as the corresponding key-value pairs are pre-configured in the CAM table, the hardware can parse and record the protocol number and offset of each layer layer by layer. Furthermore, the node configuration table defines the protocol identifier (offset position, field length, current protocol length), and the CAM table defines the protocol semantics (protocol number, type bitmap position, next node). This separation design means that the same set of node configuration tables can be shared by multiple CAM entries; only different entries need to be configured in the CAM table for each protocol. Simultaneously, when the hardware encounters an unrecognized protocol identifier, the CAM table lookup will inevitably fail. This embodiment designs a mechanism to immediately terminate the parsing process when a match is found, preventing hardware resources from being wasted on abnormal or unknown protocol messages. At the same time, the existing parsing results in the protocol descriptor remain valid, and a truncation flag is set to notify the host driver. Finally, through a dynamic offset accumulation mechanism, the starting offset of each protocol header in the original message is accurately calculated. The final recorded offset values ​​enable the host driver to directly locate the precise position of each protocol header, extracting specific fields from each header without re-parsing the message, further reducing software processing overhead.

[0119] Please see Figure 4 , Figure 4 This is a schematic flowchart of another message processing method disclosed in an embodiment of this application. It includes steps 401-405.

[0120] 401. If the first key value matches the first template, the fast path resolution process is initiated to extract the target offset field content of the corresponding network packet preset in the first template, and generate the second key value based on the target offset field content.

[0121] In some embodiments, after a hit in step 203, it indicates that the packet belongs to a common encapsulation type (such as "VLAN+IPv4"), and the process enters fast path processing. At this time, the hardware extracts deeper fields from the packet according to the preset instructions of the hit template (e.g., the "VLAN+IPv4" rule). In this embodiment, the template indicates the extraction of IP 5-tuple information, including: source IP address, destination IP address, protocol number, source port number, and destination port number. These fields are concatenated to generate a second key value.

[0122]

[0123] The hardware reads the above fields from the message buffer, concatenates them in a preset order, and generates a fixed-length second key value (104 bits in this embodiment).

[0124] 402. Calculate the second key value using a preset hash algorithm to obtain the first hash value.

[0125] In some embodiments, the hardware uses a specific hash algorithm (such as CRC32 or Toeplitz hash algorithm) to calculate the second key value to obtain a first hash value. This hash value is used as an index to look up the second template hash table.

[0126] Taking CRC32 as an example, the hardware inputs the 104-bit second key value into the CRC32 calculation unit and outputs the 32-bit first hash value in a single clock cycle.

[0127] 403. Match the second template hash table using the first hash value.

[0128] In some embodiments, the second template hash table is stored in SRAM to cache historical parsing results. The first hash value calculated above is used to match the second template hash table. Then, depending on the matching result, step 404 or step 405 is executed respectively.

[0129] In some embodiments, the data structure of its second template hash table is as follows:

[0130]

[0131] The Key is designed to be compatible with IPv6 and is typically 296 bits in size (128 bits (IPv6 source address) + 128 bits (IPv6 destination address) + 8 bits (protocol number) + 16 bits (source port number) + 16 bits (destination port number)).

[0132] In this embodiment, to simplify hardware implementation and ensure deterministic latency, a direct mapping structure with a fixed number of buckets is adopted. The lower N bits of the hash value are used as the bucket index, and each bucket stores one entry. The lower N bits of the first hash value are used as the index to locate the corresponding bucket in the hash table. For example, if the hash table contains 1024 buckets, the lower 10 bits (bits 0-9) of the hash value are used as the bucket index. The entry stored in the target bucket is read, and the Key field in the entry is compared with the second key value. Then, based on the matching result, steps 404 or 405 are executed respectively.

[0133] 404. If the first hash value matches the second template hash table, obtain the pre-stored fast path resolution result and execute the step of generating a protocol descriptor.

[0134] In some embodiments, if a match is found, it indicates that the message stream corresponding to the 5-tuple has been previously parsed, and the hash value already contains an entry in the hash table. The hardware directly reads the previously stored parsing results (including the protocol type bitmap, protocol number list, and offset list) from this entry, without performing complex layer-by-layer protocol parsing, and the process jumps directly to step 205 (descriptor generation).

[0135] In some embodiments, if the key values ​​are equal and the Valid flag is 1, it indicates a match. In this case, the hardware directly reads the pre-stored protocol parsing result (Value) from the hash table entry, including: a 64-bit protocol type bitmap; up to 8 pairs of protocol numbers and offsets; the parsing result is directly passed to the hardware protocol parsing module (step 205); the process skips the complete slow path layer-by-layer parsing and directly enters the descriptor generation step.

[0136] 405. If the first hash value does not match the second template hash table, proceed with the steps to enter the slow path resolution process.

[0137] In some embodiments, if a match is not found, it means that the message flow corresponding to the 5-tuple is appearing for the first time (new connection), and there is no corresponding entry in the hash table. The process jumps to step 204 to start slow path resolution.

[0138] In some embodiments, if the key-value comparison is not equal or the Valid flag is 0, it indicates a match failure. In this case, it is considered that the flow corresponding to the network packet is appearing for the first time (new connection), and there is no cached result in the hash table; the process jumps to slow path processing (step 204), performing a complete layer-by-layer protocol parsing; after the slow path parsing is completed, the update process is triggered (i.e., ...). Figure 5 (As shown in the embodiment), the parsing result is filled back into the hash table for use in subsequent messages.

[0139] The message processing method disclosed in this embodiment can obtain the complete parsing result through a single hash lookup. That is, for a known stream, the parsing complexity is reduced from... Reduced to This significantly improves packet throughput in high-bandwidth environments. The selected hash algorithm has a small hardware implementation area and low latency, and can complete calculations without increasing pipeline depth, ensuring deterministic low latency for fast paths. Slow path resolution results are automatically refilled into the hash table, and the software can dynamically configure hash table parameters to flexibly adapt to different traffic models.

[0140] Please see Figure 5 , Figure 3 This is a flowchart illustrating another message processing method disclosed in an embodiment of this application. It includes steps 501-502.

[0141] 501. After slow path resolution is completed, determine whether the current packet contains a valid network protocol IP address or 5-tuple information.

[0142] In some embodiments, after the slow path resolution process (step 204) is completed, step 501 is executed to determine whether the current packet meets the learning and update conditions. Specifically, there are at least three determination logics:

[0143] Condition 1: Does it contain a valid IP address?

[0144] Condition 2: Whether it contains valid quintuple information.

[0145] Condition 3: Five-tuple integrity check.

[0146] 502. If contained, extract the valid IP address or 5-tuple information, generate a second hash value using a preset hash algorithm, and update the second template hash table with the slow path resolution result as the associated storage value of the second hash value.

[0147] In some embodiments, based on condition one, it is checked whether the IPv4 or IPv6 protocol layer is successfully identified in the slow path resolution result. If the identification is successful, the source IP address and destination IP address are extracted from the resolution result, and their validity is verified (e.g., checking whether the IP address is an illegal value such as 0.0.0.0 or a broadcast address).

[0148] Based on condition two, after confirming the IP address is valid, further checks are performed to see if the TCP or UDP protocol layer is identified. If identification is successful, the source and destination port numbers are extracted from the parsing results. The five fields—source IP, destination IP, protocol number (TCP=6 or UDP=17), source port, and destination port—are combined to form a complete 5-tuple of information.

[0149] Based on condition three, check whether the values ​​of each field are within the legal range, or check whether the message is complete (e.g., whether the TCP header has been truncated).

[0150] If all the above conditions are met, the current packet is determined to contain a valid IP address or 5-tuple information. Otherwise, skip the learning update and proceed directly to step 205 to generate and upload the descriptor.

[0151] The packet processing method disclosed in this embodiment uniquely identifies a network connection using a 5-tuple (source / destination IP, protocol number, source / destination port). This tuple serves as the key for a hash table, ensuring that all packets within the same connection share the parsing result and maximizing cache hit benefits. Furthermore, after the first packet undergoes complete slow path parsing, the result is automatically refilled into the hash table, allowing subsequent packets to directly hit the fast path. This closed-loop mechanism enables hardware to continuously optimize performance without software intervention, adapting to real-time changing traffic models.

[0152] Please see Figure 6 , Figure 6 This is a flowchart illustrating another message processing method disclosed in an embodiment of this application. It includes steps 601-606.

[0153] 601. Get the protocol type bitmap field.

[0154] This embodiment mainly describes the specific process of the host driver restoring the hardware parsing results.

[0155] In some embodiments, the protocol descriptor is a compact, fixed-length data structure designed to carry a sufficiently complete protocol parsing result while minimizing transmission overhead, enabling the host driver to efficiently reconstruct the hardware parsing information.

[0156] First, the protocol type bitmap field in the protocol descriptor is retrieved. Specifically, the beginning of the protocol descriptor is a 64-bit protocol type bitmap field (Type Bitmap[63:0]). Each bit in this bitmap is pre-associated with a specific protocol layer type (e.g., bit 0 corresponds to the MAC layer, bit 1 to the IPv4 layer, bit 13 to the TCP layer, and bit 56 to the HTTPS layer). When the hardware parsing module successfully identifies a protocol layer, it sets the bit corresponding to that protocol to 1. By reading this bitmap, the host driver can quickly determine which protocol layers appear in the packet without having to check the protocol number field one by one.

[0157] Secondly, the bitmap design also supports sequential encoding of protocol layers. For example, the order in which the bits are set in the bitmap from left to right (or from least significant bit to most significant bit) corresponds exactly to the parsing order of the message protocol stack from the outside to the inside. For example, if bits 0, 1, 13, and 56 are set in sequence, it indicates that the protocol stack is MAC layer → IPv4 layer → TCP layer → HTTPS layer.

[0158] 602. Obtain multiple protocol number and offset pairs, and store the protocol number of each protocol layer and the starting offset of each protocol number in the network packet in the parsing order.

[0159] In some embodiments, following the bitmap field, the descriptor sequentially arranges multiple sets of "protocol number + offset" pairs. Each set contains:

[0160]

[0161] The protocol number uses a globally unified encoding, covering common protocols from L2 to L7 (including Ethernet, IPv4, IPv6, TCP, UDP, HTTP, HTTPS, etc.), and reserves encoding space for custom protocols.

[0162] In other feasible technical solutions, the number of protocol layers can be controlled to not exceed 8 layers, that is, designing 8 sets of protocol number and offset pairs. Furthermore, each set of protocol number and offset pairs in the protocol descriptor contains an 8-bit protocol number field and an 8-bit offset field, which are arranged sequentially after the protocol type bitmap field.

[0163]

[0164] The descriptor has a total length of 24 bytes (192 bits), aligned with the smallest granularity of standard DMA engine transfers to ensure optimal transmission efficiency. If the actual number of parsed protocol layers is less than 8, unused bytes can be filled with 0, and the host driver determines the number of valid groups based on the number of bits set in the bitmap.

[0165] 603. Read the protocol type bitmap field in the protocol descriptor.

[0166] In some embodiments, the host driver first reads the first 8 bytes of the protocol descriptor, specifically the protocol type bitmap field. In some embodiments, the protocol type bitmap field is used to indicate the protocol type of each protocol layer appearing in the network packet.

[0167] By scanning the 64-bit integer bit by bit (or using bit scan instructions), the host driver can quickly determine the number and position of the set bits in the bitmap.

[0168] 604. Determine the number of protocol layers and the protocol type of each protocol layer in the network packet based on the set bits in the protocol type bitmap field.

[0169] In some embodiments, based on the set bits in the bitmap, the driver maps each set position to a specific protocol layer type according to a predefined mapping table (stored in the driver or loaded via software configuration). For example:

[0170] Set bit 0 → Protocol type = MAC;

[0171] Set bit 1 → Protocol type = IPv4;

[0172] Set bit 13 → Protocol type = TCP;

[0173] Bit 56 is set → Protocol type = HTTPS.

[0174] The order in which bits are set in the bitmap is the parsing order of the protocol stack from the outer layer to the inner layer.

[0175] 605. Extract the protocol number and offset of each protocol layer from the protocol descriptor in sequence.

[0176] In some embodiments, the driver reads N groups of (Proto_id, Proto_offset) pairs sequentially, starting from a byte offset of 8 in the descriptor, based on the number of bits set in the bitmap, N (N≤8). The Proto_id in each group is used to verify or supplement protocol type information (which can be cross-checked with the bitmap mapping result). The Proto_offset directly indicates the starting byte position of the protocol header in the original message data.

[0177] The final parsing result generated by the hardware is shown in Table 3, with protocol descriptor information as shown.

[0178]

[0179] 606. Associate the restored protocol topology information with the message data for use by applications within the host.

[0180] The driver associates the reconstructed protocol stack topology information (protocol list and offsets for each layer) with the raw message data obtained from the DMA buffer, constructing a metadata structure containing "data pointer + length + protocol descriptor parsing result". Subsequently, this metadata structure is sent to the application via the I / O interface. Upon receiving this structure, the application can directly use the `Proto_offset` value to locate the protocol headers of each layer, extracting the required fields without re-parseing the message. For example:

[0181] Use Proto_offset[2] (TCP layer offset) + offset 16 to directly read the TCP window size;

[0182] Use Proto_offset[3] (HTTPS layer offset) to directly access the HTTP request header.

[0183] The message processing method disclosed in this application, by aligning the protocol type bitmap and related protocol number + offset pairs in the defined protocol descriptor with the granularity of DMA engine transmission, can effectively reduce transmission overhead and simplify DMA engine design. Furthermore, the protocol type bitmap uses one bit to represent one protocol layer, and a 64-bit bitmap can represent 64 different protocol layers, covering all common protocols from L2 to L7. The host driver can obtain the complete topology of the protocol stack through a single bit scan instruction. Simultaneously, the 8-bit offset field supports an offset range of 0 to 255 bytes, sufficient to cover a maximum header length of 256 bytes, meeting the header depth requirements of most network packets.

[0184] In combination with the above Figures 2 to 6 The illustrated embodiment can be referred to. Figure 7 , Figure 7This is a schematic flowchart illustrating a network message protocol parsing method disclosed in an embodiment of this application. It includes steps 701-717. Wherein, as... Figure 7 The image shows a method for parsing network message protocols and reporting results, namely the one described above. Figures 2 to 6 The overall process of one possible solution shown in the embodiment is as follows. Specifically, it includes the following steps.

[0185] 701. After receiving network packets, the network card caches the packets in the packet cache module of the hardware RAM and extracts the Ethernet header information according to the preset maximum Ethernet protocol parsing length.

[0186] 702. Based on the Ethernet header information, extract the content of the fixed offset field according to preset rules to generate the first key value;

[0187] 703. Match the first key value with the first template. The first template is implemented by TCAM and stores a limited number of template entries to quickly determine whether the packet contains IPv4 / IPv6 protocol and Layer 1 or Layer 2 VLAN tag. If a match is found, proceed to step 704. If no match is found, jump to step 707 to perform slow path resolution.

[0188] 704. Based on the template entry hit in step 703, extract the content of the preset message offset field of the template, generate a second key value, and calculate the hash value of the second key value (referred to as the first hash value) using a hash algorithm.

[0189] 705. Match the first hash value with the second template hash table; if a match is found, proceed to step 706; if no match is found, proceed to step 707 to perform slow path resolution.

[0190] 706. Based on the entries in the second template hash table that correspond to the first hash value, directly generate the protocol parsing result and jump to step 717;

[0191] 707. Start the layer-by-layer parsing process of the protocol parsing module and initialize the parsing state: set the current node identifier (nodeid) to 0 and the current header offset (head offset) to 0; start parsing from the MAC header, index the pre-configured node identifier configuration table (as shown in Table 2), and extract the protocol number of the subsequent protocol to be parsed from the message according to the table entries;

[0192] 708. Based on the next protocol's protocol number and the current nodeid, look up the CAM table (as shown in Table 1).

[0193] 709. Determine the CAM table lookup result: If a CAM table entry is found, proceed to step 710; otherwise, proceed to step 714.

[0194] 710. Based on the matched CAM table entry configuration, record the current protocol identifier (cur_proto_id), the current protocol type (cur_proto_type), and the current header offset (head_offset);

[0195] 711. Determine if the current protocol is the last-level protocol: If the CAM entry indicates that the current protocol is the last-level protocol (is_last=1), then terminate the layer-by-layer parsing process and jump to step 714; otherwise, execute step 712.

[0196] 712. Update the header offset of the next protocol: Increase the current header offset by the current protocol length (LEN).

[0197] 713. Update the node identifier (next_node) of the next parsed node, and return to step 707 to continue the layer-by-layer parsing;

[0198] 714. Traverse the parsing results recorded in step 710, mark the offset position corresponding to cur_proto_type as 1 in the bitmap, and generate the protocol identifier list (proto_id) and protocol offset table (proto_offset) in sequence (as shown in Table 3). The final generated bitmap is used by the software to quickly locate the current message information, and uses the specific information recorded by proto_id and proto_offset as needed.

[0199] 715. Based on the parsing results of steps 707 to 713, determine whether the packet contains a valid IP address or 5-tuple information; if it does, proceed to step 716; otherwise, proceed to step 717.

[0200] 716. Extract valid IP address or 5-tuple information, generate hash value using the same hash algorithm as in step 704, and update the second template hash table with the protocol identifier list and offset table generated in step 714 as the associated storage value of the hash value.

[0201] 717. Based on the parsing result directly generated in step 706 or the layer-by-layer parsing result from steps 707 to 713, generate a message descriptor and send it to the host software.

[0202] Finally, after receiving the descriptor, the software reconstructs the protocol topology, each protocol number, and the protocol offset in the packet according to the configured type and protoid information, and sends the reconstructed information to the application. This reduces the overhead of the software repeatedly parsing the protocol.

[0203] In one of the feasible technical solutions, the above-mentioned Figure 7 For reference Figure 8 , Figure 8This is a schematic diagram of an example Ethernet data packet disclosed in an embodiment of this application. Figure 8 Taking a packet received via MAC→VLAN→IPv4→TCP→HTTPS as an example, the following will explain in detail. Figure 7 and Figure 8 The combined flowchart.

[0204] 701: Message buffer, and extracts the message as the header for parsing according to the preset maximum length.

[0205] 702: In this embodiment, to quickly determine common packet types, the hardware parsing engine directly extracts a specific fixed offset field from the Ethernet header. The hardware logic extracts the field content at the following offset positions in parallel:

[0206] Offset 12–13: Typically corresponds to the Ethernet Type field (EtherType) or the TPID (Tag Protocol Identifier) ​​of the VLAN tag.

[0207] Offset 16–17: If a VLAN tag exists, this usually corresponds to the actual protocol type (such as IPv4 / IPv6) or the TPID of the second-level VLAN after the VLAN tag.

[0208] Offset 20–21: If a second-level VLAN exists, this usually corresponds to the actual protocol type (such as IPv4 / IPv6) after the VLAN tag.

[0209] The hardware concatenates or combines the contents of the above three fields to generate the first key value.

[0210] 703: The generated first key-value pair is sent to TCAM for parallel lookup. TCAM has a pre-configured first template table that stores common message encapsulation patterns. In this example, it matches the following TCAM rules:

[0211]

[0212] At this point, the first key value matches Rule 1 in Table 1 perfectly. The TCAM outputs a hit signal, indicating that the packet belongs to the "VLAN + IPv4" type. The process then jumps to 704 to proceed with fast path processing. If the packet is of unknown type or there is no corresponding template in the TCAM, it jumps to 707 to proceed with slow path resolution.

[0213] 704: When a 703 hit occurs, the hardware extracts deeper fields from the packet (e.g., the IP 5-tuple: source IP, destination IP, protocol number, source port, destination port) according to the preset instructions of the hit template (e.g., rule 1), generating a second key value. The hardware uses a specific hash algorithm (such as CRC32 or Toeplitz) to calculate the second key value, obtaining a first hash value. This hash value is used as an index to look up the second template hash table. This hash table is stored in SRAM to cache historical parsing results.

[0214] 705: If the 5-tuple message has been parsed before, the hash table will contain an entry corresponding to the hash value. The hardware directly reads the previously stored parsing result (bitmap, proto_id, and proto_offset information) from this entry. The process jumps directly to 717, eliminating the need for complex protocol parsing and greatly improving efficiency. If this is the first time the 5-tuple has been encountered (i.e., a new connection), there is no corresponding entry in the hash table. In this case, the process jumps to 707, initiating slow path resolution.

[0215] Slow path resolution (including steps 707-714):

[0216] The system initializes the parsing environment, setting: current node identifier (nodeid) = 0 (indicating the starting parsing node is the MAC layer); current header offset (head_offset) = 0 (indicating parsing starts from the beginning of the packet). First round of parsing: MAC layer protocol identification (Nodeid = 0).

[0217] 707: Extract the next protocol number.

[0218] The system uses the current nodeid=0 inode configuration table (Table 4). According to the table entry configuration, the next protocol number of the MAC layer protocol is located at the current head_offset plus the preset Next_protocol_offset. In this embodiment, Next_protocol_offset is configured as 96 bits (i.e., 12 bytes). The hardware reads 16 bits (2 bytes) of data from the packet offset 0+12=12 bytes and extracts the next protocol number as 0x8100 (representing the IEEE 802.1Q VLAN tag).

[0219] 708: Search the CAM table. The system uses the extracted next protocol number 0x8100 and the current node identifier 0 as keywords to search the CAM table (Table 5).

[0220] 709: A matching entry exists in the CAM table, indicating a match, proceed to step 710.

[0221] 710: Based on the configuration of the matched CAM entries, the system records the following resolution status:

[0222] Current protocol identifier (cur_proto_id) = 1 (corresponding to MAC layer protocol); current protocol type (cur_proto_type) = 0 (indicating layer 2 protocol); current header offset (head_offset) = 0.

[0223] 711: The flag bit is_last=0 configured in the CAM entry indicates that the current protocol is not the last-level protocol and it is still necessary to continue parsing the lower-level protocol. Proceed to step 712.

[0224] 712: According to the MAC layer protocol definition, its fixed header length cur_len = 14 bytes. The system updates the header offset: head_offset = 0 + 14 = 14.

[0225] 713: Based on the CAM table entry configuration, obtain the next node identifier (next_node) = 1. The system updates nodeid to 1 and jumps back to step 707 to start the next round of parsing.

[0226] Second round of resolution: VLAN layer resolution (Nodeid=1):

[0227] 707: The system extracts the next protocol number based on the inode configuration table with nodeid=1.

[0228] 708-710: CAM table hit, records: cur_proto_id=[VLAN protocol ID]; cur_proto_type=[VLAN type]; head_offset=14.

[0229] 711: is_last=0 (not the last level).

[0230] 712: The VLAN header length of head_offset has been increased by 4 bytes and updated to 18.

[0231] 713: Update next_node=3, jump to 707.

[0232] Third round of resolution: IPv4 layer resolution (Nodeid=3):

[0233] 707-710: CAM table hit, records: cur_proto_id=[IPv4 protocol ID]; cur_proto_type=3 (indicating Layer 3 IP protocol); head_offset=18.

[0234] 711: is_last=0.

[0235] 712: The IPv4 header length has been increased by 20 bytes in head_offset, now updated to 38.

[0236] 713: Update next_node=8, jump to 707.

[0237] Fourth round of parsing: TCP layer parsing (Nodeid=8):

[0238] 707-710: Hit the CAM table, records: cur_proto_id=49 (corresponding to TCP protocol); cur_proto_type=13 (indicating the fourth transport layer protocol); head_offset=38.

[0239] 711: is_last=0.

[0240] 712: The TCP header length of head_offset has been increased by 20 bytes, updated to 58.

[0241] 713: Update next_node=40, jump to 707.

[0242] Fifth round of resolution: HTTPS layer resolution (Nodeid=40):

[0243] 707-710: Hit the CAM table, record: cur_proto_id=103 (corresponds to HTTPS application layer protocol); cur_proto_type=56 (indicates application layer protocol); head_offset=58.

[0244] 711: The CAM entry is 1, indicating that the current protocol is a last-level protocol and no further parsing is required. The system jumps to step 714.

[0245] Learning updates and reporting (including steps 715-717):

[0246] 714: The system iterates through the cur_proto_type records of each round (MAC, VLAN, IPv4, TCP, HTTPS), generates a protocol type bitmap (sets the position corresponding to proto_type to 1 in the bitmap), and constructs a proto_id list and a proto_offset list for use in subsequent steps to generate descriptors. The final generation result is shown in Table 6.

[0247] 715-716: The results contain IPv4 and TCP. Extract the 5-tuple, use the parsing result generated in 714 (protocol bitmap, offset list) as the value, and the previously calculated hash value as the key, and fill it back into the second template hash table. This way, subsequent packets of the same flow can directly take the fast path.

[0248] 717: Finally, regardless of whether the fast path or the slow path is taken, the system will assemble a message descriptor as shown in Table 3 based on the parsing results, which includes the protocol type, offset information, etc., and send it to the host software (such as the operating system kernel) for processing via DMA.

[0249] The following table 4 shows an example of a node (NODE information example table):

[0250]

[0251] CAM example (CAM example configuration table) is shown in Table 5 below:

[0252]

[0253]

[0254] Following the configuration example in this solution, after parsing, the network packets from MAC→VLAN→IPv4→TCP→HTTPS will ultimately result in the following Table 6 (Example Final Parsing Results):

[0255]

[0256] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the steps or stages of other steps.

[0257] The above describes a message processing method provided by an embodiment of this application. The following describes the apparatus for performing the above message processing method. Please refer to... Figure 9 , Figure 9 This is a schematic diagram of a message processing device provided in an embodiment of this application. Figure 9 As shown, the message processing apparatus includes:

[0258] The receiving unit 901 is used to receive network packets, buffer the network packets in the hardware, and extract the packet header information of the network packets according to a preset length.

[0259] Extraction unit 902 is used to extract the content of preset offset field based on message header information and according to preset rules, and generate a first key value;

[0260] Matching unit 903 is used to match the first template using the first key value;

[0261] The parsing unit 904 is used to enter the slow path parsing process when the first key value does not match the first template, so as to generate a slow path parsing result according to the pre-configured protocol parsing rules; wherein, the slow path parsing result includes at least the protocol type of the network packet at different protocol layers, the protocol number of the current layer protocol of each protocol layer, and the starting offset of the current layer protocol in the network packet;

[0262] The generation unit 905 is used to generate a protocol descriptor based on the slow path resolution result; wherein, the protocol descriptor contains a protocol type bitmap and a protocol number-offset pair;

[0263] The transmission unit 906 is used to synchronously transmit the protocol descriptor and the corresponding message data to the host, so that the host can restore the slow path resolution result based on the protocol descriptor and send the restored protocol topology information to the application.

[0264] Exemplarily, the device further includes: a calculation unit 907 and an acquisition unit 908;

[0265] The extraction unit 902 is also used to enter the fast path parsing process when the first key value hits the first template, so as to extract the target offset field content of the corresponding network packet preset in the first template, and generate the second key value according to the target offset field content.

[0266] The calculation unit 907 is used to calculate the second key value using a preset hash algorithm to obtain the first hash value;

[0267] The matching unit 903 is also used to match the second template hash table with the first hash value; wherein the second template hash table is stored in memory to cache historical parsing results;

[0268] The acquisition unit 908 is used to acquire the pre-stored fast path resolution result when the first hash value hits the second template hash table, and to trigger the generation unit 905 to perform the operation of generating a protocol descriptor; wherein, the pre-stored fast path resolution result is related to the historical resolution result corresponding to the first hash value;

[0269] The parsing unit 904 is also used to perform the operation of entering the slow path parsing process when the first hash value does not match the second template hash table.

[0270] Exemplarily, the device further includes: an update unit 909;

[0271] Update unit 909 is used to determine whether the current packet contains a valid network protocol IP address or 5-tuple information after slow path resolution is completed; wherein, the current packet is used to indicate the packet corresponding to the network packet in the current protocol layer;

[0272] The update unit 909 is also used to extract the valid IP address or 5-tuple information when it contains valid IP address or 5-tuple information, generate a second hash value using a preset hash algorithm, and update the second template hash table with the slow path resolution result as the associated storage value of the second hash value.

[0273] Exemplarily, the device further includes: a configuration unit 910;

[0274] Configuration unit 910 is used to configure the CAM table; wherein the CAM table includes at least the current node number of the current protocol in the current protocol layer, the current protocol number, the current protocol type bitmap information, the next protocol identifier pointing to the next protocol corresponding to the next protocol in the next protocol layer, the next node identifier, and whether the table lookup is ended;

[0275] Configuration unit 910 is also used to configure a node configuration table; wherein the node configuration table includes at least the current node number, the offset of the next protocol identifier in the current protocol, the field length of the next protocol identifier, and the current protocol length of the current protocol.

[0276] Exemplarily, the device further includes: a lookup unit 911 and an execution unit 912;

[0277] Parsing unit 904 is specifically used to initialize the parsing process, set the current node identifier of the current protocol layer to the initial value, and set the current header offset to 0;

[0278] Extraction unit 902 is specifically used to extract the next protocol identifier from the specified offset position of the current message according to the current node identifier index node configuration table; wherein, the current message is used to indicate the message corresponding to the network message in the current protocol layer;

[0279] The lookup unit 911 is used to construct a third key value based on the current node identifier and the next protocol identifier, and then look up the CAM table.

[0280] The update unit 909 is specifically used to record the protocol number, protocol type and current header offset of the current protocol when the CAM table is hit, and update the current header offset according to the current protocol length.

[0281] Execution unit 912 is used to terminate the parsing process of the current message when the CAM table is not matched.

[0282] Exemplarily, the device further includes: a determination unit 913;

[0283] The judgment unit 913 is used to determine whether the end lookup flag in the CAM table is the final protocol flag after the CAM table is hit.

[0284] The execution unit 912 is also used to terminate the parsing when the table lookup end flag is the last-level protocol identifier;

[0285] The execution unit 912 is also used to update the current node identifier to the next node identifier and return to the step of indexing the node configuration table according to the current node identifier when the table lookup end flag is not the last-level protocol identifier.

[0286] For example, the system also includes:

[0287] Acquisition unit 908 is used to acquire the protocol type bitmap field; wherein, the protocol type bitmap field is used to indicate the protocol type of each protocol layer appearing in the network packet;

[0288] The acquisition unit 908 is also used to acquire multiple protocol number and offset pairs, and store the protocol number of each protocol layer and the starting offset of each protocol number in the network packet in the parsing order; wherein, each protocol number and offset pair in the protocol descriptor contains a protocol number field and an offset field, and are arranged in order after the protocol type bitmap field.

[0289] For example, the system further includes: a reading unit 913 and a determining unit 914;

[0290] Reading unit 913 is used to read the protocol type bitmap field in the protocol descriptor;

[0291] The determining unit 914 is used to determine the number of protocol layers and the protocol type of each protocol layer in the network packet based on the bits set in the protocol type bitmap field.

[0292] The reading unit 913 is also used to extract the protocol number and offset of each protocol layer from the protocol descriptor in sequence;

[0293] The execution unit 912 is specifically used to associate the restored protocol topology information with the message data for use by applications within the host.

[0294] This application also provides an electronic device in its embodiments. (See reference...) Figure 10The diagram illustrates a structural schematic of an electronic device suitable for implementing the message processing method in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 10 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0295] like Figure 10 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 1001, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1008 into a random access memory (RAM) 1003. When the electronic device is powered on, the RAM 1003 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, ROM 1002, and RAM 1003 are interconnected via a bus 1004. An input / output (I / O) interface 1005 is also connected to the bus 1004.

[0296] Typically, the following devices can be connected to the I / O interface 1005: input devices 1006 including, for example, a touchscreen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; output devices 1007 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1008 including, for example, memory card, hard disk, etc.; and communication devices 1009. Communication device 1009 allows electronic devices to exchange data via wireless or wired communication with other devices. Although Figure 10 Electronic devices with various means are shown, but it should be understood that implementation or possession of all the means shown is not required. More or fewer means may be implemented alternatively.

[0297] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the message processing methods provided in this application.

[0298] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the message processing methods provided in this application.

[0299] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0300] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0301] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0302] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A message processing method, characterized in that, The method includes: Receive network packets, cache the network packets in hardware, and extract the packet header information of the network packets according to a preset length; Based on the message header information, according to preset rules, the content of the preset offset field is extracted to generate a first key value; Use the first key value to match the first template; If the first key value does not match the first template, the slow path resolution process is initiated to generate a slow path resolution result based on the pre-configured protocol resolution rules. The slow path resolution result includes at least the protocol type of the network packet at different protocol layers, the protocol number of the current layer protocol at each protocol layer, and the starting offset of the current layer protocol in the network packet. Based on the slow path resolution results, a protocol descriptor is generated; wherein, the protocol descriptor contains a protocol type bitmap and a protocol number-offset pair; The protocol descriptor and the corresponding message data are synchronously transmitted to the host so that the host can restore the slow path resolution result based on the protocol descriptor and send the restored protocol topology information to the application.

2. The message processing method according to claim 1, characterized in that, After matching the first template with the first key value, the method further includes: If the first key value matches the first template, the fast path parsing process is entered to extract the target offset field content corresponding to the network packet from the first template, and generate a second key value based on the target offset field content. The first hash value is obtained by calculating the second key value using a preset hash algorithm; The first hash value is used to match the second template hash table; wherein the second template hash table is stored in memory to cache historical parsing results; If the first hash value matches the second template hash table, the pre-stored fast path resolution result is obtained, and the step of generating the protocol descriptor is executed; wherein, the pre-stored fast path resolution result is associated with the historical resolution result corresponding to the first hash value; If the first hash value does not match the second template hash table, the step of entering the slow path resolution process is executed.

3. The message processing method according to claim 2, characterized in that, The method further includes: After slow path resolution is completed, it is determined whether the current packet contains a valid network protocol IP address or 5-tuple information; wherein, the current packet is used to indicate the packet corresponding to the network packet in the current protocol layer; If contained, the valid IP address or the 5-tuple information is extracted, a second hash value is generated using the preset hash algorithm, and the slow path resolution result is used as the associated storage value of the second hash value to update the second template hash table.

4. The message processing method according to claim 1, characterized in that, The configuration steps for the protocol parsing rules include: Configure the CAM table; wherein the CAM table includes at least the current node number of the current protocol in the current protocol layer, the current protocol number, the current protocol type bitmap information, the next protocol identifier pointing to the next protocol corresponding to the next protocol in the next protocol layer, the next node identifier, and whether the table lookup is ended; Configure a node configuration table; wherein the node configuration table includes at least the current node number, the offset of the next protocol identifier in the current protocol, the field length of the next protocol identifier, and the current protocol length of the current protocol.

5. The message processing method according to claim 4, characterized in that, The process of generating slow path resolution results based on pre-configured protocol resolution rules includes: Initialize the parsing process, set the current node identifier of the current protocol layer to the initial value, and set the current header offset to 0; The node configuration table is indexed based on the current node identifier, and the next protocol identifier is extracted from the specified offset position of the current packet; wherein, the current packet is used to indicate the packet corresponding to the network packet in the current protocol layer; Construct a third key value based on the current node identifier and the next protocol identifier, and then look up the CAM table; When the CAM table is matched, the protocol number, protocol type and current header offset of the current protocol are recorded, and the current header offset is updated according to the current protocol length. If the CAM table is not matched, the parsing process of the current message is terminated.

6. The message processing method according to claim 5, characterized in that, After the CAM table is hit, the method further includes: Determine whether the end-of-lookup flag in the CAM table is a final-level protocol flag; If the table lookup termination flag is the last-level protocol identifier, then the parsing is terminated; If the end-of-lookup flag is not the last-level protocol identifier, update the current node identifier to the next node identifier, and return to the step of indexing the node configuration table based on the current node identifier to continue parsing.

7. The message processing method according to claim 1, characterized in that, The protocol descriptor is a fixed-format data structure, and the generation of the protocol descriptor includes: Obtain the protocol type bitmap field; wherein, the protocol type bitmap field is used to indicate the protocol type of each protocol layer appearing in the network packet; Multiple protocol number and offset pairs are obtained and stored sequentially according to the parsing order, along with the protocol number of each protocol layer and the starting offset of each protocol number in the network packet. Each protocol number and offset pair in the protocol descriptor contains a protocol number field and an offset field, and are arranged sequentially after the protocol type bitmap field.

8. The message processing method according to claim 7, characterized in that, The process of restoring the slow path resolution result includes: Read the protocol type bitmap field from the protocol descriptor; Based on the bits set in the protocol type bitmap field, determine the number of protocol layers appearing in the network packet and the protocol type of each protocol layer; Extract the protocol number and offset of each protocol layer sequentially from the protocol descriptor; The restored protocol topology information is associated with the message data for use by applications within the host.

9. A message processing apparatus, characterized in that, include: The receiving unit is used to receive network packets, cache the network packets in hardware, and extract the packet header information of the network packets according to a preset length. The extraction unit is used to extract the content of a preset offset field based on the message header information and according to preset rules, and generate a first key value; A matching unit is used to match a first template using the first key value; The parsing unit is used to enter the slow path parsing process when the first key value does not match the first template, so as to generate a slow path parsing result according to the pre-configured protocol parsing rules; wherein, the slow path parsing result includes at least the protocol type of the network packet at different protocol layers, the protocol number of the current layer protocol of each protocol layer and the starting offset of the current layer protocol in the network packet; The generation unit is used to generate a protocol descriptor based on the slow path resolution result; wherein the protocol descriptor includes a protocol type bitmap and a protocol number-offset pair; The transmission unit is used to synchronously transmit the protocol descriptor and the corresponding message data to the host, so that the host can restore the slow path resolution result based on the protocol descriptor and send the restored protocol topology information to the application.

10. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the message processing method as described in any one of claims 1 to 8.

11. A computer storage medium, characterized in that, The storage medium carries one or more computer programs that, when executed by an electronic device, enable the electronic device to implement the message processing method as described in any one of claims 1 to 8.

Images