Unexpected message processing method, apparatus and system

Abstract

The application relates to an unexpected message processing method, device and system. The method comprises the following steps: in the case of receiving an unexpected message, storing a data payload part of the unexpected message in an unexpected message buffer and storing a message header descriptor of the unexpected message in an on-chip message header buffer; sending an unexpected message arrival notification carrying the message header descriptor to a control end; in the case of receiving a new regular message buffer allocated by the control end, reading buffer information of the allocated buffer; in the case of existing a target message header descriptor matching the buffer information in the on-chip message header buffer, sending an unexpected message matching success notification to the control end; the unexpected message matching success notification is used for instructing the control end to copy a data payload part corresponding to the target message header descriptor to the new regular message buffer. The method can improve unexpected message processing efficiency.

Description

Technical Field

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

[0002] With the development of communication networks and distributed system technologies, various message exchange technologies between heterogeneous nodes have emerged. These technologies typically require the execution end to efficiently process messages from different sources and adopt different processing strategies based on message type. In a typical message processing mechanism, the system pre-divides a regular message buffer and an unexpected message buffer to store expected normal messages and unexpected messages that do not meet the expected arrival time, order, or format, respectively.

[0003] With the development of high-performance computing and artificial intelligence cluster technologies, high-speed interconnect network technologies supporting remote direct memory access semantics have emerged. These technologies bypass the kernel and achieve zero-copy data transmission, exhibiting extremely low latency and extremely high throughput. However, this leads to the problem of handling unexpected messages. In such high-performance network communications, when the execution end receives a message, if the control end has not yet issued a corresponding receive command (i.e., has not prepared a receive buffer), this message is called an unexpected message.

[0004] In traditional network protocols, unexpected messages are treated as an anomaly or error state. When the executing end receives an unexpected message for which the corresponding receive buffer cannot be found, it returns a negative acknowledgment message to the sending end. After receiving the negative acknowledgment message, the sending end must wait for a period of time before retransmitting the message. However, this current approach has the following problems: First, the negative acknowledgment message mechanism requires the sending end to go through the complete process of waiting, timeout, and retransmission. In scenarios with large message volumes and high communication frequencies in AI clusters, this introduces significant additional latency, severely impacting the overall job execution efficiency. Summary of the Invention

[0005] Therefore, it is necessary to provide an unexpected message processing method, apparatus, and system that can improve the efficiency of unexpected message processing in response to the above-mentioned technical problems.

[0006] Firstly, this application provides an unexpected message handling method, applied to the execution end, including:

[0007] Upon receiving an unexpected message, the data payload portion of the unexpected message is stored in the unexpected message buffer, and the message header descriptor of the unexpected message is stored in the on-chip message header buffer.

[0008] Send an unexpected message arrival notification carrying the message header descriptor to the control terminal;

[0009] Upon receiving a new regular message buffer allocated by the control terminal, read the buffer information of the allocated buffer;

[0010] If a target message header descriptor matching the buffer information exists in the on-chip message header buffer, an unexpected message matching success notification is sent to the control terminal; the unexpected message matching success notification is used to instruct the control terminal to copy the data payload portion corresponding to the target message header descriptor to the new regular message buffer.

[0011] In one embodiment, the method further includes:

[0012] Obtain the received message information;

[0013] Field extraction is performed on the message information to obtain the key field information of the message information;

[0014] The key field information is matched with the internal cached regular message buffer. If the match fails, the message information is determined to be an unexpected message.

[0015] In one embodiment, the regular message buffer includes a labeled buffer and a non-labeled buffer; the matching of the key field information with the internally cached regular message receive buffer includes:

[0016] If the key field information contains a tag, then if the matching result between the tag and the buffer tag of the tag buffer is a match failure, then the match failure is determined.

[0017] If the key field information does not contain a tag, then if the length of the message data contained in the key field information is greater than the buffer data length of the non-tag buffer, the matching is determined to be unsuccessful.

[0018] In one embodiment, the method further includes:

[0019] If a match is successful, obtain the physical address of the regular message buffer;

[0020] The data payload portion is written to the regular message buffer according to the physical address.

[0021] Secondly, this application also provides an unexpected message handling method, applied to a control terminal; the method includes:

[0022] Upon receiving an unexpected message arrival notification from the execution end carrying a message header descriptor, a new regular message buffer is allocated to the execution end; the unexpected message arrival notification is sent by the execution end after receiving the unexpected message, storing the data payload of the unexpected message in the unexpected message buffer, and storing the message header descriptor of the unexpected message in the on-chip message header buffer.

[0023] Upon receiving an unexpected message matching success notification from the execution end, the data payload portion corresponding to the target message header descriptor is copied to the new regular message buffer. The unexpected message matching success notification is sent by the execution end upon receiving the new regular message buffer, after reading the buffer information of the allocated buffer, and if a target message header descriptor matching the buffer information exists in the on-chip message header buffer.

[0024] In one embodiment, the method further includes:

[0025] If the remaining buffer space of the unexpected message buffer does not meet the preset space condition, a new unexpected message buffer is issued.

[0026] In one embodiment, the method further includes:

[0027] Pre-allocate regular message buffers and unexpected message buffers, and write the buffer information of each of the regular message buffers and unexpected message buffers into the command queue;

[0028] Send a receive command notification to the execution end; the receive command notification is used to instruct the execution end to obtain the information of each buffer from the command queue, and cache the address description information of the regular message buffer and the unexpected message buffer respectively.

[0029] Thirdly, this application also provides an unexpected message processing device, applied to an execution end, the device comprising:

[0030] The message storage module is used to store the data payload of the unexpected message in the unexpected message buffer and store the message header descriptor of the unexpected message in the on-chip message header buffer when an unexpected message is received.

[0031] The first notification sending module is used to send an unexpected message arrival notification carrying the message header descriptor to the control terminal;

[0032] The information reading module is used to read the buffer information of the allocated buffer when a new regular message buffer is allocated by the control terminal.

[0033] The second notification sending module is used to send an unexpected message matching success notification to the control terminal when a target message header descriptor matching the buffer information exists in the on-chip message header buffer; the unexpected message matching success notification is used to instruct the control terminal to copy the data payload portion corresponding to the target message header descriptor to the new regular message buffer.

[0034] Fourthly, this application also provides an unexpected message processing device, applied to a control terminal, the device comprising:

[0035] The buffer allocation module is used to allocate a new regular message buffer to the execution end when it receives an unexpected message arrival notification carrying a message header descriptor sent by the execution end; the unexpected message arrival notification is sent by the execution end after receiving the unexpected message, storing the data payload of the unexpected message in the unexpected message buffer, and storing the message header descriptor of the unexpected message in the on-chip message header buffer.

[0036] The data payload copy module is used to copy the data payload portion corresponding to the target message header descriptor to the new regular message buffer when receiving an unexpected message matching success notification sent by the execution end; the unexpected message matching success notification is sent by the execution end when receiving the new regular message buffer, reading the buffer information of the allocated buffer, and sending it if a target message header descriptor matching the buffer information exists in the on-chip message header buffer.

[0037] Fifthly, this application also provides an unexpected message processing system, the system comprising an execution end and a control end;

[0038] The execution terminal is communicatively connected to the control terminal, and the execution terminal includes an on-chip message header buffer.

[0039] The execution end is configured to, upon receiving an unexpected message, store the data payload portion of the unexpected message in an unexpected message buffer and store the message header descriptor of the unexpected message in an on-chip message header buffer.

[0040] Send an unexpected message arrival notification carrying the message header descriptor to the control terminal;

[0041] The control terminal is used to allocate a new regular message buffer to the execution terminal upon receiving the unexpected message arrival notification.

[0042] The execution terminal is also used to read the buffer information of the allocated buffer when it receives a new regular message buffer allocated by the control terminal;

[0043] If a target message header descriptor matching the buffer information exists in the on-chip message header buffer, an unexpected message matching success notification is sent to the control terminal.

[0044] The control terminal is also configured to copy the data payload portion corresponding to the target message header descriptor to the new regular message buffer upon receiving the notification of successful matching of the unexpected message.

[0045] The aforementioned unexpected message handling method, apparatus, and system, upon receiving an unexpected message at the execution end, separates and stores the data payload and message header descriptor into an unexpected message buffer and an on-chip message header buffer, achieving hardware-side decoupling of the message header and data payload. This eliminates the need for the execution end to block or discard data due to unexpected messages. Furthermore, by sending an unexpected message arrival notification carrying only the message header descriptor to the control end, the control end can promptly detect the arrival of the unexpected message without obtaining the complete message content. The control end then proactively allocates a new regular message buffer, avoiding the additional latency and bandwidth overhead caused by the sender's passive waiting, timeout retransmission, and the control end's complete lack of awareness in traditional mechanisms. Further, the execution end... Upon receiving the regular message buffer allocated by the control end, the buffer information is read and matched in the on-chip message header buffer to ensure accurate association between the message header descriptor and the newly allocated regular message buffer by the control end. Then, when the match is successful, an unexpected message matching success notification is sent to the control end, instructing the control end to copy the data payload part corresponding to the target message header descriptor to the regular message buffer. This allows unexpected messages to directly reuse the regular message buffer already allocated by the control end to complete subsequent processing without triggering a retransmission process or requiring the execution end to occupy additional dedicated buffer resources. Ultimately, zero retransmission and low-latency processing of unexpected messages are achieved, and the collaboration between the control end and the execution end is closer and more efficient, improving the efficiency of unexpected message processing. Attached Figure Description

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

[0047] Figure 1 This is an application environment diagram of an unexpected message handling method in one embodiment;

[0048] Figure 2 This is a flowchart illustrating an unexpected message handling method in one embodiment;

[0049] Figure 3This is a flowchart illustrating an unexpected message handling method in another embodiment;

[0050] Figure 4 This is a schematic diagram of the system initialization and command pre-deployment steps in one embodiment;

[0051] Figure 5 This is a schematic diagram illustrating the message reception and expected message matching steps in one embodiment;

[0052] Figure 6 This is a schematic diagram of the execution end's autonomous handling steps for unexpected messages in one embodiment;

[0053] Figure 7 This is a schematic diagram of the matching and data transfer steps of the new buffer in one embodiment;

[0054] Figure 8 This is a schematic diagram illustrating how performance overhead and latency are avoided in one embodiment;

[0055] Figure 9 This is a schematic diagram illustrating the reduction of software overhead in one embodiment;

[0056] Figure 10 This is a schematic diagram illustrating the implementation of improved scalability in one embodiment;

[0057] Figure 11 This is a flowchart illustrating an unexpected message handling method in another embodiment;

[0058] Figure 12 This is a flowchart illustrating an unexpected message handling method in yet another embodiment;

[0059] Figure 13 This is a structural block diagram of an unexpected message processing device in one embodiment;

[0060] Figure 14 This is a structural block diagram of an unexpected message processing device in another embodiment;

[0061] Figure 15 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0062] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0063] The unexpected message handling method provided in this application embodiment can be applied to, for example, Figure 1In the application environment shown, the execution end 102 communicates with the control end 104 via a network. The execution end (hardware end, i.e., the receiving network card) refers to the hardware entity located on the data receiving side in RDMA (Remote Direct Memory Access) network communication, typically an RDMA network card deployed on a server. The execution end is responsible for receiving, verifying, and temporarily storing messages at the network layer. It has the ability to directly manipulate the hardware buffer, but it does not have the ability to autonomously decide the subsequent message processing flow; its behavior is driven by instructions issued by the control end. In this application, the execution end undertakes the responsibilities of receiving unexpected messages on the hardware side, separating and storing message headers and data payloads, and exchanging status notifications with the control end. The control end (software end, i.e., user-mode driver software) is the interface between the user-mode application and the network card. After a successful unexpected message match, the control end moves the data from the unexpected message buffer to the regular message buffer, enabling the user-mode application to access the data (the user-mode application can only access its requested regular message buffer). The control terminal is responsible for initiating communication requests, managing the allocation and reclamation of the receive buffer, and determining the message consumption logic. It possesses global resource scheduling and decision-making capabilities but does not directly operate the network interface card (NIC) hardware. In this application, the control terminal undertakes the responsibilities of receiving unexpected message arrival notifications, actively allocating regular message buffers, and copying data payloads to designated buffers based on matching results. It is the core decision-making force of the entire unexpected message processing flow. Specifically, during the unexpected message processing process, when the execution terminal 102 receives an unexpected message, it stores the data payload portion of the unexpected message in the unexpected message buffer and stores the message header descriptor of the unexpected message in the on-chip message header buffer; it sends an unexpected message arrival notification carrying the message header descriptor to the control terminal 104; when it receives a new regular message buffer allocated by the control terminal 104, it reads the buffer information of the allocated buffer; if a target message header descriptor matching the buffer information exists in the on-chip message header buffer, it sends an unexpected message matching success notification to the control terminal 104; the unexpected message matching success notification is used to instruct the control terminal 104 to copy the data payload portion corresponding to the target message header descriptor to the new regular message buffer.

[0064] In one exemplary embodiment, such as Figure 2 As shown, an unexpected message handling method is provided, which is applied to... Figure 1 Taking the execution terminal 102 as an example, the explanation includes the following steps S202 to S208. Wherein:

[0065] In step S202, upon receiving an unexpected message, the data payload portion of the unexpected message is stored in the unexpected message buffer, and the message header descriptor of the unexpected message is stored in the on-chip message header buffer.

[0066] An unexpected message refers to a message received by the execution end (receiving end network card) on the network, but the control end has not yet issued the corresponding receive command, or the receive command has not yet reached the execution end; that is, the execution end is not yet ready to receive the message. The data payload refers to the actual user data content carried in the unexpected message, which is the actual payload to be transmitted, excluding the message header. The unexpected message buffer is a memory area used to temporarily store the data payload of unexpected messages. This memory is requested and allocated by the control end from the host memory during the communication initialization phase, associated with a dedicated host memory area, serving as a general data temporary storage pool for unexpected messages. The message header descriptor is a simplified description or summary of the message header of the unexpected message (containing control information such as source address, destination address, message length, and message identifier). It is not the complete message header, but rather a descriptive information that can uniquely identify the message. The on-chip message header buffer is located in the message header buffer (on-chip SRAM (Static Random Access Memory)) inside the network card chip. It is a memory area specifically used to store message header descriptors. It is a separate memory area from the accidental message buffer. The message header is stored here, and the data payload is stored there. The two are physically isolated.

[0067] Specifically, the executing end (receiving end network card) receives a message on the network. The executing end first checks if there is a corresponding receive buffer for this message. It finds that the control end (software end, i.e., user-space driver software) has not yet issued a receive command or the receive command has not yet reached the executing end, meaning the receive buffer is not ready. Therefore, it determines this message to be an unexpected message. The executing end splits this unexpected message into two parts: a message header and a data payload. Instead of storing the entire message together, the executing end extracts the key information from the message header, generates a message header descriptor, and stores this message header descriptor in the on-chip message header buffer. Simultaneously, it extracts the message's data payload (i.e., the actual user data) and stores it separately in the unexpected message buffer. In this way, the message header descriptor and the data payload are stored in two different memory areas, allowing for independent lookup and matching later.

[0068] Step S204: Send an unexpected message arrival notification carrying a message header descriptor to the control terminal.

[0069] In RDMA (Remote Direct Memory Access) network communication, the execution end (hardware end, i.e., the receiving network card) refers to the hardware entity located on the data receiving side, typically an RDMA network card deployed on a server. The execution end is responsible for receiving, verifying, and temporarily storing packets at the network layer. It has the ability to directly manipulate the hardware buffer but lacks the ability to autonomously decide on subsequent message processing; its behavior is driven by instructions issued by the control end. In this application, the execution end is responsible for receiving unexpected messages on the hardware side, separating and storing message headers and data payloads, and exchanging status notifications with the control end. The control end (software end, i.e., the upper-layer application) refers to the software entity located on the data sending or receiving side in RDMA network communication, typically an application or communication middleware running in user space. The control end is responsible for initiating communication requests, managing the allocation and reclamation of the receive buffer, and determining message consumption logic. It has global resource scheduling and decision-making capabilities but does not directly manipulate the network card hardware. In this application, the control terminal is responsible for receiving unexpected message arrival notifications, proactively allocating regular message buffers, and copying data payloads to designated buffers based on matching results. It is the core decision-maker in the entire unexpected message handling process. An unexpected message arrival notification is a notification message proactively sent by the execution terminal to the control terminal, informing the control terminal that "I have received an unexpected message that you are not yet ready to receive." This notification typically includes a summary of the unexpected message's key header information (such as tag value, length, etc.) so that the control terminal can detect the occurrence of the unexpected message and may trigger subsequent buffer distribution actions. For example, the notification can be sent via an event queue or an interrupt method.

[0070] Specifically, after storing the data payload and message header descriptor in step S202, the execution end constructs an unexpected message arrival notification. This notification is an internal control message sent from the execution end to the control end. During construction, the execution end fills the fields of the message header descriptor into the designated positions of the notification message in a pre-defined order. After construction, the execution end sends the notification to the control end via an event queue or interrupt. Upon receiving the notification, the control end can determine from the message header descriptor carried in the notification that an unexpected message with a specific characteristic X has arrived at the execution end, and its data payload has been temporarily saved, awaiting allocation of a regular message buffer by the control end.

[0071] Step S206: Upon receiving a new regular message buffer allocated by the control terminal, read the buffer information of the allocated buffer.

[0072] The new regular message buffer is a buffer dynamically allocated by the control end to handle unexpected messages after receiving notification of their arrival. Buffer information is attribute data describing a new regular message buffer, including at least its starting address, length, memory key, or buffer index number.

[0073] Specifically, after receiving the unexpected message arrival notification sent in step S204, the control terminal, based on the message header descriptor carried in the notification and the current system resource status, decides to allocate a new regular message buffer for the unexpected message. The control terminal selects an idle regular message buffer from the regular message buffer pool. This buffer usually has its memory address and memory key already registered and was originally intended to process normal and expected messages. After selecting the buffer, the control terminal sends the buffer information to the execution terminal through the internal control channel. After receiving the buffer information, the execution terminal reads this information and saves it in its internal register or temporary variable. The execution terminal does not immediately use this information for data copying but instead proceeds to the next matching process. The process of reading the buffer information includes: verifying the integrity of the buffer information, parsing fields such as the start address and length, and storing this information locally on the execution terminal for comparison with entries in the on-chip message header buffer.

[0074] In step S208, if a target message header descriptor matching the buffer information exists in the on-chip message header buffer, an unexpected message matching success notification is sent to the control terminal. The unexpected message matching success notification is used to instruct the control terminal to copy the data payload portion corresponding to the target message header descriptor to a new regular message buffer.

[0075] The target message header descriptor refers to the message header descriptor in the on-chip message header buffer that matches the buffer information of the newly allocated regular message buffer; in other words, it is the message header descriptor corresponding to this unexpected message. The unexpected message match success notification is a notification sent from the execution end to the control end, informing the control end that "a message header descriptor matching the newly allocated buffer was found in the on-chip message header buffer; the match was successful."

[0076] Specifically, after completing the reading of the buffer information in step S206, the execution end begins the matching operation. It traverses the SRAM (Static Random-Access Memory) linked list or uses CAM (Content-Addressable Memory) matching to match the newly received receive command with the corresponding type of unexpected message. Specifically: if the new regular message buffer is a TRQE (Tag Receive Queue Entry): it searches the unexpected message header buffer for a Tag-type unexpected message record with a completely matching Tag value. If the new regular message buffer is an RQE (Receive Queue Entry): it compares whether the length of the unexpected message data in the unexpected message header buffer is greater than or equal to the size of the buffer associated with that RQE. If the match is successful, the execution end reads the complete information of the unexpected message header record from the message header buffer, especially the starting address and data length of the data in the unexpected message buffer. It can be understood that the execution end does not automatically perform a DMA copy from the unexpected message buffer to the new regular message buffer. This is because the data in the unexpected message buffer may be directly consumed by the application layer or require more flexible processing by the control end (such as partial reception or truncation), and automatic copying by the execution end would introduce significant bandwidth overhead for PCIe access. Therefore, this solution adopts a method of notifying the control end to perform the copy. The execution end reports an "unexpected message match successful" notification to the control end. This notification carries the following key information: the message header and URQE information of the successfully matched unexpected message, and the newly issued RQE / TRQE information used in this match. After reporting, the execution end clears the unexpected message record from the message header cache to free up on-chip storage space. After receiving the unexpected message match successful notification, the control end performs a memory copy operation (such as calling memcpy) to copy the data payload portion corresponding to the target message header descriptor to a new regular message buffer.

[0077] The aforementioned unexpected message handling method, upon receiving an unexpected message at the execution end, separates and stores the data payload and message header descriptor into an unexpected message buffer and an on-chip message header buffer. This decouples the message header and data payload on the hardware side, preventing the execution end from blocking or discarding data due to unexpected messages. Furthermore, by sending an unexpected message arrival notification carrying only the message header descriptor to the control end, the control end can promptly detect the arrival of the unexpected message without obtaining the complete message content. The control end then proactively allocates a new regular message buffer, avoiding the additional latency and bandwidth overhead caused by the sender's passive waiting, timeout retransmission, and the control end's complete lack of awareness in traditional mechanisms. Further, after receiving the regular message buffer allocated by the control end, the execution end... By reading the buffer information and matching it in the on-chip message header buffer, the accurate association between the message header descriptor and the newly allocated regular message buffer at the control end is ensured. Then, when the match is successful, an unexpected message matching success notification is sent to the control end, instructing the control end to copy the data payload part corresponding to the target message header descriptor to the regular message buffer. This allows unexpected messages to directly reuse the regular message buffer already allocated by the control end to complete subsequent processing without triggering a retransmission process or requiring the execution end to occupy additional dedicated buffer resources. Ultimately, zero retransmission and low-latency processing of unexpected messages are achieved, and the collaboration between the control end and the execution end is closer and more efficient, improving the efficiency of unexpected message processing, while avoiding the CPU load introduced by the control end in matching unexpected messages with the regular buffer.

[0078] In an exemplary embodiment, the method further includes: obtaining received message information; extracting fields from the message information to obtain key field information of the message information; matching the key field information with the internally cached regular message buffer, and determining that the message information is an unexpected message if the matching fails.

[0079] The message information refers to a complete message received by the execution end (receiving end network card) from the network, consisting of a message header and a data payload. Field extraction refers to the operation of parsing each field from the message information according to the protocol format, including: message type (tag message or non-tag message), tag value (if any), message data payload length, and sender identifier (such as source QP number). Key field information refers to the core fields extracted from the message information used to determine which buffer should receive the message. Internal cached regular message buffers refer to the information of those regular message buffers that are pre-cached on the execution end and for which the control end (software side, i.e., user-space driver software) has issued receive commands. This information includes the buffer's address, size, and tag; the execution end compares this information with the received message.

[0080] Specifically, after receiving a message on the network, the execution end first extracts the fields from the message, parsing each field according to the protocol format to obtain the key field information. Then, the execution end uses this key field information to match it against its internally cached regular message buffers. These regular message buffers refer to those buffers where the control end has previously issued receive commands; the execution end caches information such as the address, size, and label of these buffers. The matching process involves checking if the key field information matches any regular message buffer. If none of the regular message buffers match, the execution end determines that this message is an unexpected message, meaning the control end has not yet prepared a receive buffer for this message.

[0081] For example, the execution end can extract the Tag value from the message information and use it as an index to search and compare in the internal cached TRQE pool. If a TRQE exists whose Tag value matches the message's Tag value, a successful match is determined. After a successful match, the execution end obtains the physical address of the target buffer from the TRQE and starts the DMA engine to directly write the data payload of the message information into the host memory buffer. After writing is complete, the hardware reports a reception completion notification to the software according to the configuration. Alternatively, the size of the buffer associated with each RQE is compared one by one. If the remaining space in the buffer is greater than or equal to the payload length of the current message, a successful match is determined. After a successful match, the execution end obtains the physical address of the target buffer from the RQE, starts DMA to write the data payload into the buffer, and reports a completion event as appropriate. The process ends. If, after the above search, a Tag message fails to find a TRQE with a matching Tag value, or a non-Tag message fails to find a buffer with sufficient space after traversing all RQEs, the message is determined to be an unexpected message.

[0082] In this embodiment, by extracting key fields after receiving a message and then matching them with the cached regular message buffer, the automatic determination of unexpected messages is achieved. The execution end does not need to rely on the feedback from the control end to directly identify which messages are unexpected messages on the hardware side, providing accurate triggering conditions for subsequent separation storage and notification processes.

[0083] In an exemplary embodiment, the regular message buffer includes a tagged buffer and a non-tagged buffer; matching key field information with the internally cached regular message receiving buffer includes: if the key field information contains a tag, then if the matching result between the tag and the buffer tag of the tag buffer is a failure, then the matching is determined to be a failure; if the key field information does not contain a tag, then if the length of the message data contained in the key field information is greater than the length of the buffer data of the non-tagged buffer, then the matching is determined to be a failure.

[0084] In this context, a tagged buffer (TRQE) is a regular message buffer with a tagged identifier, specifically designed to receive tagged messages. The buffer itself carries a buffer tag used to match tags in the message's key fields. An untagged buffer (RQE) is a regular message buffer without a tag, specifically designed to receive untagged ordinary Send messages. A tag is an identifier field carried in the message's key fields, used to distinguish messages of different types or origins. Message data length refers to the length of the message's data payload carried in the message's key fields. Buffer tags are the tag identifiers carried by the tagged buffer itself, used to compare with tags in the message's key fields. Buffer data length refers to the data length information of the untagged buffer, used to represent the remaining space in the buffer.

[0085] Specifically, if the key field information contains a tag, and the tag message fails to find a TRQE with a matching tag value, then the matching result of the tag and the buffer tag of the tag buffer is a match failure; if the key field information does not contain a tag, and if a buffer with sufficient space is not found after traversing all RQEs, then it is determined that the length of the message data contained in the key field information is greater than the length of the buffer data of the non-tag buffer, and the match fails.

[0086] In this embodiment, by subdividing the regular message buffer into a labeled buffer and an unlabeled buffer, and setting matching rules for the labeled and unlabeled cases respectively, the matching judgment is more accurate, avoiding misjudgment caused by using a single rule to match all messages, and also allowing the execution end to quickly complete the filtering of unexpected messages on the hardware side.

[0087] In one exemplary embodiment, the method further includes: if a match is successful, obtaining the physical address of a regular message buffer; and writing the data payload portion into the regular message buffer according to the physical address.

[0088] The physical address refers to the actual physical address of the regular message buffer in memory, not a virtual address. The execution end needs this address to write data directly into it.

[0089] Specifically, upon successful matching, the executing end obtains the physical address of the target buffer from the TRQE and starts the DMA engine to directly write the data payload of the message into the host memory buffer. After writing is complete, the executing end reports a reception completion notification to the control end according to the configuration.

[0090] In this embodiment, by directly obtaining the physical address and writing the data payload into the regular message buffer after a successful match, zero-copy hardware direct writing of regular messages is achieved. The execution end does not need to notify the control end, nor does the control end need to participate in data transfer, thus reducing communication overhead and processing latency.

[0091] In one exemplary embodiment, such as Figure 3 As shown, an unexpected message handling method is also provided, applied to the control end; the method includes:

[0092] Step S302: Upon receiving an unexpected message arrival notification with a message header descriptor sent by the execution end, a new regular message buffer is allocated to the execution end; the unexpected message arrival notification is sent by the execution end after receiving the unexpected message, storing the data payload of the unexpected message in the unexpected message buffer, and storing the message header descriptor of the unexpected message in the on-chip message header buffer.

[0093] Step S304: Upon receiving an unexpected message matching success notification from the execution end, the data payload portion corresponding to the target message header descriptor is copied to a new regular message buffer. The unexpected message matching success notification is sent by the execution end upon receiving the new regular message buffer, after reading the buffer information of the allocated buffer, and if a target message header descriptor matching the buffer information exists in the on-chip message header buffer.

[0094] Specifically, during operation, the control unit receives an unexpected message arrival notification from the execution unit. This notification is proactively sent by the execution unit after receiving the unexpected message, storing the data payload in the unexpected message buffer, and storing the message header descriptor in the on-chip message header buffer. The notification includes the message header descriptor, so the control unit knows that an unexpected message is waiting on the execution unit. Upon receiving this notification, the control unit proactively allocates a new regular message buffer specifically for this unexpected message and sends the buffer information to the execution unit. The execution unit then matches the message in the on-chip message header buffer. If a match is found, it sends back an unexpected message matching success notification. Upon receiving this matching success notification, the control unit performs a data copy operation, copying the data payload corresponding to the target message header descriptor from the execution unit's unexpected message buffer to its newly allocated regular message buffer. Thus, this unexpected message officially enters the regular message processing flow.

[0095] In one exemplary embodiment, the method further includes: issuing a new unexpected message buffer if the remaining buffer space of the unexpected message buffer does not meet a preset space condition.

[0096] The remaining buffer space refers to the unused space in the unexpected message buffer that can continue to store new unexpected message data payloads. The preset space condition refers to a pre-defined space threshold; for example, if the remaining space is less than a certain percentage or a fixed size, it is considered insufficient.

[0097] Specifically, in extreme cases, the unexpected message buffer may run out, and the on-chip SRAM cache storing message headers may also be full. The execution end can fall back to the existing mechanism of temporarily discarding unexpected message packets and retransmitting them, and take the following measures: when the unexpected message buffer is about to run out, the control end needs to issue a new URQE to provide additional unexpected message buffer space. At the same time, the control end also needs to speed up the data copying and release of unexpected messages.

[0098] In this embodiment, by actively issuing a new buffer when the space of the unexpected message buffer is insufficient, the problem of data loss due to the exhaustion of the buffer space is avoided, ensuring the continuity and reliability of unexpected message processing. At the same time, dynamic management of the buffer is realized through preset space conditions, so that the execution end does not need to judge whether the space is sufficient.

[0099] In an exemplary embodiment, the method further includes: pre-allocating a regular message buffer and an unexpected message buffer, and writing the buffer information of the regular message buffer and the unexpected message buffer into a command queue; sending a receive command notification to the execution end; and receiving the command notification, which instructs the execution end to retrieve the buffer information from the command queue and cache the address description information of the regular message buffer and the unexpected message buffer.

[0100] The command queue is a shared queue between the control end and the execution end. The control end writes buffer information into it, and the execution end reads it from it.

[0101] Specifically, before system initialization or message processing begins, the control terminal pre-allocates regular message buffers and unexpected message buffers. These are memory areas pre-allocated by the control terminal. The control terminal writes the buffer information of each buffer, including address, size, ID, and tag, into the command queue. Then, the control terminal sends a receive command notification to the execution terminal. Upon receiving the receive command notification, the execution terminal retrieves the buffer information of the regular message buffer and unexpected message buffer from the command queue and caches the address description information of each buffer. This way, when the execution terminal receives a message subsequently, it can directly use the locally cached address description information for matching, without having to read from the command queue every time, thus improving matching efficiency.

[0102] In one specific embodiment, an unexpected message handling method is also provided, including the following steps:

[0103] Step 1: System initialization and pre-deployment of received commands (receive command caching stage);

[0104] like Figure 4 As shown, before the communication service is officially launched, the host-side driver control terminal (driver software) performs the following initialization operations:

[0105] The control terminal requests buffers: Before the reception service begins, the control terminal requests three types of receive buffers from main memory:

[0106] Regular message buffers include tag message receive buffers (tag buffers) and non-tag message receive buffers (non-tag buffers);

[0107] Among them, the Tag message receiving buffer is used to receive messages with Tag identifiers. After requesting the buffer, the control end writes the buffer address / length and the Tag value used to match the message into TRQE.

[0108] Non-Tag Message Receive Buffer: Used to receive ordinary Send messages. After requesting the buffer, the control end writes the buffer address and length into the RQE.

[0109] Unexpected message buffer: Used to store message information of unexpected messages. After the control end requests it, it writes the address and length of the unexpected message buffer into URQE.

[0110] Send commands to the execution end:

[0111] The control unit writes the TRQE, RQE, and URQE descriptors corresponding to the above buffers into the command queue located in the host memory.

[0112] The control terminal notifies the execution terminal of a new receive command by writing to the network card execution terminal register (i.e., "ringing the execution terminal doorbell").

[0113] Execution-side cached command information:

[0114] After the doorbell processing module in the network card execution end detects a doorbell update, it reads the newly issued TRQE, RQE, and URQE content from the command queue in the host memory via the PCIe bus.

[0115] The read URQE information (mainly the base address of the unexpected buffer and the current available space status) and RQE and TRQE are cached in the shared cache module inside the network card chip for use in subsequent packet processing.

[0116] Step 2: Matching received messages with expected messages (message matching buffer stage);

[0117] like Figure 5 As shown, when a network packet arrives at the network card receiver from the physical link, the receiving processing module first parses the packet and extracts key fields, including: message type (tag message or non-tag message), tag value (if any), message data payload length, and sender identifier (such as source QP number). It can be understood that the execution end in this embodiment may include multiple modules, each responsible for a corresponding function, collectively implementing all the functions required by the execution end.

[0118] Subsequently, the receiving and processing module delivers the parsed message information to the expected message matching module. This module executes different matching logic based on the message type:

[0119] Tag message matching process:

[0120] The expected message matching module extracts the Tag value from the message and uses it as an index to search and compare it in the TRQE pool cached internally by the execution end.

[0121] If a TRQE exists that carries a tag value that matches the tag value of the message, then the match is considered successful.

[0122] Upon successful matching, the executing end retrieves the physical address of the target buffer from the TRQE and initiates the DMA engine to directly write the packet's data payload into the host memory buffer. After writing is complete, the executing end reports a reception completion notification to the control end according to the configuration.

[0123] Non-Tag Message Matching Process:

[0124] The size of the buffer associated with each RQE is compared one by one. If the remaining space in the buffer is greater than or equal to the payload length of the current message, the match is considered successful.

[0125] Upon successful matching, the executing end obtains the physical address of the target buffer from the RQE, initiates DMA to write the data payload into the buffer, and reports a completion event as needed. The process ends.

[0126] Handling matching failures:

[0127] If, after the above search, the Tag message fails to find a TRQE with a matching Tag value, or if the non-Tag message fails to find a buffer with sufficient space after traversing all RQEs, then the message is determined to be an unexpected message.

[0128] At this point, the expected message matching module abandons processing the message and forwards it to the unexpected message handling module, proceeding to step three.

[0129] Step 3: Unexpected messages are handled autonomously by the execution end (unexpected message handling stage);

[0130] like Figure 6 As shown, the unexpected message handling module is specifically responsible for handling messages that failed to match in step two. Its internal workflow is as follows:

[0131] Obtain URQE information:

[0132] The unexpected message handling module sends a read request to the shared cache module to obtain the currently valid URQE information (including the base address of the unexpected buffer, the current write pointer, etc.).

[0133] Data payload written to main memory:

[0134] The unexpected message processing module writes the data payload portion of the message into the unexpected message buffer in the host memory associated with the URQE via the PCIe bus, based on the address in the URQE.

[0135] Message headers are cached on-chip:

[0136] At the same time, the execution end extracts and organizes the message header information of the message to form a concise message header descriptor structure.

[0137] The message header descriptor is written into the message header buffer inside the network interface card (NIC) chip. The message header buffer can be implemented using content-addressable memory (CAM) or ordinary SRAM in conjunction with a linked list structure to support fast lookup operations.

[0138] Because only header information is stored, the on-chip SRAM space occupied by a single unexpected message is reduced to tens of bytes, allowing the limited on-chip storage to hold index records of tens of thousands of unexpected messages.

[0139] Report a notification to the control terminal:

[0140] The execution end reports an "unexpected message has arrived" event notification to the drive control end (which can be done through an event queue or an interrupt).

[0141] The notification typically includes a summary of key header information for the unexpected message (such as tag value, length, etc.) so that the control end can detect the occurrence of the unexpected message and may trigger subsequent buffer delivery actions.

[0142] Step 4: Matching and transferring data in the new buffer (unexpected message matching in the newly issued buffer stage);

[0143] like Figure 7 As shown, when the upper-layer application subsequently executes a receive call and publishes the expected receive buffer that should have been published before step two but was delayed (i.e., the control end issues a new RQE or TRQE to the execution end), the following automatic matching process on the execution end will be triggered:

[0144] Intercept newly issued commands:

[0145] When the execution-end command parsing module receives a new RQE or TRQE command, it does not immediately store it in the internal SRAM buffer to wait for new messages to arrive. Instead, it first hands it over to the buffer matching module.

[0146] Automatic matching and comparison at the execution end:

[0147] The unexpected message matching module reads the matching information from the newly issued RQE / TRQE (if it is RQE, it mainly includes the buffer size; if it is TRQE, it includes the tag value and the buffer size).

[0148] Subsequently, the module traverses the SRAM linked list or uses CAM matching to match the newly received receive command with the corresponding type of unexpected message. The matching method is the same as in step two, namely:

[0149] If TRQE: Check if there is an unexpected message record of the Tag class with the exact same Tag value in the unexpected message header cache.

[0150] If it is RQE: Check if the length of the unexpected message data in the unexpected message header cache is greater than or equal to the buffer size associated with the RQE.

[0151] Processing after a successful match:

[0152] If a match is found, the execution end reads the complete information of the unexpected message header record from the message header cache, especially the starting address and length of the data in the unexpected buffer.

[0153] Key action: The execution end does not automatically perform a DMA copy from the unexpected buffer to the expected buffer. This is because the data in the unexpected buffer may be directly consumed by the application layer later, or requires more flexible processing by the control end (such as partial reception, truncation, etc.), and automatic copying by the execution end would introduce significant bandwidth overhead for PCIe access. Therefore, this solution adopts a method of notifying the control end to perform the copy.

[0154] The execution end reports a special notification event to the drive control end, indicating that an unexpected message match was successful. This notification carries the following key information:

[0155] The message header and URQE information of the unexpected message that was successfully matched.

[0156] The newly issued RQE / TRQE information used in this matching.

[0157] After the report is completed, the execution end will clear the unexpected message record from the message header cache to free up on-chip storage space.

[0158] The control terminal performs a data copy:

[0159] After receiving the "match successful" notification, the driver control terminal performs a memory copy operation (such as calling memcpy) to copy the data in the unexpected message buffer to the expected receive buffer.

[0160] In extreme cases, the unexpected message buffer may run out, and the on-chip SRAM cache storing message headers may also become full. The execution end can fall back to the existing mechanism of temporarily discarding unexpected message packets and retransmitting them, and take the following measures:

[0161] When the unexpected message buffer is about to run out, the control terminal needs to issue a new URQE to provide additional unexpected message buffer space. At the same time, the control terminal speeds up the data copying and release process for unexpected messages.

[0162] By using the above method, the following technical effects can be achieved:

[0163] 1. Avoid performance overhead and latency:

[0164] like Figure 8 As shown, a dedicated unexpected message buffer is introduced, which is requested from main memory by the software and then sent to the hardware before the service begins. When the receiving end fails to send the expected receive buffer in time or the receive buffer fails to match, the received message will not enter the RNR exception handling process, thus avoiding the performance overhead and communication delay caused by the sender's retries.

[0165] 2. Implement CPU offloading to reduce software overhead:

[0166] like Figure 9 As shown, an on-chip message header buffer and message header matching module are added, allowing hardware to match unexpected message headers with subsequent message receive commands. The software only needs to perform a single data transfer from the unexpected message buffer to the expected receive buffer after a successful match, eliminating the need for message matching and multiple data copying processes, significantly reducing CPU load.

[0167] 3. Saves chip area and improves scalability:

[0168] like Figure 10 As shown, the message header and message data of unexpected messages are stored separately: the message header (which occupies a small space) is stored in on-chip SRAM, while the message data (which occupies a large space) is stored in the unexpected message buffer in main memory. This separate storage architecture significantly reduces the demand for on-chip SRAM capacity, overcomes chip area limitations, and enables the system to handle application scenarios where a large number of unexpected messages occur in a short period of time.

[0169] 4. Improve resource utilization:

[0170] Each Unexpected Message Receive (URQE) associated with an unexpected message buffer can be shared by multiple unexpected messages until the buffer is full. Compared to a scheme that allocates a separate receive buffer for each QP, this sharing mechanism significantly improves memory resource utilization and reduces resource waste.

[0171] 5. Supports dynamic many-to-many communication:

[0172] It eliminates the need to pre-allocate a receive buffer for each potential sender before communication begins, reducing the complexity of connection management. Unexpected messages are handled efficiently as regular communication states, adapting to the dynamic and uncertain workloads in AI / HPC scenarios.

[0173] 6. Maintain high performance in hardware processing:

[0174] Message header matching and unexpected message handling are both performed in hardware, leveraging the high-speed access capabilities of on-chip SRAM to ensure low latency in message processing. Meanwhile, data is stored in main memory, utilizing its large capacity to achieve a balance between performance and capacity.

[0175] In a specific embodiment, such as Figure 11 As shown, an unexpected message handling method is also provided, applied to the execution end, including:

[0176] Step S1101: Obtain the received message information;

[0177] Step S1102: Extract fields from the message information to obtain key field information of the message information;

[0178] Step S1103: If the key field information contains a tag, then if the matching result between the tag and the tag in the tag buffer is a failure, then the matching is determined to be a failure.

[0179] Step S1104: If the key field information does not contain a tag, then if the length of the message data contained in the key field information is greater than the buffer data length of the non-tag buffer, then the matching is determined to be unsuccessful.

[0180] Step S1105: If the match is successful, obtain the physical address of the regular message buffer;

[0181] Step S1106: Write the data payload portion into the regular message buffer according to the physical address;

[0182] Step S1107: If the matching fails, determine that the message information is an unexpected message;

[0183] Step S1108: Upon receiving an unexpected message, the data payload portion of the unexpected message is stored in the unexpected message buffer, and the message header descriptor of the unexpected message is stored in the on-chip message header buffer.

[0184] Step S1109: Send an unexpected message arrival notification carrying a message header descriptor to the control terminal;

[0185] Step S1110: Upon receiving a new regular message buffer allocated by the control terminal, read the buffer information of the allocated buffer.

[0186] Step S1111: If a target message header descriptor matching the buffer information exists in the on-chip message header buffer, an unexpected message matching success notification is sent to the control terminal. The unexpected message matching success notification is used to instruct the control terminal to copy the data payload portion corresponding to the target message header descriptor to a new regular message buffer.

[0187] In a specific embodiment, such as Figure 12 As shown, an unexpected message handling method is also provided, applied to the execution end, including:

[0188] Step S1201: Pre-allocate regular message buffers and unexpected message buffers, and write the buffer information of each of the regular message buffers and unexpected message buffers into the command queue;

[0189] Step S1202: Send a receive command notification to the execution end;

[0190] Among them, receiving command notifications is used to instruct the execution end to retrieve information from each buffer from the command queue and to cache the regular message buffer and the unexpected message buffer;

[0191] Step S1203: Upon receiving an unexpected message arrival notification with a message header descriptor sent by the execution end, a new regular message buffer is allocated to the execution end; the unexpected message arrival notification is sent by the execution end after receiving the unexpected message, storing the data payload of the unexpected message in the unexpected message buffer, and storing the message header descriptor of the unexpected message in the on-chip message header buffer.

[0192] Step S1204: Upon receiving an unexpected message matching success notification from the execution end, copy the data payload portion corresponding to the target message header descriptor to a new regular message buffer.

[0193] Among them, the unexpected message matching success notification is sent by the execution end when it receives a new regular message buffer, reads the buffer information of the allocated buffer, and sends it if there is a target message header descriptor that matches the buffer information in the on-chip message header buffer.

[0194] Step S1205: If the remaining buffer space of the unexpected message buffer does not meet the preset space condition, a new unexpected message buffer is issued.

[0195] It should be understood that although the steps in the flowcharts of the above embodiments 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 above embodiments 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 some of the steps or stages of other steps.

[0196] Based on the same inventive concept, this application also provides an unexpected message processing apparatus for implementing the unexpected message processing method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more unexpected message processing apparatus embodiments provided below can be found in the limitations of the unexpected message processing method described above, and will not be repeated here.

[0197] In one exemplary embodiment, such as Figure 13 As shown, an unexpected message processing device 1300 is provided, applied to an execution end, including: a message storage module 1302, a first notification sending module 1304, an information reading module 1306, and a second notification sending module 1308, wherein:

[0198] The message storage module 1302 is used to store the data payload of the unexpected message in the unexpected message buffer and store the message header descriptor of the unexpected message in the on-chip message header buffer when an unexpected message is received.

[0199] The first notification sending module 1304 is used to send an unexpected message arrival notification carrying a message header descriptor to the control terminal;

[0200] The information reading module 1306 is used to read the buffer information of the allocated buffer when a new regular message buffer is allocated by the control terminal.

[0201] The second notification sending module 1308 is used to send an unexpected message matching success notification to the control terminal when a target message header descriptor matching the buffer information exists in the on-chip message header buffer. The unexpected message matching success notification is used to instruct the control terminal to copy the data payload part corresponding to the target message header descriptor to a new regular message buffer.

[0202] In one exemplary embodiment, the unexpected message processing apparatus 1300 further includes an unexpected message determination module, comprising:

[0203] The message information acquisition unit is used to acquire the received message information;

[0204] The field extraction unit is used to extract fields from the message information to obtain the key field information of the message information;

[0205] The unexpected message determination unit is used to match key field information with the internal cached regular message buffer. If the match fails, the message information is determined to be an unexpected message.

[0206] In one exemplary embodiment, the regular message buffer includes a labeled buffer and an unlabeled buffer. In this embodiment, the unexpected message determination unit is specifically used for:

[0207] If the key field information contains tags, then if the matching result between the tag and the tag in the tag buffer is a failure, then the matching is considered a failure.

[0208] If the key field information does not contain a tag, then if the length of the message data contained in the key field information is greater than the buffer data length of the non-tag buffer, the match is determined to be unsuccessful.

[0209] In one exemplary embodiment, the unexpected message processing device 1300 further includes a physical address acquisition module, specifically used for:

[0210] If a match is successful, obtain the physical address of the regular message buffer;

[0211] The data payload is written to the regular message buffer according to the physical address.

[0212] In one exemplary embodiment, such as Figure 14 As shown, an unexpected message processing device 1400 is provided, applied to a control terminal, including a buffer allocation module 1402 and a data payload copying module 1404, wherein:

[0213] The buffer allocation module 1402 is used to allocate a new regular message buffer to the execution end when it receives an unexpected message arrival notification carrying a message header descriptor sent by the execution end; the unexpected message arrival notification is sent by the execution end after storing the data payload of the unexpected message in the unexpected message buffer and storing the message header descriptor of the unexpected message in the on-chip message header buffer.

[0214] The data payload copy module 1404 is used to copy the data payload portion corresponding to the target message header descriptor to a new regular message buffer when receiving an unexpected message matching success notification sent by the execution end; the unexpected message matching success notification is sent by the execution end when receiving the new regular message buffer, reading the buffer information of the allocated buffer, and sending it if there is a target message header descriptor that matches the buffer information in the on-chip message header buffer.

[0215] In one exemplary embodiment, the unexpected message processing device 1400 further includes a buffer dispatch module, specifically used for:

[0216] If the remaining buffer space of the unexpected message buffer does not meet the preset space conditions, a new unexpected message buffer is issued.

[0217] In one exemplary embodiment, the unexpected message processing apparatus 1400 further includes a command queue writing module, specifically used for:

[0218] Pre-allocate regular message buffers and unexpected message buffers, and write the buffer information of each regular message buffer and unexpected message buffer into the command queue;

[0219] Send a receive command notification to the execution end; the receive command notification is used to instruct the execution end to retrieve information from each buffer from the command queue and cache the regular message buffer and the unexpected message buffer.

[0220] Each module in the aforementioned unexpected message processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the operations corresponding to each module.

[0221] In one exemplary embodiment, such as Figure 1As shown, an unexpected message processing system is also provided, including an execution terminal 102 and a control terminal 104. The execution terminal is communicatively connected to the control terminal, and includes an on-chip message header buffer. The execution terminal is used to, upon receiving an unexpected message, store the data payload portion of the unexpected message in an unexpected message buffer and store the message header descriptor of the unexpected message in the on-chip message header buffer; and send an unexpected message arrival notification carrying the message header descriptor to the control terminal. The control terminal is used to, upon receiving the unexpected message arrival notification, allocate a new regular message buffer to the execution terminal. The execution terminal is also used to, upon receiving the new regular message buffer allocated by the control terminal, read the buffer information of the allocated buffer; and if a target message header descriptor matching the buffer information exists in the on-chip message header buffer, send an unexpected message matching success notification to the control terminal. The control terminal is also used to, upon receiving the unexpected message matching success notification, copy the data payload portion corresponding to the target message header descriptor to the new regular message buffer.

[0222] Specifically, the unexpected message processing system consists of two parts: an execution end and a control end. The execution end, upon receiving an unexpected message, stores the data payload in the unexpected message buffer, stores the message header descriptor in the on-chip message header buffer, and then sends an unexpected message arrival notification carrying the message header descriptor to the control end. Simultaneously, after receiving a new regular message buffer allocated by the control end, the execution end reads the buffer information of this buffer and searches the on-chip message header buffer for a matching target message header descriptor. If a match is found, it sends an unexpected message matching success notification to the control end. The control end, upon receiving the unexpected message arrival notification, allocates a new regular message buffer to the execution end. Simultaneously, upon receiving the unexpected message matching success notification, the control end copies the data payload corresponding to the target message header descriptor from the execution end's unexpected message buffer to its own newly allocated regular message buffer. Each end performs its specific function: the execution end handles hardware-side reception, separation, storage, and matching, while the control end handles software-side resource allocation and data transfer, working together to complete the entire processing flow of unexpected messages from reception to final buffering.

[0223] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 15As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When executed by the processor, the computer program implements an unexpected message handling method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0224] Those skilled in the art will understand that Figure 15 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0225] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described above.

[0226] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0227] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described above.

[0228] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0229] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0230] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0231] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. An unexpected message handling method, characterized in that, Applied to the execution end; the method includes: Upon receiving an unexpected message, the data payload portion of the unexpected message is stored in the unexpected message buffer, and the message header descriptor of the unexpected message is stored in the on-chip message header buffer. Send an unexpected message arrival notification carrying the message header descriptor to the control terminal; Upon receiving a new regular message buffer allocated by the control terminal, read the buffer information of the allocated buffer; If a target message header descriptor matching the buffer information exists in the on-chip message header buffer, an unexpected message matching success notification is sent to the control terminal; the unexpected message matching success notification is used to instruct the control terminal to copy the data payload portion corresponding to the target message header descriptor to the new regular message buffer.

2. The method according to claim 1, characterized in that, The method further includes: Obtain the received message information; Field extraction is performed on the message information to obtain the key field information of the message information; The key field information is matched with the internal cached regular message buffer. If the match fails, the message information is determined to be an unexpected message.

3. The method according to claim 2, characterized in that, The regular message buffer includes a tagged buffer and a non-tagged buffer; matching the key field information with the internally cached regular message receive buffer includes: If the key field information contains a tag, then if the matching result between the tag and the buffer tag of the tag buffer is a match failure, then the match failure is determined. If the key field information does not contain a tag, then if the length of the message data contained in the key field information is greater than the buffer data length of the non-tag buffer, the matching is determined to be unsuccessful.

4. The method according to claim 2, characterized in that, The method further includes: If a match is successful, obtain the physical address of the regular message buffer; The data payload portion is written to the regular message buffer according to the physical address.

5. An unexpected message handling method, characterized in that, Applied to the control terminal; the method includes: Upon receiving an unexpected message arrival notification from the execution end carrying a message header descriptor, a new regular message buffer is allocated to the execution end; the unexpected message arrival notification is sent by the execution end after receiving the unexpected message, storing the data payload of the unexpected message in the unexpected message buffer, and storing the message header descriptor of the unexpected message in the on-chip message header buffer. Upon receiving an unexpected message matching success notification from the execution end, the data payload portion corresponding to the target message header descriptor is copied to the new regular message buffer. The unexpected message matching success notification is sent by the execution end upon receiving the new regular message buffer, after reading the buffer information of the allocated buffer, and if a target message header descriptor matching the buffer information exists in the on-chip message header buffer.

6. The method according to claim 5, characterized in that, The method further includes: If the remaining buffer space of the unexpected message buffer does not meet the preset space condition, a new unexpected message buffer is issued.

7. The method according to claim 5, characterized in that, The method further includes: Pre-allocate regular message buffers and unexpected message buffers, and write the buffer information of each of the regular message buffers and unexpected message buffers into the command queue; Send a receive command notification to the execution end; the receive command notification is used to instruct the execution end to obtain the information of each buffer from the command queue, and cache the address description information of the regular message buffer and the unexpected message buffer respectively.

8. An unexpected message processing device, applied at the execution end, characterized in that, The device includes: The message storage module is used to store the data payload of the unexpected message in the unexpected message buffer and store the message header descriptor of the unexpected message in the on-chip message header buffer when an unexpected message is received. The first notification sending module is used to send an unexpected message arrival notification carrying the message header descriptor to the control terminal; The information reading module is used to read the buffer information of the allocated buffer when a new regular message buffer is allocated by the control terminal. The second notification sending module is used to send an unexpected message matching success notification to the control terminal when a target message header descriptor matching the buffer information exists in the on-chip message header buffer; the unexpected message matching success notification is used to instruct the control terminal to copy the data payload portion corresponding to the target message header descriptor to the new regular message buffer.

9. An unexpected message processing device, applied to a control terminal, characterized in that, The device includes: The buffer allocation module is used to allocate a new regular message buffer to the execution end when it receives an unexpected message arrival notification carrying a message header descriptor sent by the execution end; the unexpected message arrival notification is sent by the execution end after receiving the unexpected message, storing the data payload of the unexpected message in the unexpected message buffer, and storing the message header descriptor of the unexpected message in the on-chip message header buffer. The data payload copy module is used to copy the data payload portion corresponding to the target message header descriptor to the new regular message buffer when receiving an unexpected message matching success notification sent by the execution end; the unexpected message matching success notification is sent by the execution end when receiving the new regular message buffer, reading the buffer information of the allocated buffer, and sending it if a target message header descriptor matching the buffer information exists in the on-chip message header buffer.

10. An unexpected message processing system, characterized in that, The system includes an execution terminal and a control terminal; the execution terminal is communicatively connected to the control terminal, and the execution terminal includes an on-chip message header buffer. The execution end is configured to, upon receiving an unexpected message, store the data payload portion of the unexpected message in the unexpected message buffer and store the message header descriptor of the unexpected message in the on-chip message header buffer. Send an unexpected message arrival notification carrying the message header descriptor to the control terminal; The control terminal is used to allocate a new regular message buffer to the execution terminal upon receiving the unexpected message arrival notification. The execution terminal is also used to read the buffer information of the allocated buffer when it receives a new regular message buffer allocated by the control terminal; If a target message header descriptor matching the buffer information exists in the on-chip message header buffer, an unexpected message matching success notification is sent to the control terminal. The control terminal is also configured to, upon receiving the notification of successful matching of the unexpected message, copy the data payload portion corresponding to the target message header descriptor to the new regular message buffer.

Images