Message processing method and device and related equipment

Abstract

The invention relates to the technical field of network communication, in particular to a message processing method and device and related equipment. The method is applied to a network processor, and a lookup table comprising mapping relations between various types of messages and corresponding buffer header offsets is preset on the network processor. The method comprises the following steps: in a stage of receiving a target message sent by an external network, pre-analyzing the received target message to determine a message type of the target message; judging whether a target table item matched with the message type of the target message exists in the lookup table or not; if it is judged that a target table item matched with the message type of the target message exists in the lookup table, the target buffer header offset included in the target table item is configured as the buffer header offset of the target message, and the target table item comprises the mapping relation between the message type of the target message and the corresponding target buffer header offset; and loading the target message to a first head buffer area based on the target buffer area head offset.

Description

Technical Field

[0001] This application relates to the field of network communication technology, and in particular to a message processing method, apparatus and related equipment. Background Technology

[0002] During network data forwarding, when NPU (Network Processing Unit), general-purpose CPU, ASIC (Application-Specific Integrated Circuit), or FPGA (Field-Programmable Gate Array) chips (collectively referred to as network processors) process packets, they need to write the first part of the packet header into the chip's internal high-speed memory. This allows the packet processing core to extract and modify the packet content. This high-speed memory is called the packet buffer. The packet buffer is generally of a fixed size. Because dedicated chips like network processors generally do not have complex memory management capabilities to ensure architectural simplicity, they are designed for this purpose.

[0003] When storing a message into the first buffer, it is generally stored from a certain offset in the buffer rather than from the beginning address of the buffer. This is because it is necessary to ensure that there is enough message content in the buffer for message forwarding, and that there is enough free area in the buffer for message encapsulation. This offset is called the buffer header offset.

[0004] Currently, high-performance network processors mostly adopt a pass-through mode, meaning they begin processing after receiving only a small portion of the packet header. In other words, processing starts as soon as the first packet buffer is written, which shortens forwarding latency and improves performance. It's important to note that loading packets into the packet buffer takes time. A smaller buffer header offset means more packet content can be stored in the buffer, allowing the packet processing core to retrieve more packet content and support more complex services. However, longer loading times result in weaker forwarding performance. Theoretically, the first buffer should only load the packet content required for forwarding; loading the rest is redundant. Conversely, the buffer header offset cannot be too large. A large offset means less packet content in the buffer, potentially affecting normal service forwarding, especially for services like VXLAN (Virtual Extensible Local Area Network) tunnel termination and SRV6 (Segment Routing over IPv6) termination, which require a longer packet length in the first buffer.

[0005] In summary, the setting of the buffer header offset in the packet head buffer of a network forwarding chip can affect forwarding performance and the chip's ability to handle complex services. Summary of the Invention

[0006] This application provides a message processing method, apparatus, and related equipment.

[0007] In a first aspect, this application provides a message processing method applied to a network processor, wherein the network processor has a pre-set lookup table including a mapping relationship between various types of messages and their corresponding buffer header offsets; the method includes: During the stage of receiving target messages sent from external networks, the received target messages are pre-parsed to determine the message type of the target messages; Determine whether there exists a target entry in the lookup table that matches the message type of the target message; If it is determined that there is a target table entry in the lookup table that matches the message type of the target message, then the target buffer header offset included in the target table entry is configured as the buffer header offset of the target message, wherein the target table entry includes the mapping relationship between the message type of the target message and its corresponding target buffer header offset; Based on the target buffer header offset, the target message is loaded into the first buffer.

[0008] Optionally, the step of pre-parsing the received target message to determine the target message type includes: The header of the received target message is parsed to obtain the specified fields in the header; The message type of the target message is determined based on the value of the specified field.

[0009] Optionally, the method further includes: If it is determined that there is no target entry in the lookup table that matches the message type of the target message, then the default buffer header offset is configured as the buffer header offset of the target message, and the target message is loaded into the first buffer based on the default buffer header offset.

[0010] Optionally, the default buffer header offset is the buffer header offset corresponding to the target type message with the largest required buffer header offset for processing each type of message.

[0011] Optionally, the method further includes: During the stage of forwarding the target packet to the external network, the target buffer header offset is obtained, and the sum of the target buffer header offset and a preset value is used to configure the current buffer header offset of the target packet; Based on the current buffer header offset of the target message, the target message is loaded into the second buffer.

[0012] Secondly, this application provides a message processing apparatus applied to a network processor, wherein the network processor has a pre-set lookup table including a mapping relationship between various types of messages and their corresponding buffer header offsets; the apparatus includes: The pre-parse unit, during the stage of receiving target packets sent by an external network, is used to pre-parse the received target packets to determine the packet type of the target packets; The judgment unit is used to determine whether there is a target entry in the lookup table that matches the message type of the target message; If the judgment unit determines that there is a target table entry in the lookup table that matches the message type of the target message, the configuration unit is configured to configure the target buffer header offset included in the target table entry as the buffer header offset of the target message, wherein the target table entry includes a mapping relationship between the message type of the target message and its corresponding target buffer header offset; The loading unit is used to load the target message into the first buffer based on the target buffer header offset.

[0013] Optionally, when pre-parsing the received target message to determine the target message type, the pre-parsing unit is specifically used for: The header of the received target message is parsed to obtain the specified fields in the header; The message type of the target message is determined based on the value of the specified field.

[0014] Optionally, if the determination unit determines that there is no target entry in the lookup table that matches the message type of the target message, the configuration unit is further configured to set the default buffer header offset as the buffer header offset of the target message, and load the target message into the first buffer based on the default buffer header offset.

[0015] Optionally, the default buffer header offset is the buffer header offset corresponding to the target type message with the largest required buffer header offset for processing each type of message.

[0016] Optionally, the device further includes: In the stage of forwarding the target packet to an external network, the acquisition unit is used to acquire the target buffer header offset, and the configuration unit is also used to configure the current buffer header offset of the target packet by the sum of the target buffer header offset and a preset value. The loading unit is further configured to load the target message into the second buffer based on the current buffer header offset of the target message.

[0017] Thirdly, embodiments of this application provide a message processing apparatus, which includes: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the steps of the method as described in any one of the first aspects above, according to the obtained program instructions.

[0018] Fourthly, embodiments of this application also provide a computer-readable storage medium storing computer-executable instructions for causing a computer to perform the steps of the method as described in any of the first aspects above.

[0019] In summary, the message processing method provided in this application is applied to a network processor, which has a pre-defined lookup table that includes a mapping relationship between various message types and their corresponding buffer header offsets. The method includes: in the stage of receiving a target message sent by an external network, pre-parsing the received target message to determine the message type of the target message; determining whether there is a target entry in the lookup table that matches the message type of the target message; if it is determined that there is a target entry in the lookup table that matches the message type of the target message, configuring the target buffer header offset included in the target entry as the buffer header offset of the target message, wherein the target entry includes a mapping relationship between the message type of the target message and its corresponding target buffer header offset; and loading the target message into a first buffer based on the target buffer header offset.

[0020] The message processing method provided in this application pre-configures buffer header offsets corresponding to various message types on the network processor. When processing a message, the message type is pre-parsed to obtain the message type, and when it is determined that a corresponding buffer header offset is configured for the message type, the message is processed based on that buffer header offset. This eliminates the need to use the longest buffer header offset for all message types, improving the processing efficiency of simple message types (those requiring shorter message lengths), thereby improving the overall message processing efficiency of the network processor. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments of this application or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings of the embodiments of this application.

[0022] Figure 1 A detailed flowchart of a message processing method provided for an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a message processing device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the hardware architecture of a message processing device provided in an embodiment of this application. Detailed Implementation

[0023] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “the,” and “the” as used in this application and claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to any and all possible combinations comprising one or more of the associated listed items.

[0024] It should be understood that although the terms first, second, third, etc., may be used to describe various information in embodiments of this application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" may also be interpreted as "when," "when," or "in response to a determination."

[0025] Currently, network processors are generally divided into two stages: Ingress and Egress. The Ingress stage adds an on-chip interactive header to the packet for concatenation with the Egress stage. Both stages need to reload the packet into the first buffer, so the header offset needs to be considered.

[0026] For the Ingress phase, mainstream network processors currently use a fixed buffer header offset setting for the first buffer, i.e., manual buffer allocation. The allocation is based on the forwarding types and packet types supported by the network processor, ensuring that the first buffer can store enough content for the longest supported encapsulation format. For example, if the most complex encapsulation service supported by the network processor is SRV6 L3VPN termination with a Layer 10 SID, then the header offset setting needs to ensure that the first buffer stores at least 242 bytes of packet (14 bytes Ethernet header + 40 bytes IPv6 header + 8 bytes routing extension header + 160 bytes Layer 10 SID + 20 bytes inner IP header).

[0027] For the Egress phase, due to the addition of the intra-chip interaction header, the key to header offset settings is ensuring that the Egress phase can handle at least as much packet content as the Ingress phase. Otherwise, some functions that require the cooperation of both phases may malfunction, such as the SRV6 END operation. In the Ingress phase, the SID at a specified location needs to be used to look up the routing table for forwarding, and in the Egress phase, the SID at the specified location needs to be copied to the DIP position in the IPv6 header. If the Egress phase can handle less packet content than the Ingress phase, a situation may occur where the routing table lookup is normal but the packet encapsulation is incorrect. The Egress phase generally adds a fixed length to the Ingress phase header offset to eliminate the influence of the intra-chip interaction header, but fundamentally, it is still a fixed setting approach.

[0028] However, setting header offsets only according to the packet encapsulation format of the most complex business leads to redundant packet loading in other business scenarios, causing additional latency and impacting forwarding performance. For example, the header offset setting for SRV6 L3VPN termination services with Layer 10 SIDs, as mentioned earlier, should ensure that the first buffer can hold at least 242 bytes of packet content. However, for typical IPv4 Layer 3 forwarding, only 54 bytes (14 bytes for Ethernet header + 20 bytes for IPv4 header + 20 bytes for Layer 4 header, taking TCP as an example) need to be stored in the buffer; the remaining 188 bytes are redundant. The header offset in the Egress stage, based on the fixed settings of the Ingress stage, also leads to additional latency, resulting in double the performance loss. Since header offsets are fixed configurations, if the Ingress stage header offset is modified for any reason, or if the length of the intra-chip interaction header changes, all header offset configurations need to be manually modified, which can easily lead to omissions.

[0029] This application provides a technical solution that presets buffer header offsets for various types of messages, and dynamically uses the buffer header offsets of different types of messages for message processing based on the buffer offset corresponding to the message type.

[0030] For example, see Figure 1 The diagram shown is a detailed flowchart of a message processing method provided in an embodiment of this application. This method is applied to a network processor, which has a pre-set lookup table containing a mapping relationship between various message types and their corresponding buffer header offsets. The method includes the following steps: Step 100: In the stage of receiving target messages sent by external networks, the received target messages are pre-parsed to determine the message type of the target messages.

[0031] In this embodiment of the application, when pre-parsing the received target message to determine the target message type, a preferred implementation is as follows: The header of the received target message is parsed to obtain the specified fields in the header; The message type of the target message is determined based on the value of the specified field.

[0032] The following example illustrates how messages are transmitted in the network processor in the form of flits.

[0033] In this embodiment of the application, when the network processor enables dynamic header offset (dynamic buffer header offset), it can determine the packet type of the target packet after receiving the target packet sent by the external network (e.g., determine that the target packet is an IPv4 / IPv6 / MPLS / RAW_ETH packet).

[0034] In this embodiment, a corresponding buffer header offset can be pre-set on the network processor for different types of packets. In this way, when processing such packets, the packets can be cached based on the corresponding buffer header offset.

[0035] In practical applications, for RAW_ETH packets, the header length required for forwarding is very short, requiring only one flit. For IPv4 and IPv6 packets, the PROTOCOL field in the header can be used to determine whether the packet is an IP tunnel packet or a UDP packet. For UDP packets, the UDP port number can be used to determine whether it is a UDP tunnel packet. Different header offsets can be configured for non-tunnel IPv4 and IPv6 packets. For IPv6 packets, the PROTOCOL field can be used to further determine whether the IPv6 packet carries an extended header. For IPv6 packets with extended headers, it can be assumed that the packet may contain complex services, and the default buffer header offset can be used.

[0036] In other words, depending on the type of message received, the length of the message to be buffered in the first buffer is different when processing various types of messages. Therefore, the buffer header offset can be set to 1 for message type 1, and the buffer header offset can be set to 2 for message type 2, and so on.

[0037] When a network processor receives a message, it determines the message type based on specified fields in the message header (such as the PROTOCOL field and / or the DPORT field).

[0038] Therefore, in this embodiment of the application, when a corresponding buffer header offset (lookup table) can be preset for different types of messages, the corresponding buffer header offset can be set for different PROTOCOL field values ​​and / or different DPORT field values. Users can flexibly configure the lookup table according to specific application scenarios and / or different needs.

[0039] Step 110: Determine whether there is a target entry in the lookup table that matches the message type of the target message.

[0040] In this embodiment of the application, after determining the message type of the target message, a lookup table is matched according to the message type of the target message to determine whether there is a target entry in the lookup table that matches the message type of the target message.

[0041] That is, it determines whether the lookup table contains the buffer header offset corresponding to the message type of the target message.

[0042] Step 120: If it is determined that there is a target entry in the lookup table that matches the message type of the target message, then the target buffer header offset included in the target entry is configured as the buffer header offset of the target message.

[0043] The target entry includes the mapping relationship between the message type of the target message and its corresponding target buffer header offset.

[0044] In this embodiment of the application, when it is determined that a target entry in the lookup table exists that matches the message type of the target message, the target buffer header offset configured in the target entry is obtained as the buffer header offset corresponding to the target message.

[0045] Step 130: Based on the target buffer header offset, load the target message into the first buffer.

[0046] When processing the received target message, the target message is loaded into the first buffer based on the target buffer header offset. In this embodiment, the buffer used when processing the target message in the Ingress stage is the first buffer, and the first buffer in the first buffer is the first buffer.

[0047] In this embodiment of the application, if it is determined that there is no target table entry in the lookup table that matches the message type of the target message, the default buffer header offset is configured as the buffer header offset of the target message, and the target message is loaded into the first buffer based on the default buffer header offset.

[0048] It should be noted that, in this embodiment of the application, the default buffer header offset is: the buffer header offset corresponding to the target type message with the largest buffer header offset required to process each type of message.

[0049] Specifically, if no table entry matching the message type of the target message type is found in the lookup table, it means that no corresponding buffer header offset is configured for the message type of the target message. In this case, the default buffer header offset configuration needs to be used when processing the target message.

[0050] In this embodiment of the application, the default buffer header offset is: the buffer header offset corresponding to the target type message with the largest buffer header offset required to process each type of message.

[0051] For example, taking the most complex encapsulation service (SRV6 L3VPN termination service with a Layer 10 SID) as an example, the buffer header offset setting needs to ensure that the first buffer can hold at least 242 bytes of packet content. Therefore, the default buffer header offset can be configured to 242 bytes.

[0052] In this embodiment of the application, for simple types of packets (e.g., packets with a short processing length), the corresponding buffer header offset can be pre-configured. In this way, when the network processor processes such packets, it obtains the buffer header offset corresponding to such packets and caches the packets in the first buffer according to the buffer header offset (the packets can be processed after the first buffer is loaded). This can improve the processing efficiency of such packets, thereby improving the overall forwarding efficiency of the network processor.

[0053] In this embodiment of the application, during the stage of forwarding the target packet to the external network, the target buffer header offset is obtained, and the sum of the target buffer header offset and a preset value is used to configure the current buffer header offset of the target packet; Based on the current buffer header offset of the target message, the target message is loaded into the second buffer.

[0054] In practical applications, for the Egress phase, due to the addition of the on-chip interaction header, the key to header offset settings is to ensure that the Egress phase can handle no less packet content than the Ingress phase. Otherwise, some functions that require the cooperation of the two phases may malfunction. For example, the SRV6 END operation requires the Ingress phase to use the SID at a specified location to look up the routing table for forwarding, and the Egress phase to copy the SID at the specified location to the DIP position in the IPv6 header. If the Egress phase can handle less packet content than the Ingress phase, a situation may occur where the routing table lookup is normal but the packet encapsulation is incorrect.

[0055] Therefore, in this embodiment of the application, after determining that a certain type of message has a corresponding buffer header offset in the Ingress stage, the buffer header offset can be carried to the Egress stage through the on-chip interaction header or message metadata. In the Egress stage, the message is pre-parsed, and the buffer header offset of the Ingress stage is obtained from the on-chip interaction header or message metadata. The configured Egress header offset calibration parameter is added to obtain the final buffer header offset of the Egress stage.

[0056] In this embodiment of the application, when processing the target message in the Ingress stage, the buffer used is the first buffer, and the first buffer in the first buffer is the first head buffer.

[0057] Based on the same inventive concept as the above-described embodiments, see, for example, the following: Figure 3 The diagram shown is a structural schematic of a message processing device provided in an embodiment of this application. This device is applied to a network processor, which has a pre-set lookup table containing a mapping relationship between various types of messages and their corresponding buffer header offsets. The device includes: The pre-parse unit 20, during the stage of receiving target packets sent by an external network, is used to pre-parse the received target packets to determine the packet type of the target packets; The judgment unit 21 is used to determine whether there is a target entry in the lookup table that matches the message type of the target message; If the judgment unit 21 determines that there is a target table entry in the lookup table that matches the message type of the target message, the configuration unit 22 is configured to configure the target buffer header offset included in the target table entry as the buffer header offset of the target message, wherein the target table entry includes the mapping relationship between the message type of the target message and its corresponding target buffer header offset; Loading unit 23 is used to load the target message into the first buffer based on the target buffer header offset.

[0058] Optionally, when pre-parsing the received target message to determine the target message type, the pre-parsing unit 20 is specifically used for: The header of the received target message is parsed to obtain the specified fields in the header; The message type of the target message is determined based on the value of the specified field.

[0059] Optionally, if the determination unit determines that there is no target entry in the lookup table that matches the message type of the target message, the configuration unit is further configured to set the default buffer header offset as the buffer header offset of the target message, and load the target message into the first buffer based on the default buffer header offset.

[0060] Optionally, the default buffer header offset is the buffer header offset corresponding to the target type message with the largest required buffer header offset for processing each type of message.

[0061] Optionally, the device further includes: In the stage of forwarding the target packet to an external network, the acquisition unit is used to acquire the target buffer header offset, and the configuration unit is also used to configure the current buffer header offset of the target packet by the sum of the target buffer header offset and a preset value. The loading unit 23 is further configured to load the target message into the second buffer based on the current buffer header offset of the target message.

[0062] These units can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more digital signal processors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when one of these units is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these units can be integrated together to form a system-on-a-chip (SOC).

[0063] Furthermore, regarding the message processing apparatus provided in this application embodiment, from a hardware perspective, the hardware architecture schematic diagram of the message processing apparatus can be found in [reference needed]. Figure 3 As shown, the message processing device may include: a memory 30 and a processor 31. The memory 30 is used to store program instructions; the processor 31 calls the program instructions stored in the memory 30 and executes the above method embodiment according to the obtained program instructions. The specific implementation method and technical effect are similar, and will not be described again here.

[0064] Optionally, this application also provides a message processing device, including at least one processing element (or chip) for performing the above method embodiments.

[0065] Optionally, this application also provides a program product, such as a computer-readable storage medium storing computer-executable instructions for causing the computer to perform the above-described method embodiments.

[0066] Here, a machine-readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, a machine-readable storage medium can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0067] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0068] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0069] 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, embodiments of this application can take the form of a computer program product implemented 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.

[0070] 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.

[0071] Furthermore, these computer program instructions can also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate 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 the process. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0072] 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.

[0073] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A message processing method, characterized in that, The method is applied to a network processor, which has a pre-defined lookup table containing a mapping relationship between various types of packets and their corresponding buffer header offsets; the method includes: During the stage of receiving target messages sent from external networks, the received target messages are pre-parsed to determine the message type of the target messages; Determine whether there exists a target entry in the lookup table that matches the message type of the target message; If it is determined that there is a target table entry in the lookup table that matches the message type of the target message, then the target buffer header offset included in the target table entry is configured as the buffer header offset of the target message, wherein the target table entry includes the mapping relationship between the message type of the target message and its corresponding target buffer header offset; Based on the target buffer header offset, the target message is loaded into the first buffer.

2. The method as described in claim 1, characterized in that, The steps of pre-parsing the received target message to determine the target message type include: The header of the received target message is parsed to obtain the specified fields in the header; The message type of the target message is determined based on the value of the specified field.

3. The method as described in claim 1 or 2, characterized in that, The method further includes: If it is determined that there is no target entry in the lookup table that matches the message type of the target message, then the default buffer header offset is configured as the buffer header offset of the target message, and the target message is loaded into the first buffer based on the default buffer header offset.

4. The method as described in claim 3, characterized in that, The default buffer header offset is the buffer header offset corresponding to the target type message with the largest required buffer header offset for processing each type of message.

5. The method as described in claim 1, characterized in that, The method further includes: During the stage of forwarding the target packet to the external network, the target buffer header offset is obtained, and the sum of the target buffer header offset and a preset value is used to configure the current buffer header offset of the target packet; Based on the current buffer header offset of the target message, the target message is loaded into the second buffer.

6. A message processing apparatus, characterized in that, The device is applied to a network processor, which has a pre-defined lookup table containing a mapping relationship between various types of packets and their corresponding buffer header offsets; the device includes: The pre-parse unit, during the stage of receiving target packets sent by an external network, is used to pre-parse the received target packets to determine the packet type of the target packets; The judgment unit is used to determine whether there is a target entry in the lookup table that matches the message type of the target message; If the judgment unit determines that there is a target table entry in the lookup table that matches the message type of the target message, the configuration unit is configured to configure the target buffer header offset included in the target table entry as the buffer header offset of the target message, wherein the target table entry includes a mapping relationship between the message type of the target message and its corresponding target buffer header offset; The loading unit is used to load the target message into the first buffer based on the target buffer header offset.

7. The apparatus as claimed in claim 6, characterized in that, When performing pre-parsing on a received target message to determine its target message type, the pre-parsing unit is specifically used for: The header of the received target message is parsed to obtain the specified fields in the header; The message type of the target message is determined based on the value of the specified field.

8. The apparatus as claimed in claim 6, characterized in that, The device further includes: In the stage of forwarding the target packet to an external network, the acquisition unit is used to acquire the target buffer header offset, and the configuration unit is also used to configure the current buffer header offset of the target packet by the sum of the target buffer header offset and a preset value. The loading unit is further configured to load the target message into the second buffer based on the current buffer header offset of the target message.

9. A message processing apparatus, characterized in that, The message processing device includes: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the steps of the method as described in any one of claims 1-5 according to the obtained program instructions.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing the computer to perform the steps of the method as described in any one of claims 1-5.

Images