Message matching method and message matching device
By using tagged storage units and bitmap information in distributed computing, the problem of low message matching efficiency is solved, achieving efficient message matching and overall performance improvement of the storage network.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- WUXI STARS MICRO SYSTEM TECHNOLOGIES CO LTD
- Filing Date
- 2026-03-18
- Publication Date
- 2026-06-30
AI Technical Summary
Existing message matching methods are inefficient in distributed computing and cannot efficiently match messages in the receive queue and the unexpected message queue.
By combining tag storage units and bitmap information, the matching process is shortened and the traversal of the PRQ list is reduced by first matching the target message in the tag storage unit and then obtaining the descriptor based on the bitmap information.
Significantly improves message matching efficiency, reduces PCIe bandwidth usage and CPU cache pollution, achieves line-speed reception and zero-copy to memory, supports multi-stream concurrency in the same queue, and enhances the overall efficiency and scalability of the storage network.
Smart Images

Figure CN122317023A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data communication technology, and in particular to a message matching method and a message matching device. Background Technology
[0002] In distributed computing, Message Passing Interfaces (MPIs) provide applications with a simple and powerful way to manage the exchange of information between processes. A fundamental challenge of these interfaces is ensuring that a message sent by a process is correctly received by the intended receiver; this goal is achieved through a message matching process.
[0003] Message matching involves pairing received messages with corresponding receive requests. Typically, the message matching process involves two queues: the Post Receive Queue (PRQ) and the Unexpected Message Queue (UMQ). The PRQ stores requests that have not yet arrived to receive messages, while the UMQ stores messages that have been received but not yet requested. Both the PRQ and UMQ are implemented as linked lists.
[0004] Currently, the main message matching method involves traversing the PRQ or UMQ linked list to match requests with messages when a new message arrives or a new receive request is published. However, traditional message matching methods suffer from low matching efficiency. Summary of the Invention
[0005] Therefore, it is necessary to provide a message matching method and device that can improve message matching efficiency in response to the above-mentioned technical problems.
[0006] Firstly, this application provides a message matching method, including:
[0007] Receive the target message sent by the upstream node; the target message includes the queue identifier and the first message identifier.
[0008] The first message identifier is matched with the second message identifier in the tag storage unit to obtain the first matching result; the second message identifier is the identifier of multiple requests in the published receive queue PRQ corresponding to the queue identifier;
[0009] If the first matching result is that there is no second message identifier in the tag storage unit that matches the first message identifier, then the first descriptor of the target request stored in the published receive queue PRQ is obtained based on the bitmap information;
[0010] The target message is stored based on the first descriptor and the first message identifier.
[0011] In one embodiment, the tag storage unit includes a public tag storage unit and a queued tag storage unit. The process of matching the first message identifier with the second message identifier in the tag storage unit to obtain a first matching result includes:
[0012] Match the first message identifier with the second message identifier in the public tag storage unit and the queue tag storage unit;
[0013] If a second message identifier that matches the first message identifier exists in the public tag storage unit or the queue tag storage unit, then the first matching result is determined to be that a second message identifier that matches the first message identifier exists in the tag storage unit;
[0014] If neither the public tag storage unit nor the queue tag storage unit contains a second message identifier that matches the first message identifier, then the first matching result is determined to be that there is no second message identifier that matches the first message identifier in the tag storage unit.
[0015] In one embodiment, the matching of the first message identifier with the second message identifier in the public tag storage unit and the queue tag storage unit includes:
[0016] Match the first message identifier with the second message identifier in the public tag storage unit;
[0017] If there is no second message identifier in the public tag storage unit that matches the first message identifier, then the first message identifier is matched with the second message identifier in the queue tag storage unit;
[0018] If there is no second message identifier in the queue tag storage unit that matches the first message identifier, then the first matching result is determined to be that there is no second message identifier in the tag storage unit that matches the first message identifier.
[0019] In one embodiment, the method further includes:
[0020] The first doorbell is received. The first doorbell is triggered after the driver software sends a receive descriptor to the published receive queue PRQ. The first doorbell carries the requested second descriptor, which includes the third message identifier.
[0021] If there is a free space in the public tag storage unit, the first doorbell is stored in the public tag storage unit.
[0022] In one embodiment, after storing the first doorbell in the queue tag storage unit, the method further includes:
[0023] Based on the position index of the second descriptor, update the bitmap information at the corresponding position in the published receive queue to the first value.
[0024] In one embodiment, storing the target message based on the first descriptor and the first message identifier includes:
[0025] If the first descriptor and the first message identifier match, the target message is stored at the address corresponding to the first descriptor;
[0026] If the first descriptor and the first message identifier do not match, the target message is stored in the Unexpected Message Queue (UMQ) according to the header and data portions of the target message.
[0027] In one embodiment, after storing the target message at the address corresponding to the first descriptor, the method further includes:
[0028] Update the bitmap information at the corresponding position in the published receive queue PRQ to the second value.
[0029] In one embodiment, the method further includes:
[0030] Upon receiving the first doorbell, determine whether there are any unexpected messages in the unexpected message queue;
[0031] If an unexpected message exists in the unexpected message queue, query the common tag storage unit based on the fourth message identifier of the unexpected message;
[0032] If the second message identifier corresponding to the fourth message identifier does not exist in the public tag storage unit, then the third message identifier in the first doorbell is obtained;
[0033] If the third message identifier and the fourth message identifier of the unexpected message are matched successfully, the corresponding unexpected message will be stored according to the second descriptor in the first doorbell.
[0034] In one embodiment, after receiving the target message sent by the upstream node, the method further includes:
[0035] Use bitmap information as old bitmap information;
[0036] At the current moment, obtain the new bitmap information of the published receive queue PRQ, and perform an XOR operation between the new bitmap information and the old bitmap information;
[0037] If the result of the XOR operation indicates that the old bitmap information and the new bitmap information are consistent, the new doorbell will be discarded.
[0038] If the result of the XOR operation indicates that the old bitmap information and the new bitmap information are inconsistent, the first descriptor of the target request already stored in the published receive queue is returned based on the new bitmap information.
[0039] Secondly, this application also provides a message matching device, comprising:
[0040] The receiving module is used to receive target messages sent by upstream nodes; the target message includes a queue identifier and a first message identifier.
[0041] The matching module is used to match the first message identifier with the second message identifier in the tag storage unit to obtain the first matching result; the second message identifier is the identifier of multiple requests in the published receive queue PRQ corresponding to the queue identifier;
[0042] The acquisition module is used to acquire the first descriptor of the target request stored in the published receive queue based on bitmap information if the first matching result is that there is no second message identifier in the tag storage unit that matches the first message identifier.
[0043] The storage module is used to store the target message based on the first descriptor and the first message identifier.
[0044] The aforementioned message matching method and device, upon receiving a target message, first match it in the tag storage unit, then screen it based on bitmap information and descriptors. This compresses the operation that originally required traversing the entire PRQ linked list into querying the target message's message identifier in the tag storage unit and filtering it using the Bitmap information. This significantly shortens the pre-write latency of the message to memory, greatly improving message matching efficiency and thus increasing message processing efficiency. Simultaneously, the bitmap information only manages descriptors corresponding to published requests, avoiding invalid memory reads and write amplification, reducing PCIe bandwidth usage and CPU cache pollution. Furthermore, since both the tag storage unit and bitmap information are pre-filled by the hardware doorbell, software does not need to intervene in the data plane, achieving line-speed reception and zero-copy to memory, balancing high throughput and low latency. It also naturally supports multi-stream concurrency within the same queue, significantly improving the overall efficiency and scalability of the storage network. Attached Figure Description
[0045] 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.
[0046] Figure 1This is a diagram illustrating the application environment of the message matching method in one embodiment;
[0047] Figure 2 This is a flowchart illustrating a message matching method in one embodiment;
[0048] Figure 3 This is a flowchart illustrating the message matching method in another embodiment;
[0049] Figure 4 This is a flowchart illustrating the message matching method in another embodiment;
[0050] Figure 5 This is a flowchart illustrating the message matching method in another embodiment;
[0051] Figure 6 This is a flowchart illustrating the message matching method in another embodiment;
[0052] Figure 7 This is a flowchart illustrating the message matching method in another embodiment;
[0053] Figure 8 This is a flowchart illustrating the message matching method in another embodiment;
[0054] Figure 9 This is a flowchart illustrating the message matching method in another embodiment;
[0055] Figure 10 This is a flowchart illustrating the message matching method in another embodiment;
[0056] Figure 11 This is a schematic diagram of the expected message processing flow in one embodiment;
[0057] Figure 12 This is a schematic diagram of the processing flow for unexpected messages in one embodiment;
[0058] Figure 13 This is a structural block diagram of a message matching device in one embodiment. Detailed Implementation
[0059] 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.
[0060] In distributed computing, Message Passing Interfaces (MPIs) provide applications with a simple and powerful way to manage the exchange of information between processes. A fundamental challenge of these interfaces is ensuring that a message sent by a process is correctly received by the intended receiver; this goal is achieved through a message matching process.
[0061] Message matching involves pairing received messages with corresponding receive requests. Typically, the message matching process involves two queues: the Post Receive Queue (PRQ) and the Unexpected Message Queue (UMQ). The PRQ stores requests that have not yet arrived to receive messages, while the UMQ stores messages that have been received but not yet requested. Both the PRQ and UMQ are implemented as linked lists.
[0062] Currently, message matching primarily involves traversing the PRQ or UMQ linked list to match requests with messages when new messages arrive or new receive requests are published. However, traditional message matching methods suffer from low matching efficiency. This application provides a message matching method aimed at solving the aforementioned problems.
[0063] The message matching method provided in this application embodiment can be applied to, for example... Figure 1 The network interface card (NIC) chip shown includes: a receive processing module, a queue tag storage unit, a hardware doorbell module, a public tag storage unit, and an unexpected message management module. The NIC chip is also connected to the main memory of the computer device. The main memory includes: bitmap information corresponding to the published receive queue (PRQ), the published receive queue (PRQ), and the unexpected message queue (UMQ).
[0064] The receiving and processing module receives and processes messages sent by upstream nodes. It also has the capability to construct an internal hardware notification doorbell and send it to the hardware doorbell module, as well as to the unexpected message queue (UMQ), when matching fails in the common tag storage unit, the queue tag storage unit, and the PRQ queue. The hardware doorbell module receives doorbells from the driver software and sequentially distributes them to the common tag storage unit, which stores the doorbells currently distributed by the hardware doorbell module. The queue tag storage unit stores all doorbells previously distributed by the hardware doorbell module. Additionally, the hardware doorbell module modifies the bitmap information corresponding to the PRQ based on the information carried in the doorbell. The unexpected message management module manages the unexpected message queue (UMQ). The bitmap information corresponding to the published receive queues (PRQ) in main memory is used to manage the published receive queues (PRQ).
[0065] In one exemplary embodiment, such as Figure 2 As shown, a message matching method is provided, which is applied to... Figure 1 Taking the network card chip in the example, the explanation includes:
[0066] S201. Receive the target message sent by the upstream node; the target message includes the queue identifier and the first message identifier.
[0067] The queue identifier is a marker carried by the target packet that indicates which queue the target packet should be processed in. It should be noted that modern network interface cards (NICs) typically support multiple receive queues to enable multi-core parallel processing, and the queue identifier determines which processing path the packet should enter.
[0068] The first message identifier refers to the unique identifier information carried by the target message. The first message identifier can be tag information.
[0069] In this embodiment, when the network interface card (NIC) chip performs message matching, there may be two scenarios. One is that the driver software first sends a request to the published receive queue, which carries the message identifier of the message to be received. Then, the message is received, and the message identifier of the message is matched with the message identifier of the message to be received carried in the request to achieve message matching. The other is that the message is received first, and then the driver software sends a request to the published receive queue, which carries the message identifier of the message to be received. The message identifier of the message is matched with the message identifier of the message to be received carried in the request to achieve message matching.
[0070] S202. Match the first message identifier with the second message identifier in the tag storage unit to obtain the first matching result; the second message identifier is the identifier of multiple requests in the published receive queue PRQ corresponding to the queue identifier.
[0071] The tag storage unit stores the doorbell corresponding to the request sent by the driver software to the published receive queue. The doorbell carries a descriptor of the request, which includes the message identifier of the message to be received.
[0072] In this embodiment, after receiving the target message sent by the upstream node, the first message identifier carried in the target message can be matched with the second message identifier stored in the tag storage unit to obtain a first matching result: either there is a second message identifier in the tag storage unit that matches the first message identifier, or there is no first matching result in the tag storage unit that matches the first message identifier. It should be noted that if a first matching result is obtained where a second message identifier matches the first message identifier in the tag storage unit, the target message is directly stored at the address described by the descriptor corresponding to the second message identifier to achieve message matching; if no first matching result is obtained where a second message identifier matches the first message identifier in the tag storage unit, then the following step S203 is executed.
[0073] S203. If the first matching result is that there is no second message identifier in the tag storage unit that matches the first message identifier, then the first descriptor of the target request stored in the published receive queue PRQ is obtained based on the bitmap information.
[0074] Bitmap information refers to the bitmap information corresponding to the published receive queue (PRQ) stored in the main memory of the computer device. For example, if the published receive queue (PRQ) has three storage locations: position 1, position 2, and position 3, and the bitmap of position 1 is 0, the bitmap of position 2 is 1, and the bitmap of position 3 is 0, then the request stored at position 2 of the PRQ is waiting for a matching message. Querying the bitmap information can determine which request in the PRQ is waiting for a message. Furthermore, after determining the request waiting for a message in the PRQ based on the bitmap information, the descriptor of the request corresponding to the position where the bitmap of the bitmap information is 1 can be obtained. Optionally, the descriptor of the request stored in the PRQ includes information such as the descriptor of the message the request is waiting for and the final storage address of the message being waited for.
[0075] It should be noted that the total depth of the PRQ is the same as the total number of bitmap information, meaning that the number of storage spaces in the PRQ corresponds one-to-one with the total number of bitmap information. The published receive queue (PRQ) stores at least one request for a received message that has not yet arrived, and each request carries a descriptor for the message to be received.
[0076] In this embodiment, if the first matching result is that there is no second message identifier in the tag storage unit that matches the first message identifier, then the bitmap information corresponding to the published receive queue PRQ is obtained from the main memory, and the first descriptor of the target request stored in the published receive queue PRQ is obtained based on the bitmap information.
[0077] S204. Store the target message based on the first descriptor and the first message identifier.
[0078] In this embodiment, after obtaining the first message identifier and the first descriptor, the first message identifier and the message identifier in the first descriptor can be matched. If the first message identifier and the message identifier in the first descriptor match successfully, the target message is stored in the storage address in the first descriptor. If the first message identifier and the message identifier in the first descriptor do not match successfully, it means that the descriptor of the receiving queue corresponding to the target message has not yet arrived. At this time, the target message can be discarded or sent to the unexpected message queue UMQ for temporary storage.
[0079] In this embodiment, after receiving the target message, matching is first performed in the tag storage unit, followed by screening of bitmap information and descriptors. This compresses the operation that originally required traversing the entire PRQ linked list into a linear process. The message identifier of the target message is queried in the tag storage unit, and the bitmap information is filtered based on the Bitmap. This significantly shortens the pre-write latency of the message to memory, greatly improves message matching efficiency, and thus improves message processing efficiency. At the same time, the bitmap information only manages the descriptors corresponding to published requests, avoiding invalid memory reads and write amplification, reducing PCIe bandwidth usage and CPU cache pollution. In addition, since the tag storage unit and bitmap information are pre-filled by the hardware doorbell, the software does not need to intervene in the data plane, achieving line-speed reception and zero copy to memory, balancing high throughput and low latency, and naturally supporting multi-stream concurrency in the same queue, significantly improving the overall efficiency and scalability of the storage network.
[0080] In this embodiment, in the above Figure 2 Based on the illustrated embodiment, the tag storage unit includes a common tag storage unit and a queued tag storage unit. The detailed process of matching the first message identifier with the second message identifier in the tag storage unit will be explained. In an exemplary embodiment, such as... Figure 3 As shown, the above S202 includes:
[0081] S301. Match the first message identifier with the second message identifier in the public tag storage unit and the queue tag storage unit.
[0082] The public tag storage unit stores doorbells triggered after the driver software submits a request to the published receive queue (PRQ). Each doorbell carries a descriptor corresponding to the submission request, including a message identifier for the message the submission request is waiting for. It should be noted that multiple PRQs share the public tag storage unit. The public tag storage unit prioritizes doorbells that arrive first, allowing them to occupy empty slots. Later doorbells are discarded or stored in the queue tag storage unit if the public tag storage unit does not have a controller. Furthermore, doorbells that have not been accessed for a long time are discarded based on their access time in the public tag storage unit.
[0083] The queue tag storage unit stores the remnants read from the PRQ queue during the previous round of packet matching. If the current packet and the previous packet belong to the same PRQ queue, fast matching can be performed using the queue tag storage unit.
[0084] In this embodiment, after obtaining the first message identifier, the first message identifier can be matched with the second message identifier in the public tag storage unit and the queue tag storage unit.
[0085] Optionally, the first message identifier can be matched with the second message identifier in the public tag storage unit first, and then the first message identifier can be matched with the second message identifier in the queue tag storage unit; alternatively, the first message identifier can be matched with the second message identifier in the queue tag storage unit first, and then the first message identifier can be matched with the second message identifier in the public tag storage queue.
[0086] Optionally, a detailed process for matching the first message identifier with the second message identifier in the public tag storage unit and the queue tag storage unit is provided below; see [link to documentation]. Figure 4 The aforementioned S301 includes:
[0087] S3011. Match the first message identifier with the second message identifier in the public tag storage unit.
[0088] In this embodiment, after obtaining the first message identifier, the first message identifier can be matched with the second message identifier in the public tag storage unit.
[0089] S3012. If there is no second message identifier in the public tag storage unit that matches the first message identifier, then the first message identifier is matched with the second message identifier in the queue tag storage unit.
[0090] In this embodiment, if there is no second message identifier in the public tag storage unit that matches the first message identifier, then the first message identifier is further matched with the second message identifier in the queue tag storage unit; if there is a second message identifier in the public tag storage unit that matches the first message identifier, then the target message is stored at the address described by the descriptor corresponding to the second message identifier.
[0091] S3013. If there is no second message identifier in the queue tag storage unit that matches the first message identifier.
[0092] In this embodiment, if there is no second message identifier matching the first message identifier in the queue tag storage unit, then the following S302 is further executed; if there is a second message identifier matching the first message identifier in the queue tag storage unit, then the target message is stored at the address described by the descriptor corresponding to the second message identifier.
[0093] S302. If a second message identifier that matches the first message identifier exists in the public tag storage unit or the queue tag storage unit, then the first matching result is determined to be that a second message identifier that matches the first message identifier exists in the tag storage unit.
[0094] In this embodiment, if a second message identifier that matches the first message identifier exists in the public tag storage unit or the queue tag storage unit, then the first matching result is determined to be that a second message identifier that matches the first message identifier exists in the tag storage unit.
[0095] S303. If neither the public tag storage unit nor the queue tag storage unit contains a second message identifier that matches the first message identifier, then the first matching result is determined to be that there is no second message identifier that matches the first message identifier in the tag storage unit.
[0096] In this embodiment, if neither the public tag storage unit nor the queue tag storage unit contains a second message identifier that matches the first message identifier, then the first matching result is determined to be that there is no second message identifier that matches the first message identifier in the tag storage unit.
[0097] In this embodiment, matching is first performed from the public tag storage unit based on the first message identifier, and then matching is performed from the queue tag storage unit based on the first message identifier. This avoids having to traverse the PRQ based on the first message identifier every time, reducing the average matching latency from microseconds to nanoseconds. At the same time, the first message identifier is matched to search through two levels of tag storage units in a hardware pipeline, which does not block subsequent message reception. This saves on-chip storage area, ensures line-speed processing, and significantly improves the throughput and energy efficiency of the storage network.
[0098] In this embodiment, in the above Figure 3 Based on the embodiments shown, Figure 5 As shown, the above method also includes:
[0099] S401, Receive the first doorbell; the first doorbell is triggered after the driver software sends a request to the published receive queue PRQ. The first doorbell carries the second descriptor of the request, and the second descriptor includes the third message identifier.
[0100] In this embodiment, the moment of receiving the first doorbell can be either before or after receiving the target message sent by the upstream node.
[0101] Optionally, the driver software can send a request to the published receive queue (PRQ) and then send a first doorbell to the hardware doorbell module after sending the request; the first doorbell carries a second descriptor of the request, which includes a third message identifier.
[0102] S402. If there is a free space in the public tag storage unit, store the first doorbell in the public tag storage unit.
[0103] In this embodiment, when the hardware doorbell module receives the first doorbell, it can further determine whether there is a free position in the public tag storage unit. If there is a free position in the public tag storage unit, the first doorbell is dequeued and written into the public tag storage unit for subsequent fast matching.
[0104] In this embodiment, when the first doorbell is received, it is stored in either the public tag storage unit or the queue tag storage unit according to the idle level of the public tag storage unit. This ensures that the most popular tags are hit immediately, while less popular doorbells can be hit in the queue tag storage unit. Compared to directly searching for the corresponding doorbell from main memory, the query efficiency is still an order of magnitude faster than main memory. In addition, the doorbell writing and bitmap information update are processed in parallel, saving the time of secondary access.
[0105] In this embodiment, in the above Figure 5 Based on the embodiment shown, after storing the first doorbell in the queue tag storage unit, see [link to example]. Figure 6 The above methods also include:
[0106] S403. Based on the position index of the second descriptor, update the bitmap information at the corresponding position in the published receive queue to the first value.
[0107] The second descriptor also includes a queue identifier and a position index, so as to find the PRQ of the bitmap information to be updated according to the queue identifier in the second descriptor, and after finding the PRQ of the bitmap information to be updated, find the corresponding position in the PRQ of the bitmap information to be updated according to the position index, and modify the bitmap at the corresponding position to the value 1.
[0108] In this embodiment, after storing the first doorbell in the public tag storage unit and the queue tag storage unit, the PRQ of the bitmap information to be updated can be found according to the queue identifier in the first doorbell. After finding the PRQ of the bitmap information to be updated, the corresponding position is found in the PRQ of the bitmap information to be updated according to the position index in the first doorbell, and the bitmap information at the corresponding position is modified to the value 1. For example, if the bitmap information of the PRQ before the update is (0,0,0,0) and the bitmap information of the PRQ after the update is (0,0,1,0), then it means that the request at the third position of the PRQ is a request that is waiting for a message.
[0109] In this embodiment, the position index of the descriptor itself is used as the bitmap offset. The hardware does not need to calculate or search again. The bitmap information at the corresponding position can be set to 1 in one step, saving the extra read, modify and write process. This ensures that the PRQ state and the content of the tag storage unit are strictly synchronized. When matching subsequent messages, they can be directly filtered according to the bitmap information, reducing invalid main memory access. Overall, the software-visible delivery delay is reduced to the nanosecond level, while improving the determinism and energy efficiency under multi-queue concurrency.
[0110] In this embodiment, in the above Figure 2 Based on the illustrated embodiment, the process of storing the target packet based on the first descriptor and the first packet identifier will be described in detail below. See [link to documentation]. Figure 7 The aforementioned S204 includes:
[0111] S501. If the first descriptor and the first message identifier match, the target message is stored at the address corresponding to the first descriptor.
[0112] In this embodiment, if the message identifier in the first descriptor matches the first message identifier, the target message is stored at the address corresponding to the address information in the first descriptor.
[0113] Optionally, if the message identifier in the first descriptor matches the first message identifier, the data portion of the target message is stored in the memory specified by the address information in the first descriptor, and the hardware doorbell module is notified of the successful match.
[0114] S502, If the first descriptor and the first message identifier do not match, store the target message in the unexpected message queue UMQ according to the header and data parts of the target message.
[0115] The Unexpected Message Queue (UMQ) includes a header storage list and a data storage list, with a one-to-one correspondence between the storage locations in the header storage list and the storage locations in the data storage list.
[0116] In this embodiment, if the message identifier in the first descriptor and the first message identifier do not match, the target message can be parsed to obtain the header and data portions of the target message. The idle position of the UMQ is determined based on the bitmap information of the UMQ. The header portion of the target message is stored in the header storage linked list at the position corresponding to the bitmap information, and the data portion of the target message is stored in the data storage linked list at the position corresponding to the header portion.
[0117] In this embodiment, when the first descriptor and the first message identifier match, the data is directly written to the host memory with zero copy. When the first descriptor and the first message identifier do not match, the data is automatically transferred to the UMQ, only the necessary header and data are moved, avoiding packet loss and retransmission, and not blocking subsequent message reception. This ensures that the expected message is delivered at line speed, while also providing a place to temporarily store unexpected messages, significantly improving the throughput and reliability of the storage network in high-concurrency and out-of-order scenarios. In addition, using TCAM to match the TAG between the on-chip common tag storage unit and the queue tag storage unit can achieve fast matching.
[0118] In this embodiment, in the above Figure 7 Based on the illustrated embodiment, after storing the target message at the address corresponding to the first descriptor, see [link to example]. Figure 8 The above methods also include:
[0119] S503. Update the bitmap information at the corresponding position in the published receive queue PRQ to the second value.
[0120] In this embodiment, after storing the target message at the address corresponding to the first descriptor, the bitmap information at the corresponding position in the published receive queue PRQ can be updated to the value 0, indicating that the corresponding position has been used. At this time, the hardware doorbell module can notify the driver software that the matching is complete, and the driver software can re-deliver the request to the position.
[0121] In this embodiment, after storing the target packet at the address corresponding to the first descriptor, the corresponding bitmap is immediately cleared, realizing the operation of receiving and recycling packets. The hardware can release the resource slot of the PRQ without software intervention, thus preventing duplicate matching.
[0122] In this embodiment, in the above Figure 7 Based on the embodiment shown, after receiving the first doorbell, see Figure 9 The above methods also include:
[0123] S601. Upon receiving the first doorbell, determine whether there are any unexpected messages in the unexpected message queue.
[0124] The unexpected message queue has a corresponding bitmap information, which stores the idle status of each resource slot in the unexpected message queue. For example, if the unexpected message queue has three slots, the bitmap information of the first slot is 0, the bitmap information of the second slot is 1, and the bitmap information of the third slot is 0, then it means that there is an unexpected queue in the second slot of the unexpected message queue.
[0125] In this embodiment, upon receiving the first doorbell, it is possible to determine whether there is an unexpected message in the unexpected message queue based on the bitmap information of the unexpected message queue, and if there is an unexpected message in the unexpected message queue, to deliver a doorbell carrying the location information of the unexpected message in the unexpected message queue to the unexpected message management module.
[0126] S602. If there is an unexpected message in the unexpected message queue, query the common tag storage unit according to the fourth message identifier of the unexpected message.
[0127] In this embodiment, if there is an unexpected message in the unexpected message queue, the public tag storage unit is queried according to the fourth message identifier of the unexpected message to determine whether there is a message identifier in the public tag storage unit that matches the fourth message identifier of the unexpected message.
[0128] S603. If there is no second message identifier corresponding to the fourth message identifier in the public tag storage unit, then obtain the third message identifier from the first doorbell.
[0129] In this embodiment, if there is no second message identifier corresponding to the fourth message identifier in the public tag storage unit, then the third message identifier in the first doorbell is obtained.
[0130] S604. If the third message identifier and the fourth message identifier of the unexpected message are matched successfully, the corresponding unexpected message is stored according to the second descriptor in the first doorbell.
[0131] In this embodiment, all fourth message identifiers in the unexpected message can be read, and the third message identifier can be matched with each of the fourth message identifiers respectively. If the third message identifier matches any of the fourth message identifiers in the unexpected message, the corresponding unexpected message is stored according to the second descriptor in the first doorbell.
[0132] Optionally, if the third message identifier does not match any of the fourth message identifiers in the unexpected messages, the first doorbell is discarded.
[0133] Optionally, if the third message identifier matches any of the fourth message identifiers in the unexpected messages, then according to the message identifier recorded in the header storage linked list of the unexpected message queue, a fake message is constructed for the unexpected message corresponding to the fourth message identifier, and the fake message is passed to the receiving and processing module for processing. The receiving and processing module moves the data part in the unexpected message queue to the specified location. The process of moving the unexpected message to the specified location can be regarded as the local automatic re-reception of the unexpected message.
[0134] In this embodiment, once the doorbell is re-added by the software, the hardware first determines whether there are any unexpected messages stored in the UMQ. If there are unexpected messages, the message identifier in the doorbell is immediately compared with the message identifier of the unexpected message. If a match is found, the message is stored using a new descriptor without further software intervention or interruption, which significantly improves throughput and determinism in out-of-order or delayed request scenarios.
[0135] In this embodiment, in the above Figure 2 Based on the illustrated embodiments, see also Figure 10 After receiving the target message sent by the upstream node, the above method further includes:
[0136] S205. Use the bitmap information as the old bitmap information.
[0137] In this embodiment, during the process of receiving a target message and performing message identifier matching in the tag storage unit based on the message identifier of the target message, as well as performing message identifier matching based on bitmap information and request descriptor, a new doorbell may be received. This new doorbell may have two possibilities: either the bitmap information at the corresponding position in the published receive queue has not yet been updated, or the bitmap information at the corresponding position in the published receive queue has already been updated. To distinguish between these two possibilities, after receiving the target message, the receiving processing module can send a notification doorbell to the doorbell processing module. This notification doorbell carries the old bitmap information of the PRQ collected from the received target message.
[0138] S206. At the current moment, obtain the new bitmap information of the published receive queue PRQ, and perform an XOR operation between the new bitmap information and the old bitmap information.
[0139] In this embodiment, the doorbell processing module will notify the doorbell to deliver the message to the unexpected message management module. At the current moment, the unexpected message management module will obtain the new bitmap information of PRQ and perform an XOR operation between the new bitmap information and the old bitmap information.
[0140] S207. If the result of the XOR operation indicates that the old bitmap information and the new bitmap information are consistent, wait for the driver software to deliver the doorbell.
[0141] In this embodiment, if the result of the XOR operation indicates that the old bitmap information and the new bitmap information are consistent, it means that no new doorbell is delivered during the target message matching process. In this case, the doorbell will be notified to be discarded, and the system will continue to wait for the driver software to deliver the doorbell.
[0142] S208. If the result of the XOR operation indicates that the old bitmap information and the new bitmap information are inconsistent, return to the above S203 based on the new bitmap information.
[0143] In this embodiment, if the result of the XOR operation indicates that the old bitmap information and the new bitmap information are inconsistent, it means that the driver software has delivered a new doorbell, and the process can return to the above step of obtaining the first descriptor of the target request stored in the published receive queue PRQ based on the bitmap information.
[0144] In this embodiment, when a new doorbell is received, the old bitmap is first snapshotted, then the current bitmap is read and XORed. If the result is zero, it means that there is no new request during the replenishment period, and it is directly discarded to avoid idle time; if it is non-zero, it means that the software has added a valid descriptor, and the address of the target packet is immediately looked up using the new bitmap, ensuring that any real replenishment can be processed in time, which significantly improves the link utilization and energy efficiency ratio in out-of-order scenarios.
[0145] In one embodiment, the specific implementation process for two message matching methods is also provided below, see [link to implementation details]. Figure 11 It provides a predictable message processing flow, including:
[0146] Step 1: After the driver software sends a request to the published receive queue PRQ, it sends the first doorbell to the hardware doorbell module; the first doorbell carries the second descriptor of the request, and the second descriptor includes the third message identifier;
[0147] Step 2: After the hardware doorbell module dequeues the first doorbell, it writes it into the common tag storage unit for subsequent fast matching. It should be noted that multiple PRQ queues share the common tag storage unit. The common tag storage unit prioritizes the doorbells that enter first to occupy empty positions. If the common tag storage unit does not have a controller, the doorbells that enter later are either discarded or stored in the queue tag storage unit. In addition, doorbells that have not been accessed for a long time are eliminated based on the access time of each doorbell in the common tag storage unit.
[0148] Step 3: The hardware doorbell module updates the bitmap information at the corresponding position in the published receive queue to the first value according to the position index of the descriptor in the first doorbell. It should be noted that the total depth of the PRQ is the same as the total number of bitmap information, that is, the number of storage spaces of the PRQ corresponds one-to-one with the total number of bitmap information.
[0149] Step 4: The receiving and processing module receives the target message;
[0150] Step 5: The receiving and processing module queries the common tag storage unit based on the first packet identifier of the target packet to see if there is a match for the first packet identifier in the most recently issued descriptors. If there is no descriptor corresponding to the first packet identifier in the common tag storage unit, the receiving and processing module continues to query the queue tag storage unit to see if there is a descriptor corresponding to the first packet identifier. This queue tag storage unit contains all the descriptors read from a certain queue in the previous round. If the target packet belongs to this queue, it may be matched.
[0151] Step 6: If no match is found, read the bitmap information of the queue and obtain the first descriptor of the target request stored in the published receive queue PRQ based on the bitmap information. Store the bitmap information and the first descriptor in the queue tag storage unit. Store the target message based on the first descriptor and the first message identifier.
[0152] Step 7: Since it is an expected message, steps 5 and 6 can eventually match the descriptor issued by the driver software. Write the data part of the target message into the memory specified by the descriptor and notify the hardware doorbell module of the result that the descriptor has been matched.
[0153] Step 8: The hardware doorbell module updates the corresponding bitmap information of the queue to 0, indicating that this message identifier has been used. The hardware notifies the software that the matching is complete, and the software can re-deliver the message identifier to this position.
[0154] In one embodiment, the specific implementation process for two message matching methods is also provided below, see [link to implementation details]. Figure 12 It provides an unexpected message handling process, including:
[0155] Step 1: The receiving and processing module receives the target message;
[0156] Step 2: The receiving and processing module queries the common tag storage unit based on the first packet identifier of the target packet to see if there is a match for the first packet identifier in the most recently issued descriptors. If there is no descriptor corresponding to the first packet identifier in the common tag storage unit, the receiving and processing module continues to query the queue tag storage unit to see if there is a descriptor corresponding to the first packet identifier. This queue tag storage unit contains all the descriptors read from a certain queue in the previous round. If the target packet belongs to this queue, it may be matched.
[0157] Step 3: If no match is found, read the bitmap information of the queue and obtain the first descriptor of the target request stored in the published receive queue PRQ based on the bitmap information. Store the bitmap information and the first descriptor in the queue tag storage unit. Store the target message based on the first descriptor and the first message identifier.
[0158] Step 4: Enter the unexpected message handling process. Each queue context sets the physical page address of the UMQ header and the physical page address of the UMQ data, as well as the bitmap information of the UMQ recorded by the hardware. Based on the UMQ bitmap information, select the unused position of the current UMQ, store the message header in the physical page address of the corresponding header of the UMQ, and calculate the offset address of the message data and store it in the physical page address of the corresponding data of the UMQ.
[0159] Step 5: Here, considering the possibility that the software doorbell may have been delivered, but the bitmap information of PRQ has not been updated when it was read in Step 3 above, the receiving and processing module generates a UMQ doorbell notification to the hardware doorbell module. This UMQ doorbell contains the old bitmap information read in Step 3.
[0160] Step 6: The hardware doorbell module delivers the UMQ doorbell message to the unexpected message management module;
[0161] Step 7: The unexpected message management module reads the bitmap information of the latest PRQ, performs a bitwise XOR operation between the old bitmap information and the new bitmap information. If the result is 0, the doorbell is discarded and the software is waiting to deliver the doorbell; if the result is not 0, it means that the software has already delivered a new doorbell.
[0162] Step 8: After the driver software sends a request to the published receive queue PRQ, it sends the first doorbell to the hardware doorbell module; the first doorbell carries the second descriptor of the request, and the second descriptor includes the third message identifier;
[0163] Step 9: After the hardware doorbell module dequeues the first doorbell, it writes it into the common tag storage unit for subsequent fast matching. It should be noted that multiple PRQ queues share the common tag storage unit. The common tag storage unit follows the principle that the doorbell that enters first occupies the empty position first. If the common tag storage unit does not have a controller, the doorbell that enters later is discarded or stored in the queue tag storage unit. In addition, based on the access time of each doorbell in the common tag storage unit, doorbells that have not been accessed for a long time are eliminated.
[0164] Step 10: The hardware doorbell module updates the bitmap information at the corresponding position in the published receive queue to the first value according to the position index of the descriptor in the first doorbell. It should be noted that the total depth of the PRQ is the same as the total number of bitmap information, that is, the number of storage spaces of the PRQ corresponds one-to-one with the total number of bitmap information.
[0165] Step 11: Determine whether there are any unexpected message messages stored in the UMQ based on the bitmap information of the UMQ in the queue context. If there are already unexpected messages, the bitmap information of the UMQ will not be 0, and the TRQ doorbell will be delivered to the unexpected message processing module.
[0166] Step 12: The unexpected message processing module checks whether the message identifier in the doorbell matches the public tag storage unit.
[0167] Step 13: If no match is found, read the request descriptor stored in the PRQ of the doorbell;
[0168] Step 14: Read the message identifier of the valid header part in UMQ, and match the message identifier carried in the doorbell with the message identifier of UMQ respectively. If no match is found, discard the doorbell; if a match is found, proceed to step 15.
[0169] Step 15: Based on the message information recorded in the header of the UMQ, construct fake messages for the received unexpected messages in sequence and pass them to the message processing module for processing. The message processing module moves the data part in the UMQ to the matched specified position. The process of moving the unexpected messages to the specified position can be regarded as the local automatic re-reception of unexpected messages.
[0170] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.
[0171] Based on the same inventive concept, this application also provides a message matching apparatus for implementing the message matching 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 message matching apparatus embodiments provided below can be found in the limitations of the message matching method described above, and will not be repeated here.
[0172] In one exemplary embodiment, such as Figure 13 As shown, a message matching device is provided, including: a receiving module 10, a matching module 11, an acquisition module 12, and a storage module 13, wherein:
[0173] The receiving module 10 is used to receive the target message sent by the upstream node; the target message includes a queue identifier and a first message identifier.
[0174] The matching module 11 is used to match the first message identifier with the second message identifier in the tag storage unit to obtain the first matching result; the second message identifier is the identifier of multiple requests in the published receive queue PRQ corresponding to the queue identifier.
[0175] The acquisition module 12 is used to acquire the first descriptor of the target request stored in the published receive queue PRQ based on bitmap information if the first matching result is that there is no second message identifier in the tag storage unit that matches the first message identifier.
[0176] Storage module 13 is used to store the target message based on the first descriptor and the first message identifier.
[0177] In an exemplary embodiment, the tag storage unit includes a public tag storage unit and a queued tag storage unit, and the matching module 11 includes:
[0178] The matching unit is specifically used to match the first message identifier with the second message identifier in the public tag storage unit and the queue tag storage unit;
[0179] The first determining unit is specifically used to determine that if there is a second message identifier in the tag storage unit that matches the first message identifier in the public tag storage unit or the queue tag storage unit, the first matching result is that there is a second message identifier in the tag storage unit that matches the first message identifier.
[0180] The second determining unit is specifically used to determine the first matching result as follows: if there is no second message identifier matching the first message identifier in either the public tag storage unit or the queue tag storage unit, then the first matching result is that there is no second message identifier matching the first message identifier in the tag storage unit.
[0181] In an exemplary embodiment, the matching unit is further configured to match the first message identifier with the second message identifier in the public tag storage unit; if there is no second message identifier in the public tag storage unit that matches the first message identifier, then the first message identifier is matched with the second message identifier in the queue tag storage unit; if there is no second message identifier in the queue tag storage unit that matches the first message identifier, then the first matching result is determined to be that there is no second message identifier in the tag storage unit that matches the first message identifier.
[0182] In one exemplary embodiment, the above-described apparatus further includes:
[0183] The receiving module is used to receive the first doorbell. The first doorbell is triggered after the driver software sends a receiving descriptor to the published receiving queue PRQ. The first doorbell carries a requested second descriptor, which includes a third message identifier.
[0184] The first storage module is used to store the first doorbell in the public tag storage unit when there is a free space in the public tag storage unit.
[0185] In an exemplary embodiment, after storing the first doorbell in the queue tag storage unit, the device further includes:
[0186] The first update module is used to update the bitmap information at the corresponding position in the published receive queue to the first value based on the position index of the second descriptor.
[0187] In one exemplary embodiment, the storage module 13 includes:
[0188] The first storage unit is specifically used to store the target message at the address corresponding to the first descriptor when the first descriptor and the first message identifier match.
[0189] The second storage unit is specifically used to store the target message in the unexpected message queue (UMQ) according to the header and data portions of the target message when the first descriptor and the first message identifier do not match.
[0190] In an exemplary embodiment, after storing the target message at the address corresponding to the first descriptor, the apparatus further includes:
[0191] The second update module is used to update the bitmap information at the corresponding position in the published receive queue (PRQ) to the second value.
[0192] In one exemplary embodiment, the above-described apparatus further includes:
[0193] The determination module is used to determine whether there are any unexpected messages in the unexpected message queue when the first doorbell is received;
[0194] The query module is used to query the public tag storage unit according to the fourth message identifier of the unexpected message if there is an unexpected message in the unexpected message queue.
[0195] The acquisition module is used to acquire the third message identifier in the first doorbell if there is no second message identifier corresponding to the fourth message identifier in the public tag storage unit.
[0196] The storage module is used to store the corresponding unexpected message according to the second descriptor in the first doorbell if the third message identifier and the fourth message identifier of the unexpected message are successfully matched.
[0197] In an exemplary embodiment, after receiving the target message sent by the upstream node, the above-mentioned apparatus further includes:
[0198] The determination module is used to treat bitmap information as old bitmap information;
[0199] The operation module is used to obtain the new bitmap information of the published receive queue PRQ at the current moment, and perform an XOR operation between the new bitmap information and the old bitmap information;
[0200] The discard module is used to discard the new doorbell if the result of the XOR operation indicates that the old bitmap information and the new bitmap information are consistent.
[0201] The execution module is used to return the first descriptor of the target request stored in the published receive queue based on the new bitmap information when the result of the XOR operation indicates that the old bitmap information and the new bitmap information are inconsistent.
[0202] Each module in the aforementioned message matching 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 call and execute the operations corresponding to each module.
[0203] In one embodiment, a computer device is also 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 in the above method embodiments.
[0204] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.
[0205] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.
[0206] 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.
[0207] 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.
[0208] 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. A message matching method, characterized by, The method includes: Receive a target message sent by an upstream node; the target message includes a queue identifier and a first message identifier; The first message identifier is matched with the second message identifier in the tag storage unit to obtain a first matching result; the second message identifier is the identifier of multiple requests in the published receive queue PRQ corresponding to the queue identifier; If the first matching result is that there is no second message identifier in the tag storage unit that matches the first message identifier, then the first descriptor of the target request stored in the published receive queue PRQ is obtained based on the bitmap information; The target message is stored based on the first descriptor and the first message identifier.
2. The method of claim 1, wherein, The tag storage unit includes a public tag storage unit and a queued tag storage unit. The step of matching the first message identifier with the second message identifier in the tag storage unit to obtain a first matching result includes: The first message identifier is matched with the second message identifier in the public tag storage unit and the queue tag storage unit; If a second message identifier that matches the first message identifier exists in the public tag storage unit or the queue tag storage unit, then the first matching result is determined to be that a second message identifier that matches the first message identifier exists in the tag storage unit. If neither the public tag storage unit nor the queue tag storage unit contains a second message identifier that matches the first message identifier, then the first matching result is determined to be that there is no second message identifier that matches the first message identifier in the tag storage unit.
3. The method according to claim 2, characterized in that, The step of matching the first message identifier with the second message identifier in the public tag storage unit and the queue tag storage unit includes: Match the first message identifier with the second message identifier in the public tag storage unit; If there is no second message identifier in the public tag storage unit that matches the first message identifier, then the first message identifier is matched with the second message identifier in the queue tag storage unit; If there is no second message identifier in the queue tag storage unit that matches the first message identifier, then the first matching result is determined to be that there is no second message identifier in the tag storage unit that matches the first message identifier.
4. The method according to claim 2, characterized in that, The method further includes: The first doorbell is received. The first doorbell is triggered after the driver software sends a receive descriptor to the published receive queue PRQ. The first doorbell carries the second descriptor of the request, and the second descriptor includes a third message identifier. If there is a free space in the public tag storage unit, the first doorbell is stored in the public tag storage unit.
5. The method according to claim 4, characterized in that, After storing the first doorbell in the queue tag storage unit, the method further includes: Based on the position index of the second descriptor, update the bitmap information at the corresponding position in the published receive queue to the first value.
6. The method according to any one of claims 1-4, characterized in that, The step of storing the target message based on the first descriptor and the first message identifier includes: If the first descriptor and the first message identifier match, the target message is stored at the address corresponding to the first descriptor; If the first descriptor and the first message identifier do not match, the target message is stored in the Unexpected Message Queue (UMQ) according to the header and data portions of the target message.
7. The method according to claim 6, characterized in that, After storing the target message at the address corresponding to the first descriptor, the method further includes: Update the bitmap information at the corresponding position in the published receive queue PRQ to the second value.
8. The method according to claim 6, characterized in that, The method further includes: Upon receiving the first doorbell, determine whether there are any unexpected messages in the unexpected message queue; If there is an unexpected message in the unexpected message queue, the public tag storage unit is queried according to the fourth message identifier of the unexpected message; If the public tag storage unit does not contain a second message identifier corresponding to the fourth message identifier, then the third message identifier in the first doorbell is obtained; If the third message identifier and the fourth message identifier of the unexpected message match successfully, the corresponding unexpected message is stored according to the second descriptor in the first doorbell.
9. The method according to any one of claims 1-5, characterized in that, After receiving the target message sent by the upstream node, the method further includes: The bitmap information is used as old bitmap information; At the current moment, obtain the new bitmap information of the published receive queue PRQ, and perform an XOR operation between the new bitmap information and the old bitmap information; If the result of the XOR operation indicates that the old bitmap information and the new bitmap information are consistent, the new doorbell is discarded; If the result of the XOR operation indicates that the old bitmap information and the new bitmap information are inconsistent, the process returns to the execution of obtaining the first descriptor of the target request stored in the published receive queue based on the new bitmap information.
10. A message matching device, characterized in that, The device includes: The receiving module is used to receive target messages sent by upstream nodes; the target message includes a queue identifier and a first message identifier. The matching module is used to match the first message identifier with the second message identifier in the tag storage unit to obtain a first matching result; the second message identifier is the identifier of multiple requests in the published receive queue PRQ corresponding to the queue identifier; The acquisition module is used to acquire the first descriptor of the target request stored in the published receiving queue based on bitmap information if the first matching result is that there is no second message identifier in the tag storage unit that matches the first message identifier. The storage module is used to store the target message based on the first descriptor and the first message identifier.