An implementation method and system of MPI-based in-line tag matching

Abstract

This disclosure relates to the field of MPI communication technology, and discloses a method and system for implementing MPI-based in-path label matching. The method includes: sending a current MPI message to a receiver via a sender, the message carrying a predicted label; receiving and parsing the predicted label from the message at the receiver; and adding a request to receive subsequent MPI messages to an MPI expected message queue at the receiver based on the predicted label, before the arrival of subsequent MPI messages. This disclosure enables the receiver to proactively add a request to receive subsequent messages to the expected message queue by having the sender carry a predicted label in the current MPI message, thus enabling the receiver to anticipate and proactively add such requests to the expected message queue. This achieves a shift from passive reception to proactive prefetching, significantly reducing the generation of unexpected messages. It also avoids overflow interruptions and hardware / software synchronization overhead caused by the exhaustion of hardware resources in unexpected queues, significantly improving communication throughput.

Description

Technical Field

[0001] This disclosure relates to the field of Message Passing Interface (MPI) communication technology, specifically to an implementation method and system for MPI-based in-path tag matching. Background Technology

[0002] As the de facto standard communication library in the field of parallel computing, MPI's tag matching mechanism is the core technology for achieving efficient and reliable inter-process communication.

[0003] However, existing label matching methods primarily employ a passive waiting mechanism at the receiver, heavily relying on the timing of message delivery from the receive buffer. This leads to a significant increase in overhead and complexity in communication-intensive scenarios, as many messages become unexpected due to the receiver's inability to prepare, thus impacting communication efficiency. Therefore, a label matching method capable of proactively predicting message sequences and reducing the accumulation of unexpected messages is urgently needed. Summary of the Invention

[0004] In view of this, this disclosure provides an implementation method and system for MPI-based in-path label matching to solve problems such as how to actively predict message sequences and reduce the accumulation of unexpected messages, reduce overhead costs and complexity, and thus improve communication efficiency.

[0005] This disclosure provides an implementation method for road-in-the-loop label matching based on MPI, the method including: The sender sends the current MPI message to the receiver. The current MPI message carries the current label and the predicted label used to indicate subsequent MPI messages. The receiver receives the current MPI message and parses the predicted label from the current MPI message. By using predicted tags, the receiving end adds the receiving request for subsequent MPI messages to the MPI expected message queue before the arrival of subsequent MPI messages.

[0006] This disclosure also provides an implementation system for MPI-based in-path label matching, the system comprising: The sending end is used to send the current MPI message to the receiving end. The current MPI message carries the current label and the predicted label used to indicate subsequent MPI messages. The receiving end is used to receive the current MPI message and parse the predicted label from the current MPI message; The receiving end is also used to add the receiving request for the subsequent MPI message to the MPI expected message queue based on the predicted label before the subsequent MPI message arrives.

[0007] This disclosure also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described MPI-based in-way tag matching implementation methods.

[0008] This disclosure also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described methods for implementing MPI-based in-way tag matching.

[0009] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described methods for implementing MPI-based in-path label matching.

[0010] In the implementation method and system of MPI-based in-path label matching in the above embodiments of this disclosure, by having the sending end carry the predicted label in the current MPI message, the receiving end can detect in advance and actively add the receiving request for subsequent messages to the expected message queue; this realizes a mechanism shift from passive receiving to active prefetching, significantly reducing the generation of unexpected messages; thereby avoiding overflow interruptions and software / hardware synchronization overhead caused by the exhaustion of unexpected hardware queue resources, and significantly improving communication throughput. By utilizing the existing data transmission channel to transmit the predicted signaling in-path, there is no need to establish additional connections or send independent control messages; this achieves label prediction and synchronization with zero additional communication frequency overhead. Attached Figure Description

[0011] To more clearly illustrate the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart illustrating an implementation method for MPI-based in-path label matching provided in this embodiment of the present disclosure; Figure 2 A schematic diagram of the expected message queue and the unexpected message queue for an implementation method of MPI-based in-path label matching provided in this disclosure embodiment; Figure 3 A schematic diagram illustrating the expected matching scenario for an implementation method of MPI-based in-path label matching provided in this embodiment of the disclosure; Figure 4 A schematic diagram of the negotiation process for an implementation method of MPI-based in-path label matching provided in this embodiment of the disclosure; Figure 5A schematic diagram illustrating the process of the receiving end actively sending expected tag notifications in an implementation method of MPI-based in-path tag matching provided in this embodiment of the disclosure; Figure 6 A schematic diagram of the structure of an MPI-based in-path label matching implementation system provided in this embodiment of the disclosure; Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure. Detailed Implementation

[0013] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this disclosure.

[0014] As the scale of high-performance computing or artificial intelligence clusters continues to grow and expand, the requirements for communication efficiency in parallel computing tasks are becoming increasingly stringent. MPI, as the mainstream communication standard for distributed computing, directly determines the performance of large-scale inter-process data exchange through its tag matching mechanism.

[0015] In practical applications, MPI communication data streams often exhibit the following significant characteristics: 1. High concurrency and burstiness: In large-scale parallel tasks, tens of thousands of processes may initiate communication at the same time, resulting in a massive influx of concurrent messages in the network. The rate at which messages arrive at the receiving end often undergoes dynamic changes due to the imbalance of computing load. 2. Asynchronous out-of-order nature, that is, affected by network routing and node scheduling, the order in which messages sent by different source nodes arrive at the receiving end is highly uncertain, and the receiving end has difficulty predicting whether the next message to arrive has met the matching conditions. 3. Protocol differences: MPI can adopt different transmission strategies for different data volumes. For example, small messages use the Eager protocol to pursue low latency, while large messages use the Rendezvous protocol to pursue high bandwidth. This poses differentiated requirements for underlying resource scheduling.

[0016] The aforementioned communication characteristics pose a serious challenge to existing data storage and processing architectures: 1. Because the receiving end's request to receive often lags behind the arrival of the message, a large number of messages cannot be matched in time, thus becoming unexpected messages; under the Eager protocol, such messages can account for 5% to 15%, requiring additional temporary cache.

[0017] 2. For example, the modern high-performance network card Mellanox CX6, although it supports hardware offloading, has expensive on-chip storage resources and very low hardware depth for unintended message queues; for example, the Mellanox CX6 can only hold 127 records.

[0018] 3. When unexpected messages exceed the hardware's capacity, they must overflow into the host memory for processing, leading to frequent hardware and software interactions. This not only increases interrupt overhead but also causes severe performance jitter.

[0019] Therefore, the following solutions are often used in related technologies to handle tag matching: 1. Pure software matching architecture: This scheme relies entirely on the CPU to maintain expected and unexpected queues in main memory; all arriving messages are processed by the CPU, and the receiving end passively scans the queues for matching, resulting in severe contention for communication and computing resources.

[0020] 2. Hardware offloading architecture; This solution pushes the matching logic down to the network card; The network card hardware attempts to write the expected message directly to the user memory, and only reports the unmatched message to the driver or temporarily stores it in the on-chip cache.

[0021] However, the aforementioned technologies often have the following problems: 1. Whether it is a software or hardware solution, they all essentially adopt the "receiver passively waiting" mode; that is, the receiver cannot predict the sending sequence of the sender and can only passively search after the message arrives. This mechanism is the root cause of unexpected messages, which makes the communication efficiency limited by the timing of the release of the receiving request.

[0022] 2. Existing hardware offloading solutions lack flexibility in handling unexpected messages. Once the volume of messages suddenly exceeds the hardware queue threshold, subsequent message processing will fall back to the software slow path. This failure of the hardware fast path, resulting in context switching and memory copying, severely restricts the overall throughput.

[0023] 3. Under the Eager protocol, unexpected messages need to undergo a second copy through the "network card-temporary buffer-user buffer", which increases memory bandwidth consumption; under the Rendezvous protocol, unexpected control frames cause increased handshake latency, making it impossible for data transmission to effectively cover the handshake overhead, thus hindering the overlap between communication and computing.

[0024] To address the aforementioned issues, various embodiments of this disclosure provide an implementation method for MPI-based in-path label matching. The method includes: a sending end sending a current MPI message to a receiving end, the current MPI message carrying a current label and a predicted label for indicating subsequent MPI messages; the receiving end receiving the current MPI message and parsing the predicted label from the current MPI message; and the receiving end adding a receiving request for the predicted label to the MPI expected message queue before the arrival of subsequent MPI messages, based on the predicted label.

[0025] It should be noted that, in the description of this disclosure, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this disclosure are used to distinguish similar objects and are not used to describe a particular order or sequence.

[0026] To enable those skilled in the art to better understand the present disclosure, the present disclosure will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0027] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating an implementation method for MPI-based in-path tag matching provided in an embodiment of this disclosure. The method provided in this embodiment is applied to an MPI communication environment.

[0028] In this MPI communication environment, there may be at least one sender and at least one receiver; the sender and receiver may be different processes running on the same computing node, or they may be different processes running on different computing nodes interconnected by a network.

[0029] Here, the sender and receiver are located in the same MPI communication domain and can exchange data point-to-point through the MPI protocol; the sender can be the party that initiates the message sending operation at the current communication time, and the receiver can be the party that receives the matching message at the current communication time.

[0030] It should be noted that in actual parallel programs, a process may alternate between acting as the sender and receiver at different times.

[0031] Furthermore, in this MPI communication environment, MPI can maintain two message queues, including the Post Receive Queue (PRQ, hereinafter referred to as the expected message queue) and the Unexpected Message Queue (UMQ, hereinafter referred to as the unexpected message queue).

[0032] The expected message queue is used to store receiving requests that have been initiated by the receiving application but have not yet been completed. When the receiving end calls each receiving interface, the MPI library can generate a receiving request descriptor containing matching information such as expected tags and add it to the expected message queue to wait for matching.

[0033] Unexpected message queues can be used to temporarily store messages that have arrived at the receiving end but have not yet been found in the expected message queue to match a receiving request. That is, when a message arrives at the receiving end, if the receiving application has not yet called the corresponding receiving interface, the message will be regarded as an "unexpected message" and stored in the unexpected message queue until the receiving end subsequently issues a matching receiving request, at which point the message will be retrieved from the unexpected message queue for processing.

[0034] For example, please refer to Figure 2 , Figure 2 A schematic diagram of the expected and unexpected message queues for an implementation method of MPI-based in-path label matching provided in this disclosure embodiment, wherein, as... Figure 2 As shown, the sender on the left sends three messages to the receiver on the right: Msg_tag2, Msg_tag4, and Msg_tag1. The receiver on the right maintains an expected message queue and an unexpected message queue.

[0035] by Figure 2 Taking three messages as an example, the specific workflow is as follows: Scenario 1 (Expected Match): When Msg_tag2 carrying tag2 arrives at the receiving end, the MPI library traverses the expected message queue and finds a receive request for tag2 in the queue. At this time, the MPI library determines that the match is successful and directly writes the data payload of Msg_tag2 into the user buffer (i.e., Buf2) pointed to by the receive request, thus completing the data reception. Similarly, when Msg_tag1 carrying tag1 arrives at the receiving end, it is stored in the user buffer Buf1 corresponding to tag11.

[0036] Scenario 2 (Unexpected Buffer): When Msg_tag4 carrying tag4 arrives at the receiving end, the MPI library again traverses the expected message queue, but does not find a receive request for tag4 in the queue. At this time, the MPI library determines that the match has failed, regards Msg_tag4 as an unexpected message, and temporarily stores it in the unexpected message queue. This message will remain in the unexpected message queue until the receiving application initiates a receive request for tag4, at which point the MPI library will retrieve it and complete the final delivery.

[0037] The embodiments of this disclosure aim to solve the problem that the tag4 message is forced to enter the unexpected message queue in the above-described scenario two; through the following path prediction mechanism, this disclosure can add the corresponding receiving request to the expected message queue on the left in advance before the tag4 message arrives, thereby transforming it into the processing flow of scenario one.

[0038] Furthermore, such as Figure 1 As shown, the process of this method may include the following steps: Step S101: Send the current MPI message from the sending end to the receiving end.

[0039] In this embodiment, the current MPI message can refer to the data unit that the sender is currently performing a transmission operation at the current moment; the current MPI message carries a current tag and a prediction tag for indicating subsequent MPI messages.

[0040] Specifically, the current tag can be used to represent the current MPI message itself, so that the receiving end can match it in the current expected message queue to complete the current data transmission task.

[0041] Prediction tags can be identifiers that the sender predicts for messages to be sent in the future, based on its own sending logic or a pre-planned communication sequence. These prediction tags can be used to indicate the tag information of one or more MPI messages that the sender will send after sending the current MPI message.

[0042] By carrying a prediction tag along with the current message's data stream, the sender can inform the receiver of its future communication intentions in advance without establishing an additional out-of-band connection or sending a separate control message, thereby achieving the integration of communication signaling and data transmission.

[0043] Preferably, when constructing the current MPI message, the sender may encapsulate the prediction label in the message header, extended header, or a specific payload field and send it to the receiver.

[0044] Step S102: Receive the current MPI message through the receiving end and parse the predicted label from the current MPI message.

[0045] In this embodiment, after receiving the data packet sent by the sender through the underlying network protocol, the receiving end can first parse and process the current MPI message according to the pre-agreed communication protocol format or message structure definition.

[0046] Specifically, the parsing process may mainly include the extraction of message headers, extended headers, or specific payload location information; the receiving end not only needs to extract the current label used for the current matching task, but also needs to extract the predicted label carried along the way.

[0047] Here, the parsing process for these two tags can be performed synchronously or sequentially as needed.

[0048] As an alternative implementation, in order to be compatible with existing MPI standard protocols and minimize communication overhead, current MPI messages can reuse standard tag fields.

[0049] In this scenario, the receiver can use bitwise operations to separate the current label from the predicted label. For example, if the standard label field is logically divided into a high-order bit field and a low-order bit field, the receiver can use masking and shifting operations to extract the predicted label from the high-order bit field and the current label from the low-order bit field.

[0050] This method enables the in-path delivery of predicted label information without increasing the message length.

[0051] As another optional implementation, if the current MPI message uses an extended message format, that is, includes an extended field independent of the standard label field, the receiving end can directly locate the offset address of the extended field and read the value therein as the predicted label.

[0052] It should be noted that the process of the receiving end parsing the predicted label from the current MPI message does not affect its normal processing of the current label. The receiving end can use the parsed current label to search for a match in the expected message queue according to the normal MPI matching process and complete the reception of the current data; at the same time, the parsed predicted label is used as the input parameter for triggering the prefetch mechanism to execute the operation in the subsequent step S103.

[0053] Step S103: Based on the predicted tag, the receiving end adds the receiving request for the subsequent MPI message to the MPI expected message queue before the subsequent MPI message arrives.

[0054] In this embodiment, this step aims to utilize the time window between the current message processing and the arrival of subsequent messages to advance the originally delayed receiving operation, thereby achieving proactive pre-fetching of subsequent messages.

[0055] Specifically, at the receiving end, after parsing the predicted tag, a new receive request for subsequent MPI messages can be constructed based on the predicted tag. This receive request can include three elements that uniquely identify an MPI message: the Communicator, the Rank of the source process, and the Tag. The Tag field is filled with the predicted tag, while the Communicator and the Rank of the source process can usually be directly derived from the relevant context information of the current MPI message, or deduced based on a preset communication mode.

[0056] Furthermore, after the matching key is constructed, the deduplication and pre-release logic is executed through the receiving end.

[0057] As a specific implementation method, the receiving end first searches the existing MPI expected message queue to check whether there is already a receiving request that matches the predicted label (and the Rank of the corresponding communication sub-process and source process); If the query results show that a matching receive request already exists in the expected message queue, it means that the upper-layer application on the receiving end has issued the receive call in a timely manner, or that the previous prediction mechanism has taken effect.

[0058] At this point, the receiving end keeps the expected message queue state unchanged to avoid duplicate reception or resource conflicts.

[0059] Furthermore, if the query results show that there is no matching receive request in the expected message queue, it means that the receive call for subsequent messages has not yet been published.

[0060] At this point, the receiving end actively generates a corresponding receiving request based on the predicted label and adds it to the expected message queue.

[0061] Furthermore, in scenarios involving interaction with upper-layer applications, the specific operation of adding the received request to the expected message queue can be implemented through a callback or notification mechanism.

[0062] That is, when the MPI underlying library of the receiving end detects a missing matching request, it sends a buffer prefetch notification to the upper-layer application of the receiving end. This notification can carry prediction label information, thereby instructing the upper-layer application to allocate the corresponding memory buffer as soon as possible and call the receiving interface to send the receiving request corresponding to the buffer to the expected message queue.

[0063] In the implementation method and system of MPI-based in-path label matching in the above embodiments of this disclosure, by having the sending end carry a predicted label in the current MPI message, the receiving end can proactively detect and add the receiving request for subsequent messages to the expected message queue in advance. This realizes a mechanism shift from passive receiving to proactive prefetching, significantly reducing the generation of unexpected messages. This avoids overflow interruptions and hardware / software synchronization overhead caused by the exhaustion of hardware unexpected queue resources, significantly improving communication throughput. By utilizing existing data transmission channels to transmit predicted signaling in-path, there is no need to establish additional connections or send independent control messages; label prediction and synchronization with zero additional communication frequency overhead are achieved. By ensuring that subsequent messages can directly match the receiving request in the expected queue when they arrive at the receiving end, zero-copy transmission of data bypassing temporary buffers and directly writing to the user buffer is achieved. This breaks through the physical limitation of the unexpected message buffer depth on high-performance network cards, fully releasing computing power and improving performance.

[0064] In one possible implementation of step S101 above, the current MPI message includes a standard label field, which is divided into a first field and a second field; wherein the first field is used to carry the current label and the second field is used to carry the predicted label.

[0065] In this embodiment, considering the standardization of the MPI communication protocol and to maintain compatibility with existing underlying network hardware, this disclosure proposes a field reuse strategy.

[0066] Specifically, a standard MPI message header can typically contain a fixed-length tag field, such as a 32-bit integer. In order to transmit prediction information without changing the message header structure or increasing the payload length, this embodiment can logically divide the tag field into two independent bit fields.

[0067] For example, assuming the total length of the label field is L bits (e.g., 32 bits), the lower M bits of the label field can be defined as the first field to store the value of the current label; and the higher LM bits of the label field can be defined as the second field to store the value of the predicted label.

[0068] The value of M can be flexibly set according to the range of label values ​​in the actual application scenario. For example, M can be equal to 16, in which case the high 16 bits and the low 16 bits each occupy half of the label field, storing the predicted label and the current label respectively.

[0069] In this configuration, the sending end's processing logic may specifically include: when preparing to send a message, the sending end obtains the current tag value required by the current business logic and the predicted tag value obtained from the prediction; subsequently, the sending end uses bitwise operations to assemble these two values ​​into the same tag field.

[0070] For example, the predicted tag can be moved to a higher bit by a left shift operation, and then the current tag can be filled into a lower bit by a bitwise OR operation, thereby generating the final composite tag to be sent.

[0071] Correspondingly, the processing logic of the receiving end can include: after receiving the message, the receiving end reads the tag field and performs unpacking using the corresponding bitmask and shift operation.

[0072] For example, the current label in the first field can be directly extracted by performing a bitwise AND operation with the low-order mask, and used for the current matching process; at the same time, the high-order data is shifted to the low-order by a right shift operation, thereby extracting the predicted label in the second field, which is used for the subsequent prefetching process.

[0073] It should be noted that the division of the first and second fields is not limited to high-low bit splitting; other mapping methods can also be used, as long as the sender and receiver follow the pre-agreed encoding rules.

[0074] In the implementation method and system of MPI-based in-path label matching in the above embodiments of this disclosure, by reusing existing label fields, no additional extended fields need to be added to the MPI message header, nor is any data payload space required. This ensures that the transmission of prediction information does not increase the number of bytes transmitted over the network and does not introduce additional bandwidth overhead. Since the physical frame structure of the MPI message is not changed, this scheme can run directly on existing network hardware and drivers without modifying the underlying hardware logic, thereby greatly improving compatibility and practicality.

[0075] In one possible implementation of step S101 above, the predicted label includes the label of the Nth subsequent MPI message that the sender will send, or the label sequence of the Nth subsequent MPI message that the sender will send; where N is a positive integer.

[0076] In this embodiment, the prediction mechanism of the sending end is not limited to predicting only the next adjacent message (i.e., the case of N=1), but can support more flexible jump prediction or batch prediction to adapt to complex parallel computing modes and network environments.

[0077] Specifically, a skip-style prediction scenario can be as follows: In some parallel algorithms, the sender may predict that the communication operation in the Nth step is a critical path, or predict that the Nth message is a large message using the Rendezvous protocol, while the intermediate messages are ordinary control packets; in this case, the sender can configure a prediction label to point to the Nth message in the future.

[0078] Specifically, if N>1 is set, for example N=3, it means that the current message carries the tag of the "next next next" message.

[0079] After the receiving end parses the tag, it prepares the receiving resources in advance for the Nth message. This mechanism is particularly suitable for scenarios where computation and communication highly overlap. By giving the receiving end an advance notice of N steps, it provides sufficient time for the receiving end to schedule memory or complete the previous heavy computation task, preventing the buffer from being unprepared when critical messages arrive due to the receiving end being busy.

[0080] Furthermore, the scenario for batch prediction can be as follows: In some scenarios, a series of messages are often sent continuously by the sender; in this case, the prediction label can be encoded as a label sequence containing multiple label values.

[0081] Specifically, the sender can package the tags of N future messages (e.g., Next_1, Next_2, ..., Next_N) into the current message. Upon receiving the current message, the receiver parses the tag sequence and triggers the construction and enqueueing of N receive requests all at once.

[0082] It should be noted that the value of N can be preset by the system administrator or other relevant personnel, or it can be dynamically adjusted by the sender based on the current network congestion level or unexpected queue backlog. When the value of N is large, compression encoding or other methods can be used to carry the tag sequence in order to avoid occupying too much header space.

[0083] Furthermore, to ensure full compatibility with the original MPI program, this embodiment also provides a fallback scheme for the prediction mechanism.

[0084] Specifically, when the prediction tag carried in the current MPI message is a preset invalid value (such as 0), it indicates that the current MPI message does not carry valid prediction information. In this case, the receiving end skips the step of adding the receive request to the MPI expected message queue and processes the subsequent MPI messages according to the standard MPI protocol.

[0085] Understandably, this mechanism allows developers to silently revert to the existing MPI passive waiting process by entering invalid values ​​when they cannot specifically identify subsequent tags or do not need to predict them. Therefore, this fallback scheme achieves full compatibility and flexible switching with standard MPI programs without changing the core tag matching process or introducing any additional processing overhead.

[0086] In the implementation method and system of MPI-based in-path label matching in the above embodiments of this disclosure, when adopting a skip-based prediction scenario, by supporting the prediction of the Nth subsequent message, the system can skip intermediate non-critical or uncertain communication steps and directly lock the communication needs of future critical nodes. This provides the receiving end with a longer preparation time window, effectively smooths the receiver response delay caused by fluctuations in computing load, and further reduces the risk of critical path messages entering unexpected queues. Furthermore, batch prediction reduces the number of context switches, improving system throughput performance when facing high-concurrency message streams. Simultaneously, by introducing a fallback mechanism for invalid predicted labels, this solution possesses extremely high robustness and compatibility, ensuring the stable operation of the communication system under various complex business scenarios.

[0087] In one possible implementation of step S103 above, the request to receive subsequent MPI messages is added to the MPI expected message queue, including: The receiving end checks the MPI expected message queue for a receive request that matches the predicted label. If no match is found, a buffer prefetch notification is sent to the upper-layer application of the receiving end to instruct the upper-layer application to send the corresponding receive buffer. If a matching receive request already exists, the MPI expected message queue state remains unchanged.

[0088] In this embodiment, the accuracy of receiving request publication can be ensured by adopting a query-notification logic control strategy at the receiving end.

[0089] Specifically, after the predicted label is parsed by the receiving end, the MPI underlying library first performs a traversal query operation on the current expected message queue; the matching key of the query can include the predicted label, as well as the Rank of the communication sub-process and the source process to which the message belongs.

[0090] If the query result is empty, it indicates that the receiving request for the predicted tag has not yet been published. At this time, the MPI underlying library sends a buffer prefetch notification to the upper-layer application through a preset interface. The notification contains the predicted tag, which is used to trigger the upper-layer application to perform memory distribution operations and call the receiving interface to generate an receiving request containing the user buffer address, thereby inserting the receiving request into the expected message queue.

[0091] Furthermore, if the query result indicates that a matching receive request already exists in the queue, it can be interpreted that the upper-layer application has published a receive call through the program flow; at this time, the MPI underlying library does not perform any addition or modification operations on the predicted label in order to maintain the existing state of the expected message queue.

[0092] Here, this logic is designed to prevent the erroneous state of one label corresponding to multiple buffers due to repeated insertion of accept requests.

[0093] For example, please refer to Figure 3 , Figure 3 This is a schematic diagram illustrating an expected matching scenario for an implementation method of MPI-based in-path label matching provided in this disclosure embodiment, wherein, as... Figure 3 As shown, the current message sent by the sender to the receiver, taking Msg_tag2 as an example, carries the current tag tag2 and the predicted tag tag4.

[0094] After receiving the Msg_tag2 message, the MPI underlying library at the receiving end first parses the message header, extracting the current tag tag2 and the predicted tag tag4. The receiving end then checks the expected message queue to see if there is a receive request matching the current tag tag=2. If a published receive request is found (i.e., a ready receive buffer), the message payload data is directly written to the user address space corresponding to that buffer, completing the delivery of the current message. Figure 3 As shown, the MPI underlying library finds the Buf2 corresponding to tag2 in the expected message queue and writes the message payload data directly to Buf2.

[0095] While matching the current tag, the receiving end performs a query operation in the expected message queue based on the predicted tag tag4 to determine whether there is a receiving request that matches the predicted tag; for example Figure 3 As shown, there is no receive request corresponding to tag4 in the expected message queue. The MPI underlying library sends a buffer prefetch notification to the upper layer application through a preset interface. This notification contains the predicted tag4, which is used to instruct the upper layer application to publish a receive call for tag4. The upper layer application allocates a buffer Buf4 for tag4. The MPI underlying library adds the receive request (including the Buf4 address and matching information) to the expected message queue, making it in the published state, waiting for the subsequent arrival of tag4 messages.

[0096] In the implementation method and system of MPI-based in-path label matching in the above embodiments of this disclosure, by performing a deduplication operation before notifying the upper-layer application, the problem of duplicate sending and receiving requests caused by the overlap between the prediction mechanism and the normal logic of the application layer can be effectively prevented, ensuring the uniqueness and orderliness of receiving requests in the MPI expected message queue. Simultaneously, this mechanism only notifies the application layer to allocate resources when necessary, avoiding unnecessary memory pre-occupancy and achieving on-demand preparation of the receive buffer while ensuring the correctness of communication semantics.

[0097] In one possible implementation of the above embodiments, the method further includes: If the upper-layer application does not respond to the buffer prefetch notification, and there is still no matching receive request in the expected MPI message queue when the subsequent MPI message actually arrives, then the subsequent MPI message will be stored in the unexpected message queue.

[0098] In this embodiment, the present disclosure may also provide processing logic in the event of prediction mechanism failure, thereby ensuring the reliability of storage and transmission.

[0099] Specifically, although a buffer prefetch notification is issued in step S103, in actual operation, the upper-layer application may fail to complete the publication of the receive request in time before the subsequent MPI message arrives due to reasons such as excessive computing load, thread scheduling delay, or tight memory resources.

[0100] In this scenario, when the subsequent MPI message actually arrives at the receiving end via network transmission, the MPI underlying library will perform another matching check on the expected message queue. If no receive request for that message tag is found in the expected message queue at this time, the MPI underlying library will execute the standard unexpected message handling process, including: The data payload and header information of the subsequent MPI message are stored in the unexpected message queue for buffering. The message will remain in the unexpected message queue until the upper-layer application initiates a matching receive call to retrieve it.

[0101] Furthermore, it should be noted that the solutions of this disclosure embodiment can have extremely high compatibility and fault tolerance, including: the solution can be an optimized extension based on the standard MPI tag matching process, without changing the original core tag matching process; that is, the prediction mechanism is only used as an auxiliary enhancement, and regardless of whether the prediction is accurate or effective, it will not destroy the atomicity and data integrity of MPI communication.

[0102] Furthermore, this solution has a low dependence on upper-layer application developers. In actual development, if developers have difficulty accurately predicting the tag of the next message, or to simplify the development process, the sender may not fill in the predicted tag, or even fill in a randomly generated tag value. In this case, the receiver will not be able to match a valid receive request in the deduplication logic of step S103, or after notifying the upper-layer application, the application layer will find that the tag is invalid and choose to silently discard it.

[0103] At this point, the receiving end cannot enjoy the performance improvement brought by prefetching, but when the message actually arrives, it will still enter the standard unexpected message queue for fallback processing according to the process described above in this embodiment. The entire communication process will not report errors and will not have any negative impact on the stability of the receiving side.

[0104] In the implementation method and system of MPI-based in-path label matching in the above embodiments of this disclosure, by setting a fallback mechanism for application layer no-response scenarios, it can be ensured that the communication system can still operate normally in accordance with the standard MPI protocol specification in scenarios such as invalid prediction or delayed response, thereby improving the robustness of the system.

[0105] In one possible implementation of the above embodiments, before the sending end sends the current MPI message to the receiving end, the method further includes: The tag sequence or tag generation rules are determined through negotiation between the sender and receiver via the out-of-band management network. The sender determines the predicted label carried in the current MPI message based on the label sequence or label generation rules.

[0106] In this embodiment, the out-of-band management network can refer to a physical or logical network channel that is independent of the high-speed computing network used for MPI data transmission.

[0107] Before data exchange begins in an MPI job, the sender and receiver can pre-negotiate using this out-of-band management network to reduce the probability of the receiver entering an unexpected queue due to label mismatch. The negotiated content can include the label sequence or label generation rules to be used in subsequent communication.

[0108] Here, the label sequence can refer to a predefined list of labels, and the label generation rule can refer to the label change algorithm agreed upon by both parties.

[0109] Through the above negotiation, the sender and receiver can reach an agreement before the communication begins. In the subsequent step S101, the sender does not need to guess the predicted label, but directly searches for or calculates the predicted label that the current message should carry according to the label sequence or label generation rule determined by the negotiation.

[0110] In the implementation method and system of MPI-based in-band label matching in the above embodiments of this disclosure, by placing the label planning logic of the load in the initialization stage or in the out-of-band management network in advance, the CPU instruction consumption of the MPI data path can be reduced, and the probability of the receiver entering an unexpected queue due to label mismatch can be reduced.

[0111] In one possible implementation of the above embodiments, the negotiation process is performed by a job manager connected to the out-of-band management network, and the negotiation process includes: The planned tag sequence is distributed to the sending and receiving ends via the out-of-band management network through the job manager; Upon receiving the planned tag sequence, both the sending and receiving ends return confirmation responses to the job manager. Upon receiving a confirmation response via the Job Manager, the MPI job is started.

[0112] In this embodiment, a job manager is introduced as a global coordinating node to achieve centralized communication orchestration. Here, the job manager can be a job scheduling system component in a high-performance computing cluster, or a dedicated MPI initiator.

[0113] Specifically, the negotiation process may include the following steps: During the MPI program initialization or job submission phase, the job manager generates a global communication tag plan based on the static analysis results of the parallel program or a user-preset configuration file. Subsequently, the job manager pushes the planned tag sequence to each sending and receiving end participating in the computation via the out-of-band management network.

[0114] After receiving the tag sequence, the sender and receiver load it into local memory and send an acknowledgment response to the job manager.

[0115] The job manager collects confirmation responses from all relevant nodes before officially issuing the job start command and initiating the MPI communication process.

[0116] As an example, please refer to Figure 4 , Figure 4 A schematic diagram of the negotiation process for an implementation method of MPI-based in-path label matching provided in this disclosure embodiment is shown below. Figure 4 As shown, in the first stage, the job manager determines the tag sequence or tag generation rule negotiated between the sender and receiver, and sends the tag sequence or tag generation rule to the sender and receiver respectively. The sender and receiver return response information of receiving the tag to the job manager respectively. In the second stage, the job manager starts the MPI job, and the sender and receiver perform normal message interaction according to the sent tag sequence or tag generation rule.

[0117] In the implementation method and system of MPI-based in-path label matching in the above embodiments of this disclosure, the mechanism of sending-confirming-starting ensures that all nodes have a consistent prediction context before entering the high-speed communication stage. This effectively prevents the problem that the initial message cannot be correctly predicted or matched due to inconsistent node startup speeds.

[0118] In one possible implementation of the above embodiments, the method further includes: The receiver sends a desired tag notification to the sender. The desired tag notification is used to indicate the tag that the receiver is about to publish in the receive buffer. The sending end receives the expected label notification and, if out-of-order transmission is allowed or there is no dependency between different labeled messages, adjusts the sending order of subsequent MPI messages according to the expected label notification; wherein, the predicted label carried in the current MPI message is determined based on the adjusted sending order.

[0119] In this embodiment, to further improve matching efficiency, a receiver demand-driven mechanism can also be introduced.

[0120] Specifically, the specific steps of this embodiment may include: In step a1, the receiving end can identify the most urgent or soon-to-be-ready receiving task based on its own computing logic or resource status, construct an expected tag notification and send it to the sending end. The expected tag notification may include the target tag that the receiving end expects to receive first.

[0121] In step a2, after receiving the expected tag notification, the sending end scans the local message queue to be sent. If a message matching the target tag is found in the queue, the sending end will perform a queue rearrangement operation, raising the priority of the message and moving it to the front of the sending queue so that it becomes a subsequent MPI message to be sent.

[0122] Step a3: Based on the adjusted sending order, the sender redetermines the predicted labels in the messages currently being constructed or about to be sent.

[0123] For example, if the original planned sending order is Msg_1→Msg_2 and the predicted tag is tag2; after receiving the notification of the expected tag3, the sending order is adjusted to Msg_1→Msg_3→Msg_2; at this time, when Msg_1 is sent as the current MPI message, the predicted tag it carries will be dynamically modified to tag3.

[0124] It should be noted that the aforementioned mechanism is particularly applicable to communication scenarios where out-of-order execution is permitted or scenarios where there is no strong data dependency between different tags.

[0125] As an example, please refer to Figure 5 , Figure 5 A schematic diagram illustrating the process of the receiver actively sending expected label notifications for an implementation method of MPI-based in-path label matching provided in this embodiment of the disclosure, as shown below. Figure 5As shown, the dashed line represents the normal message interaction process between the sender and receiver. At time T0, the receiver actively sends a request for a tag notification to the sender, informing the sender that it expects to receive resource 1 labeled as tag. At time T1, the receiver actively sends another request for a tag notification to the sender, informing the sender that it expects to receive resource 2 labeled as tag. After receiving these two notifications, the sender optimizes and schedules its message queues according to the tag information in the notifications, prioritizing the sending of matching messages.

[0126] In the implementation method and system of MPI-based in-path label matching in the above embodiments of this disclosure, by dynamically adjusting the sending order to match the buffer state of the receiving end, the probability of directly hitting the expected message queue when the message arrives is greatly increased, thereby maximizing the utilization of the zero-copy transmission capability of the hardware offloading engine and reducing memory bandwidth consumption.

[0127] In one possible implementation of the above embodiments, the request to receive subsequent MPI messages is added to the MPI expected message queue, including: The receiving end constructs a receiving request using the communication sub-information to which the current MPI message belongs, the source process identifier information of the current MPI message, and the predicted label.

[0128] In this embodiment, the MPI standard can uniquely identify a matching request by including three core elements: the Communicator, the source process identifier (i.e., the Rank of the aforementioned source process), and the message tag.

[0129] When the sender carries a prediction tag in the current MPI message, it implies that the subsequent messages corresponding to the prediction tag are still sent by the same sender (i.e., the sender of the current message) in the same communication domain.

[0130] Therefore, when the receiving end constructs a new receive request for the predicted label, it does not need to renegotiate or transmit the communication sub-ID and source process Rank over the network. Instead, it can directly inherit the metadata of the MPI message currently being processed.

[0131] The receiving MPI library extracts communication sub-information and source process Rank from the descriptor of the current MPI message, combines them with the parsed predicted label to form a complete and valid receive request, and puts it into the expected message queue.

[0132] In the implementation method and system of MPI-based in-path label matching in the above embodiments of this disclosure, by reusing the communication sub-process of the current message and the Rank of the source process, the sending end only needs to transmit the label itself when carrying prediction information in the in-path, without transmitting a lengthy communication context descriptor, thereby saving network bandwidth.

[0133] In one embodiment, an MPI-based in-way label matching implementation system 600 is provided, which corresponds one-to-one with the MPI-based in-way label matching implementation methods in the above embodiments. For example... Figure 6 As shown, the system includes: The sender 601 can be an MPI process running on a compute node or its hardware offloading component. The sender 601 is used to send the current MPI message to the receiver 602. The current MPI message carries a current tag and a prediction tag for indicating subsequent MPI messages. Receiver 602 is the MPI process and its underlying support system running on another computing node, responsible for receiving and parsing messages and performing predictive prefetching. Receiver 602 is used to receive the current MPI message and parse the predicted label from the current MPI message; The receiver 602 is also used to add the receiving request for the subsequent MPI message to the MPI expected message queue before the subsequent MPI message arrives, based on the predicted label.

[0134] In one embodiment, the current MPI message includes a standard label field, which is divided into a first field and a second field; wherein the first field is used to carry the current label and the second field is used to carry the predicted label.

[0135] In one embodiment, the predicted label includes the label of the Nth subsequent MPI message to be sent by the sender 601, or the label sequence of the Nth subsequent MPI messages to be sent by the sender 601; where N is a positive integer.

[0136] In one embodiment, the receiver 602 is specifically configured to query the MPI expected message queue for a receive request that matches the predicted label; if no such request is found, it sends a buffer prefetch notification to the upper-layer application to instruct the upper-layer application to send the corresponding receive buffer. If a matching receive request already exists, the MPI expected message queue state remains unchanged.

[0137] In one embodiment, the receiver 602 is further configured to store the subsequent MPI message into the unexpected message queue if the upper layer application does not respond to the buffer prefetch notification and there is still no matching receive request in the expected MPI message queue when the subsequent MPI message actually arrives.

[0138] In one embodiment, the sending end 601 and the receiving end 602 are further configured to negotiate through the out-of-band management network to determine the tag sequence or tag generation rule before the sending end 601 sends the current MPI message to the receiving end 602; The sender 601 determines the predicted label carried in the current MPI message based on the label sequence or label generation rules.

[0139] In one embodiment, the system further includes a job manager 603 connected to an out-of-band management network. This job manager is a cluster-level control node used to coordinate communication between the two parties before job startup to ensure consistent prediction context. The negotiation process is as follows: The planned tag sequence is sent to the transmitter 601 and the receiver 602 through the out-of-band management network; The receiving end 601 and the receiving end 602 respectively return an acknowledgment response in response to receiving the planned tag sequence; Upon receiving a confirmation response, the MPI job is initiated.

[0140] In one embodiment, the receiver 602 is further configured to send a desired tag notification to the sender 601, the desired tag notification being used to indicate the tag of the receive buffer that the receiver 602 is about to publish; The sender 601 is used to receive the expected tag notification and, if out-of-order transmission is allowed or there is no dependency between different tag messages, adjust the transmission order of subsequent MPI messages according to the expected tag notification; wherein, the predicted tag carried in the current MPI message is determined based on the adjusted transmission order.

[0141] In one embodiment, the receiver 602 is specifically used to construct a receiving request using the communication sub-information to which the current MPI message belongs, the source process identifier information of the current MPI message, and the predicted tag.

[0142] It should be noted that the implementation system for MPI-based road tag matching provided in the above embodiments is only illustrated by the division of the above-described program modules when implementing the corresponding MPI-based road tag matching method. In practical applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the above system can be divided into different program modules to complete all or part of the processing described above. In addition, the apparatus provided in the above embodiments and the corresponding Figure 1 The embodiments of the methods shown belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0143] This disclosure also provides an electronic device having the above-described features. Figure 6 The system shown is an implementation of MPI-based in-path label matching.

[0144] Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure.

[0145] The following is a detailed reference. Figure 7The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present disclosure. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 701, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 702 or a program loaded from memory 708 into random access memory (RAM) 703. The RAM 703 also stores various programs and data required for the operation of the electronic device. The processor 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0146] Typically, the following devices can be connected to I / O interface 705: input devices 706 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 707 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 708 including, for example, magnetic tapes, hard disks, etc.; and communication devices 709. Communication device 709 allows electronic devices to exchange data via wireless or wired communication with other devices. Although Figure 7 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0147] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 709, or installed from memory 708, or installed from ROM 702. When the computer program is executed by processor 701, it performs the functions defined in the implementation method of MPI-based in-path tag matching according to embodiments of this disclosure.

[0148] Figure 7 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0149] This disclosure also provides a computer-readable storage medium in which the methods described in this disclosure can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium after being downloaded over a network. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the MPI-based in-path tag matching implementation method shown in the above embodiments is implemented.

[0150] A portion of this disclosure can be applied to computer program products, such as computer program instructions, which, when executed by a computer, can invoke or provide methods and / or technical solutions according to this disclosure through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, and installation package files. Accordingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions; the computer compiling the instructions and then executing the corresponding compiled program; the computer reading and executing the instructions; or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0151] Although embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for implementing in-path label matching based on MPI, characterized in that, The method includes: The sender sends a current MPI message to the receiver, and the current MPI message carries a current label and a predicted label for indicating subsequent MPI messages. The receiver receives the current MPI message and parses the predicted label from the current MPI message. Based on the predicted tag, the receiving end adds the request to receive the subsequent MPI message to the MPI expected message queue before the subsequent MPI message arrives.

2. The method according to claim 1, characterized in that, The current MPI message includes a standard label field, which is divided into a first bit field and a second bit field; wherein the first bit field is used to carry the current label, and the second bit field is used to carry the predicted label.

3. The method according to claim 1, characterized in that, The predicted label includes the label of the Nth subsequent MPI message that the sender will send, or the label sequence of the Nth subsequent MPI message that the sender will send; wherein, N is a positive integer.

4. The method according to any one of claims 1-3, characterized in that, Adding the request to receive the subsequent MPI message to the MPI expected message queue includes: The receiving end checks the MPI expected message queue to see if there is a receive request that matches the predicted label. If no request is found, a buffer prefetch notification is sent to the upper-layer application of the receiving end to instruct the upper-layer application to send the corresponding receive buffer. If a matching receive request is found, the MPI expected message queue state remains unchanged.

5. The method according to claim 4, characterized in that, The method further includes: If the upper-layer application does not respond to the buffer prefetch notification, and there is still no matching receive request in the expected MPI message queue when the subsequent MPI message actually arrives, then the subsequent MPI message will be stored in the unexpected message queue.

6. The method according to claim 1, characterized in that, Before the sending end sends the current MPI message to the receiving end, the method further includes: The tag sequence or tag generation rules are determined through negotiation between the sender and receiver via the out-of-band management network. The sending end determines the predicted label carried in the current MPI message based on the label sequence or the label generation rule.

7. The method according to claim 6, characterized in that, The negotiation process is performed by a job manager connected to the out-of-band management network, and the negotiation process includes: The planned tag sequence is distributed to the sending and receiving ends via the out-of-band management network through the job manager; Upon receiving the planned tag sequence, both the sending end and the receiving end return an acknowledgment response to the job manager. Upon receiving the confirmation response, the job manager initiates the MPI job.

8. The method according to claim 1, characterized in that, The method further includes: The receiver sends a desired tag notification to the sender, which is used to indicate the tag of the receive buffer that the receiver is about to publish. The sending end receives the expected label notification and, if out-of-order transmission is allowed or there is no dependency between different label messages, adjusts the sending order of subsequent MPI messages according to the expected label notification; wherein, the predicted label carried in the current MPI message is determined based on the adjusted sending order.

9. The method according to claim 1, characterized in that, The step of adding the request to receive the subsequent MPI message to the MPI expected message queue includes: The receiving end constructs a receiving request using the communication sub-information to which the current MPI message belongs, the source process identifier information of the current MPI message, and the predicted label.

10. A system for implementing road-in-the-loop label matching based on MPI, characterized in that, The system includes: The sending end is used to send the current MPI message to the receiving end. The current MPI message carries the current label and the predicted label used to indicate subsequent MPI messages. The receiving end is used to receive the current MPI message and parse the predicted label from the current MPI message; The receiving end is further configured to, based on the predicted label, add the receiving request for the subsequent MPI message to the MPI expected message queue before the subsequent MPI message arrives.

Images