Event notification method and apparatus, device, computer program product, and storage medium

Abstract

An event notification method and apparatus, a device, a computer program product, and a storage medium. A binding mechanism between queue pairs and completion queues involved in an event notification mechanism of a second protocol is modified, and it is proposed that the binding between queue pairs and completion queues be performed in accordance with the jurisdiction relationship between network connections and listening instances in a first protocol. Listening instances invoked in an event notification mechanism of the first protocol are also partially modified at the user-space logic level, and it is proposed that completion queues be registered within the listening scope of corresponding listening instances. A listening instance determines, by monitoring completion queue entries in a completion queue, whether a readiness event has occurred on a network connection established according to the first protocol. Then, on the basis of these completion queue entries, an event notification result conforming to the first protocol is generated and returned to an application. Accordingly, compatibility of the event notification mechanisms between the two protocols can be achieved without requiring modification of the program code of the application.

Description

An event notification method, apparatus, device, computer program product, and storage medium Technical Field

[0001] This disclosure relates to the field of communication technology, and in particular to an event notification method, apparatus, device, computer program product, and storage medium. Background Technology

[0002] Remote Direct Memory Access (RDMA) protocol supports direct access to memory data through a network interface without the intervention of the operating system kernel, thus enabling high-throughput, low-latency network communication. Transmission Control Protocol / Internet Protocol (TCP / IP), as a traditional network communication protocol, requires data transmission to be processed by the operating system kernel, resulting in higher overhead for data movement and copying.

[0003] It is evident that, compared to the TCP / IP protocol, the RDMA protocol has significant advantages in high-concurrency, low-latency I / O applications such as high-performance computing and big data analysis.

[0004] Currently, many applications are still written based on the TCP / IP protocol. While it is possible to make these applications support the RDMA protocol by modifying the program code, the cost is too high.

[0005] However, without modifying the program code, if one expects to use an RDMA device to perform data transmission for network read / write requests initiated by these applications according to the TCP / IP protocol, an incompatibility issue arises between the I / O event notification mechanisms of the two protocols, causing network read / write requests to fail. Therefore, resolving this incompatibility issue without modifying the program code has become a new challenge in the RDMA field. Summary of the Invention

[0006] This disclosure provides an event notification method, apparatus, device, computer program product, and storage medium to resolve the incompatibility issue between event notification mechanisms of TCP / IP and RDMA protocols without modifying program code.

[0007] This disclosure provides an event notification method, applicable to an operating system, the method comprising:

[0008] In response to the target application establishing a new network connection according to the first protocol, a target queue pair conforming to the second protocol is created for the network connection;

[0009] The target queue pair is bound to a completion queue conforming to the second protocol created for the target listening instance, and the target application specifies that the target listening instance should listen for events on the network connection.

[0010] Register the completed queue to the listening range of the target listening instance;

[0011] If a completion queue entry pointing to the target queue pair is read from the completion queue through the target listening instance, then a ready event is marked on the network connection in the event notification result returned to the target application, and the event notification result conforms to the first protocol.

[0012] This disclosure also provides an event notification device, including:

[0013] A module is created to create a target queue pair conforming to a second protocol for a target application that establishes a new network connection in accordance with a first protocol in response to the detection of the target application establishing a new network connection in accordance with a first protocol.

[0014] A binding module is used to bind the target queue pair to a completion queue conforming to the second protocol created for the target listening instance, wherein the target application specifies that the target listening instance should listen for events on the network connection;

[0015] The registration module is used to register the completed queue to the listening range of the target listening instance;

[0016] The notification module is configured to mark a ready event on the network connection in the event notification result returned to the target application if a completion queue entry pointing to the target queue pair is read from the completion queue through the target listening instance, and the event notification result conforms to the first protocol.

[0017] This disclosure also provides a computing device, including a memory, a processor, and communication components;

[0018] The memory is used to store one or more computer instructions;

[0019] The processor is coupled to the memory and the communication component and is used to execute one or more computer instructions for performing the aforementioned event notification method.

[0020] This disclosure also provides a computer-readable storage medium for storing a computer program that, when executed by one or more processors, causes the one or more processors to perform the aforementioned event notification method.

[0021] This disclosure also provides a computer program product, including a computer program that, when executed by one or more processors, causes the one or more processors to perform the aforementioned event notification method.

[0022] In this embodiment, the binding mechanism between queue pairs and completion queues involved in the event notification mechanism of the second protocol is modified. It proposes binding queue pairs and completion queues according to the jurisdictional relationship between network connections and listening instances in the first protocol. Furthermore, some user-mode logic of the listening instances invoked in the event notification mechanism of the first protocol is modified, proposing to register the completion queues to the listening scope of the corresponding listening instances. Based on this, for network connections established according to the first protocol but transmitting data according to the second protocol, it is proposed that the listening instance can determine whether a ready event has occurred on these network connections by listening to the completion queue entries. It is also proposed that the listening instance then generates an event notification result conforming to the first protocol based on these completion queue entries and returns it to the application. Therefore, based on the above two modifications, compatibility of the event notification mechanism between the two protocols can be achieved without modifying the application's program code. Attached Figure Description

[0023] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this disclosure, illustrate exemplary embodiments of the present disclosure and are used to explain the disclosure, but do not constitute an undue limitation of the disclosure. In the drawings:

[0024] Figure 1 is a flowchart illustrating an event notification method provided in an exemplary embodiment of this disclosure;

[0025] Figure 2 is a logical schematic diagram of an event notification method provided in an exemplary embodiment of this disclosure;

[0026] Figure 3 is a logical diagram of the existing binding mechanism in the RDMA protocol provided by an exemplary embodiment of this disclosure;

[0027] Figure 4 is a logical diagram of a modified exemplary binding mechanism provided by an exemplary embodiment of this disclosure;

[0028] Figure 5 is a schematic diagram of the structure of an event notification device provided in another exemplary embodiment of the present disclosure;

[0029] Figure 6 is a schematic diagram of the structure of a computing device provided in another exemplary embodiment of this disclosure. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0031] Before proceeding with a detailed description of the technical solutions provided in the various embodiments of this disclosure, the following is a brief explanation of several technical concepts involved in this disclosure.

[0032] The Transmission Control Protocol / Internet Protocol (TCP / IP) is a set of communication protocols used for data transmission and communication in computer networks. It is the foundational protocol of the Internet, supporting communication between various types of computers and network devices.

[0033] Remote Direct Memory Access (RDMA) is a technology for data transfer between computers that allows them to exchange data directly without going through the network stack in the operating system kernel. This means data can be transferred directly from the memory of one system to the memory of another, eliminating the overhead typically associated with memory operations. RDMA typically relies on the support of RDMA devices. An RDMA device can be understood as a hardware device capable of data transfer according to the RDMA protocol. Typical RDMA devices include RDMA network cards, which will not be discussed further here. As can be seen, RDMA, through hardware-level direct memory access, effectively reduces data transfer latency and CPU load, thus providing higher performance and lower latency. This technology bypasses the operating system kernel, utilizing dedicated hardware on the network adapter to achieve efficient, low-latency, and low-CPU-utilization network communication. In contrast, the TCP / IP protocol requires establishing a connection between the sender and receiver and performing multiple data copies in user mode and kernel mode, increasing data transfer time and resource consumption. It is evident that, compared to the TCP / IP protocol, the RDMA protocol has significant advantages in high-performance computing, big data analysis, and other I / O high-concurrency or low-latency application scenarios.

[0034] An I / O event (Input / Output Event) refers to a specific situation or state that occurs in relation to I / O operations. Common I / O events in computer systems include:

[0035] 1. Readable event: This means that data can be read from an input source (such as a file, network socket, etc.).

[0036] 2. Writable event: Indicates that data can be written to a certain output destination (such as a file, network socket, etc.).

[0037] 3. Abnormal events: such as connection interruption, error occurrence, and other abnormal situations.

[0038] When these I / O events occur, the operating system or the relevant I / O event notification mechanism will notify the application so that the application can perform the corresponding processing in a timely manner, such as reading data, sending data, or handling errors.

[0039] An I / O event notification mechanism is a mechanism for notifying applications of specific events. Both the TCP / IP and RDMA protocols incorporate I / O event notification mechanisms (hereinafter referred to as event notification mechanisms). However, due to the different programming interfaces used by TCP / IP and RDMA—TCP / IP using the socket API and RDMA using the verb API—the event notification mechanisms of these two protocols differ and are not directly compatible.

[0040] The following is a brief introduction to the event notification mechanism under the RDMA protocol:

[0041] This event notification mechanism involves several important concepts: Queue Pair (QP) and Completion Queue (CQ). The QP is the core component of the RDMA protocol, comprising a send queue and a receive queue. It handles data send and receive requests and serves as the start and end point of the RDMA operation. The CQ stores the completion status information of the RDMA operation. Therefore, when an application initiates an RDMA operation, the operation request is placed in the QP. The RDMA hardware processes the operation, and when an RDMA operation completes, it encapsulates the relevant completion status and details into a Completion Queue Element (CQE) and adds it to the CQ to record the event. The application can read the CQE in the CQ to determine whether the RDMA hardware has completed the RDMA operation.

[0042] The following is a brief introduction to the event notification mechanism under the TCP / IP protocol:

[0043] In the TCP protocol, event notification mechanisms are typically implemented based on sockets and file descriptors. Applications can monitor the status of the file descriptors corresponding to the sockets by calling various types of listener instances. When a specified event occurs on a file descriptor, the listener instance can notify the application. In the TCP / IP protocol, event notification mechanisms are primarily used to inform applications about data arrivals, opportunities to send data, connection establishment, and closure.

[0044] Through the brief introduction of the event notification mechanisms under the two protocols above, it is clear that the event notification mechanisms under the two protocols are not directly compatible.

[0045] During their research, the inventors discovered that many applications are written based on the TCP / IP protocol, and these applications suffer from insufficient I / O performance in scenarios with high concurrency or low latency. As described in the background section, if RDMA devices are to be used to transmit data for network read / write requests initiated by these applications according to the TCP / IP protocol, it usually requires modifying the application's code, which is too costly. However, without modifying the code, the incompatibility of the event notification mechanisms corresponding to the two protocols arises, leading to network read / write request failures. Therefore, how to resolve this incompatibility issue without modifying the code has become a new challenge in the RDMA field.

[0046] To address this issue, this embodiment proposes an event notification scheme to resolve the incompatibility problem between the event notification mechanisms of the TCP / IP and RDMA protocols without modifying the program code. In this way, network read / write requests initiated by applications based on the TCP / IP protocol can be transmitted by the RDMA device according to the RDMA protocol, ensuring that the applications can receive the event notification results awaited by these network read / write requests in a timely manner without obstacles, thereby ensuring that these applications can process these network read / write requests promptly.

[0047] The technical solutions provided by the embodiments of this disclosure are described in detail below with reference to the accompanying drawings.

[0048] Figure 1 is a flowchart illustrating an event notification method provided in an exemplary embodiment of this disclosure, and Figure 2 is a logical schematic diagram illustrating an event notification method provided in an exemplary embodiment of this disclosure. This method can be executed by an operating system. Referring to Figure 1, the method includes:

[0049] Step 100: In response to the target application establishing a new network connection according to the first protocol, create a target queue pair conforming to the second protocol for the network connection;

[0050] Step 101: Bind the target queue pair to the completion queue conforming to the second protocol created for the target listening instance, wherein the target application specifies that the target listening instance should listen for events on the network connection;

[0051] Step 102: Complete the registration of the queue to the listening range of the target listening instance;

[0052] Step 103: If a completion queue entry pointing to the target queue pair is read from the completion queue through the target listening instance, then in the event notification result returned to the target application, a ready event is marked on the network connection, and the event notification result conforms to the first protocol.

[0053] In this embodiment, the first protocol can be a protocol natively followed by the application. The first protocol can be the aforementioned TCP / IP protocol, but this embodiment is not limited to this. The first protocol can also be the User Datagram Protocol (UDP) or other protocols that perform event listening based on sockets; further examples are not provided here. The second protocol can be a protocol intended for data transmission for the application. The second protocol can be the aforementioned RDMA protocol, but this embodiment is not limited to this. The second protocol can also be other protocols that perform event listening based on queue pairs and completion queues; further examples are not provided here.

[0054] Regardless of the protocol, I / O events are typically managed and notified by the operating system, and this embodiment is no exception. The operating system can provide functions to upper-layer applications, which can then initiate system calls to manage and notify I / O events through the operating system. These functions may include, but are not limited to, socket functions, select functions, epoll create functions, epoll ctl functions, and epoll wait functions, etc., which will not be further exemplified here.

[0055] This embodiment proposes designing a dynamic library between the application and the RDMA device. Each application written based on the first protocol can link to this dynamic library. The dynamic library is a form of software component that is loaded into the application at runtime to implement specific functions. The dynamic library allows the application to dynamically link to these libraries at runtime, rather than statically linking the library code into the application at compile time. Therefore, introducing the dynamic library does not require modification of the application's program code.

[0056] The dynamic library designed in this embodiment can simulate various call functions required for connection in the event notification mechanism of the first protocol, and is compatible with the programming interface in the second protocol. Based on this, the operating system in this embodiment can provide various call functions required for the event notification mechanism to the upper-layer application as usual. However, in this embodiment, the user-mode logic of these call functions in the dynamic library has been modified, so that the operating system in this embodiment can manage and notify I / O events according to the event notification scheme provided in this embodiment.

[0057] Referring to Figure 1, in step 100, in response to the target application establishing a new network connection according to the first protocol, a target queue pair conforming to the second protocol is created for that network connection. The target application can be any application written based on the first protocol but wishing to utilize the network device corresponding to the second protocol for data transmission. For example, if the second protocol is the RDMA protocol, the network device corresponding to the second protocol is an RDMA device.

[0058] In practical applications, according to the first protocol, after establishing a new network connection, the target application can call the socket function to create a corresponding socket for the network connection and record the file descriptor corresponding to the socket. In this embodiment, the operating system can listen for the target application's call to the socket function and use this as a trigger to call the library function provided by the second protocol for creating queue pairs, thereby creating a target queue pair for the network connection. It is worth noting that the work queue (WQ) in the target queue pair actually records the waiting queue of the socket corresponding to the network connection. The waiting queue is a concept in the first protocol. The waiting queue corresponding to the socket usually records waiting threads or processes that are interested in specific events on the socket (such as readable, writable, and exception events). These waiting threads or processes can be understood as network read / write requests initiated by the application.

[0059] In the second protocol, the queue pair is the starting point for data transmission operations. The network device corresponding to the second protocol can read the relevant work requests (in this embodiment, network read / write requests initiated by the target application) from the queue pair and execute data transmission for these work requests according to the second protocol. Therefore, by creating a target queue pair for the network connection, the network connection established according to the first protocol can be converted into a network connection conforming to the second protocol. Referring to Figure 2, in other words, after creating a target queue pair for the network connection, the ordinary network card corresponding to the first protocol no longer performs data transmission for the network connection, but instead, the network device corresponding to the second protocol can be triggered to perform data transmission for the network connection. For example, if the first protocol is TCP / IP and the second protocol is RDMA, then the network connection can be converted into an RDMA connection, and the ordinary network card corresponding to the TCP / IP protocol no longer performs data transmission for the network connection, but instead, the RDMA device can be triggered to perform data transmission for the network connection.

[0060] In this embodiment, the binding mechanism between queue pairs and completion queues in the second protocol is modified. It is proposed that the binding between queue pairs and completion queues be performed in accordance with the jurisdictional relationship between network connections and listening instances in the first protocol.

[0061] Figure 3 is a logical diagram of the existing binding mechanism in the RDMA protocol provided by an exemplary embodiment of this disclosure. Referring to Figure 3, taking the first protocol using the TCP / IP protocol and the second protocol using the RDMA protocol as an example, in the RDMA protocol, there is a many-to-one binding relationship between QP and CQ, and once the binding relationship between QP and CQ is established, it cannot be changed. Therefore, in this embodiment, the modification of this existing binding mechanism mainly involves the following aspects:

[0062] 1. Associate the completion queue with a listening instance in the TCP / IP protocol;

[0063] 2. The original many-to-one binding relationship between queue pairs and completion queues has been changed to a more flexible many-to-many binding relationship;

[0064] 3. Change the binding relationship that originally did not support dynamic modification to support dynamic modification.

[0065] Based on this, referring to Figure 1, in step 101, the target queue pair can be bound to a completion queue conforming to the second protocol created for the target listening instance. Here, the target listening instance is a listening instance specified by the target application for event listening on the network connection; in other words, there is a jurisdictional relationship between the target listening instance and the network connection. In this embodiment, the target application can specify one or more target listening instances for the network connection. If there are multiple target listening instances, completion queues bound to the target queue pair can be selected under each of the multiple target listening instances, and the target queue pair can be bound to the selected completion queue.

[0066] As mentioned earlier, in the event notification mechanism of first-level protocols such as TCP / IP, applications can invoke various types of listening instances to implement event notification. Here, a listening instance can be understood as a program instance used to implement the event listening mechanism, or as a process or thread. In this embodiment, the target listening instance invoked by the target application can be a single-channel listening instance or a multiplexed listening instance. A single-channel listening instance can be understood as a listening instance that can only listen to a single file descriptor at a time, while a multiplexed listening instance can be understood as a listening instance that can listen to multiple file descriptors simultaneously. Typical multiplexed listening instances may include listening instances using traversal mechanisms such as select and poll, and also listening instances using non-traversal mechanisms such as epoll. Furthermore, for a new network connection, the target application can invoke one or more target listening instances. If there are multiple instances, they can work independently according to the event notification scheme provided in this embodiment. Therefore, the following description will focus on the event notification scheme from the perspective of a single target listening instance.

[0067] This embodiment proposes creating completion queues for various types of listening instances in first protocols such as TCP / IP. A completion queue created for a single listening instance can be one or more. The completion queue created for a listening instance will be dedicated to that listening instance.

[0068] Thus, in step 101, based on the modified binding mechanism proposed in this embodiment, the target queue pair corresponding to the network connection can be bound to the completion queue corresponding to the target listening instance, according to the jurisdiction relationship between the target listening instance and the network connection. After completing the data transmission for the target queue pair, the network device corresponding to the second protocol can write a completion queue entry pointing to the target queue pair into the completion queue bound to the target queue pair.

[0069] Furthermore, as mentioned earlier, this embodiment also proposes that the modified binding mechanism supports dynamic modification of binding relationships. Taking the target queue pair as an example, this embodiment proposes that when the target application instructs the target monitoring instance to no longer manage the network connection, the binding relationship between the target queue pair and the completion queue corresponding to the target monitoring instance can be released. For example, if the network connection has been disconnected or the target application has assigned the network connection to another monitoring instance for management, then in this embodiment, the target queue can be unbound from its original bound completion queue. Of course, if the network connection is assigned to another monitoring instance for management, based on the modified binding mechanism in this embodiment, the target queue pair can be bound to the completion queue of another monitoring instance; that is, it can be rebound after unbinding. This effectively adapts to the flexible management relationship between network connections and monitoring instances in first protocols such as TCP / IP.

[0070] During their research, the inventors discovered that, according to the event listening mechanism of first protocols such as TCP / IP, after a target application creates a new network connection, it needs to register the file descriptor of the socket corresponding to that network connection with the listening instance's listening range. This allows the listening instance to monitor specific events occurring on the socket by listening to that file descriptor. However, in this embodiment, data transmission for this network connection is no longer performed according to the first protocol; instead, it has been converted to data transmission by a network device corresponding to the second protocol. The network device corresponding to the second protocol does not operate the socket's file descriptor according to the first protocol. Consequently, the listening instance can no longer monitor specific events occurring on the socket through the socket's file descriptor.

[0071] Therefore, referring to Figure 1, in this embodiment, step 102 proposes that the completion queue created for the target monitoring instance can also be registered within the monitoring scope of the target monitoring instance. This makes the completion queue a new monitoring object for the target monitoring instance (originally, the monitoring objects in the target monitoring instance only included the sockets corresponding to the various network connections it needed to manage). Thus, when a write operation occurs on the completion queue created for the target monitoring instance, it can be detected by the target monitoring instance in a timely manner.

[0072] In this embodiment, various implementation methods can be used to register the completion queue to the listening range of the target listening instance. In one optional implementation method, the file descriptor corresponding to the completion queue can be added to the set of file descriptors that the target listening instance is interested in, so as to register the completion queue to the listening range of the target listening instance.

[0073] According to the TCP / IP protocol and other first protocols, the target application can call functions such as epoll_ctl to add / delete file descriptors of interest to the listening instance, thereby registering the sockets it needs to monitor with the listening instance. The registration process involves adding the file descriptors of the sockets to be monitored to the set of file descriptors monitored by the listening instance through this function call. In this optional implementation, the file descriptors of the completion queue created for the target listening instance in this embodiment are also added to the set of file descriptors monitored by the target listening instance. Thus, from the perspective of the target listening instance, it still monitors the file descriptors according to the first protocol and is unaware that the file descriptor actually corresponds not to any socket, but to the completion queue created for the target listening instance in this embodiment.

[0074] It is understood that, referring to Figure 2, in this embodiment, after the relevant processing of steps 100-102, the target listening instance called by the target application can listen to the state changes of the target queue to the bound completion queue. The state changes of the completion queue actually reflect the event changes on the network connection. Therefore, in this embodiment, the completion queue is used as a carrier to transmit the event changes on the network connection to the target listening instance, thereby enabling the target listening instance to have the ability to sense whether a ready event has occurred on the network connection.

[0075] Based on this, referring to Figure 1, in step 103 it is proposed that: if a completion queue entry pointing to the target queue pair is read from the completion queue through the target listening instance, then in the event notification result returned to the target application, a ready event is marked on the network connection, and the event notification result conforms to the first protocol.

[0076] According to the second protocol, after completing data transmission, the network device can write a completion event entry (CQE) to the completion queue bound to the queue pair. This embodiment follows this basic logic from the second protocol. Thus, after completing data transmission for the target queue pair according to the second protocol, the network device corresponding to the second protocol will write a completion event entry to the completion queue bound to the target queue pair. Furthermore, as mentioned earlier, the target listening instance specified by the target application for the network connection established according to the first protocol can be one or more. If there are multiple target listening instances, after the network device corresponding to the second protocol completes data transmission for the target queue pair, it will write a completion event entry pointing to the target queue pair to the completion queues bound to the target queue pair under multiple target listening instances. This ensures that multiple target listening instances can listen to the ready events on the target queue pair.

[0077] During their research, the inventors discovered that the target application might initiate system calls to wait for events periodically or according to other time mechanisms. For example, the target application could initiate calls to functions such as `select` or `epoll wait` to begin waiting for events. According to first protocols such as TCP / IP, when such system calls occur, the operating system needs to return an event notification result to the target application through the target listening instance. Referring to Figure 2, this embodiment retains the step in the first protocol where the target listening instance returns the event notification result to the target application; however, the process of generating the event notification result in this step has been modified.

[0078] After the modification, referring to step 103, the target listening instance will perform read operations on its corresponding completion queue as needed. By reading the completion queue entries, it will find queue pairs with ready events, and then, based on the correspondence between queue pairs and network connections, it will find network connections with ready events. With this added processing logic, the target listening instance can find network connections with ready events and mark them in the event notification results, thus enabling timely event notification to the target application when a ready event occurs on the network connection.

[0079] As can be seen, in this embodiment, the event notification result returned by the target monitoring instance to the target application conforms to the first protocol. Moreover, the target monitoring instance can also mark those network connections that have been converted to transmit data according to the second protocol and have generated ready events in the event notification result. Therefore, although the network connections established by the target application according to the first protocol have been converted to transmit data according to the second protocol, based on the modification of the event notification result generation process in this embodiment, it can be ensured that the target application can still perceive whether ready events have occurred on these network connections without any obstacles, so as to process the network read and write requests on these network connections in a timely manner.

[0080] Furthermore, as mentioned earlier, in this embodiment, the network connection established by the target application according to the first protocol can be converted to data transmission according to the second protocol, that is, the network device corresponding to the second protocol is used to transmit data for this type of network connection. Based on the event notification scheme provided in this embodiment, the event notification mechanisms under the two protocols can be made compatible with each other, thereby ensuring that the target application can be aware of whether a ready event has occurred on this type of network connection without any obstacles. Referring to Figure 2, in addition to the compatibility issue of the event notification mechanism, there is also the memory sharing issue under the two protocols, that is, how can the data prepared by the network device corresponding to the second protocol be used by the application based on the first protocol? Regarding this part of the problem, this embodiment supports the use of various existing or future solutions, such as Shared Memory Communication over RDMA (SMC-R) technology, etc., and will not provide more examples of solutions here, nor will the principles of these solutions be described in detail. Regardless of which solution is adopted, it will not affect the implementation of this case.

[0081] In summary, this embodiment modifies the binding mechanism between queue pairs and completion queues in the event notification mechanism of the second protocol. It proposes binding queue pairs and completion queues according to the jurisdictional relationship between network connections and listening instances in the first protocol. Furthermore, it modifies some user-mode logic of the listening instances called in the event notification mechanism of the first protocol, proposing to register the completion queues within the listening scope of the corresponding listening instances. Based on this, for network connections established according to the first protocol but transmitting data according to the second protocol, it proposes that the listening instance can determine whether ready events have occurred on these network connections by listening to the completion queue entries. It also proposes that the listening instance generate event notification results conforming to the first protocol based on these completion queue entries and return them to the application. Therefore, based on the above two modifications, compatibility of the event notification mechanism between the two protocols can be achieved without modifying the application's program code. Moreover, the event notification scheme proposed in this embodiment uses the listening instances originally required in the first protocol throughout, without introducing additional processes / threads. Therefore, it does not introduce additional inter-thread communication, effectively reducing CPU overhead and response latency.

[0082] In the above or following embodiments, different binding mechanisms for queue pairs and completion queues may be provided for various types of listening instances that may be invoked in the first protocol. The binding mechanism will be described in detail below for several exemplary listening instances.

[0083] Figure 4 is a logical diagram of a modified exemplary binding mechanism provided by an exemplary embodiment of this disclosure. Figure 4 illustrates the binding mechanisms designed for several types of listening instances.

[0084] Referring to Figure 4, for a single-channel monitoring example:

[0085] A unique completion queue can be created for a single-listening instance, and this completion queue is dedicated to that single-listening instance.

[0086] For any network connection managed by the single-round listener instance, the queue pair created for the network connection can be bound to the unique completion queue corresponding to the single-round listener instance, and the queue pair exclusively occupies the completion queue.

[0087] Referring to Figure 4, here is an example of a multiplexed listening instance using a traversal mechanism such as select or poll:

[0088] Multiple completion queues can be created for a single listener instance, and each completion queue is dedicated to that specific listener instance.

[0089] For any network connection managed by the listening instance, a queue pair created for the network connection can be bound to any available completion queue corresponding to the listening instance, and the queue pair exclusively occupies the completion queue.

[0090] Referring to Figure 4, here is an example of a multiplexed listening mechanism using non-traversal methods such as epoll:

[0091] A unique completion queue can be created for a single listener instance, and this completion queue is dedicated to that listener instance.

[0092] For multiple network connections managed by the listening instance, the queue pairs created for each network connection can be bound to the unique completion queue corresponding to the listening instance. That is, the completion queue can be bound to multiple queue pairs.

[0093] Based on this, the binding process for the target queue pairs mentioned in the above embodiments can be:

[0094] If the target listening instance is a multiplexed listening instance using a traversal mechanism, then the target queue pair is bound to any free completion queue created for the target listening instance, and the target queue pair exclusively occupies the completion queue.

[0095] If the target listening instance is a multiplexed listening instance using a non-traversal mechanism, then the target queue pair is bound to a unique completion queue created for the target listening instance. Multiple queue pairs are allowed to be bound to the completion queue.

[0096] If the target listening instance is a single-channel listening instance, the target queue pair is bound to the unique completion queue created for the target listening instance, and the target queue pair exclusively owns the completion queue.

[0097] During their research, the inventors discovered that in certain special circumstances, there may be a need to ensure partial or complete overlap in the listening ranges of different types of monitoring instances, such as during server upgrades when old and new software coexist. To support these situations, this embodiment allows the registration of a completion queue created for a particular monitoring instance to the listening ranges of other monitoring instances, thus satisfying the requirement for overlapping listening ranges. Referring to Figure 4, a completion queue created for a single-channel monitoring instance can be registered not only to the single-channel monitoring instance's own listening range but also to the listening ranges of monitoring instances such as select or poll. This allows the select or poll monitoring instances to monitor all ready events required by the single-channel monitoring instance. Following the aforementioned special case, after the transition between old and new software is complete, the single-channel monitoring instance representing the old software can be directly deactivated. Since the select or poll monitoring instances have already monitored the completion queue corresponding to the single-channel monitoring instance, deactivating the single-channel monitoring instance will not affect the monitoring of that completion queue.

[0098] In addition, this embodiment also supports binding the same queue pair to multiple completion queues. As mentioned earlier, if there are multiple target monitoring instances, the target queue pair can be bound to a completion queue under each of the multiple target monitoring instances. This is a typical case of binding the same queue pair to multiple completion queues.

[0099] It should be understood that, in this embodiment, based on the modification of the binding mechanism between queue pairs and completion queues, flexible and dynamic binding between queue pairs and completion queues is supported to comply with the jurisdiction relationship between network connections and listening instances in the first protocol. The above only exemplifies a few special cases. In practical applications, if other special cases exist, this embodiment can also provide support based on the flexible and dynamic binding mechanism. Further examples and explanations are not provided here.

[0100] The following sections will explain the ingenuity of the exemplary binding mechanism for each of the aforementioned types of listening instances.

[0101] First, for the single-channel listening instance described above, only a single completion queue is created, and each queue pair exclusively uses this completion queue. That is, the single completion queue listens for events on only one network connection at a time. This aligns with the design principle of single-channel listening instances in protocols like TCP / IP, which "can only listen to one file descriptor at a time."

[0102] Secondly, for the multiplexed listening instances using traversal mechanisms such as select or poll mentioned above, multiple completion queues can be created, but each completion queue can only be exclusively occupied by one queue pair. That is, a listening instance can listen to multiple completion queues simultaneously, but a single completion queue is only used to listen to events on a single network connection. This aligns with the design concept of first-level protocols such as TCP / IP, where listening instances can "listen to multiple file descriptors at once, and these file descriptors are listened to independently." Here, the "multiple file descriptors" mentioned in this design concept can be understood as multiple network connections, which can be aligned to the unique queue pair bound to each completion queue in the aforementioned exemplary binding mechanism.

[0103] Furthermore, for the multiplexing listening instances using non-traversal mechanisms such as epoll, only a single completion queue is created, but this completion queue can support binding to multiple queue pairs. That is, multiple network connections can be monitored through a single completion queue. This aligns with the design concept of "monitoring multiple file descriptors through a single file descriptor" in first-level protocols such as TCP / IP. Here, "a single file descriptor" refers to the "ready list" used in this type of listening instance, which can be aligned to a single completion queue in the exemplary binding mechanism described above, while "multiple file descriptors" can be understood as multiple network connections.

[0104] As explained above, the exemplary binding mechanism can cleverly adapt to the design ideas of different types of listening instances. Thus, after adding the file descriptors of the completion queue created for the listening instance in this embodiment to the listening scope of the listening instance, the listening instance can listen to the file descriptors according to its original design idea, thereby effectively reducing the modification complexity in this embodiment.

[0105] Of course, it should be understood that, in addition to the exemplary binding mechanism described above, other binding mechanisms can also be supported in this embodiment. For example, regardless of the type of monitoring instance, the number of completed queues created can be consistent with the number of network connections that the monitoring instance needs to manage at one time, and the queue pairs and completed queues are bound one-to-one. For example, multiple completed queues can be created for an epoll instance, with each completed queue used to monitor one network connection. Although this brings more monitoring pressure to the epoll instance, it does not affect the implementation of this case. In this embodiment, as long as the binding relationship between queue pairs and completed queues can be guaranteed, it is sufficient to conform to the management relationship between network connections and monitoring instances in the TCP / IP protocol. This embodiment is not limited to this, and no further examples will be given here. Of course, different binding mechanisms may bring different monitoring pressures to the monitoring instance, but as mentioned above, this does not affect the implementation of this case.

[0106] In summary, this embodiment, by designing a reasonable binding mechanism between queue pairs and completion queues for different types of listening instances, can effectively adapt to the existing design ideas of different types of listening instances, thereby effectively reducing the complexity of modification. Moreover, by reasonably designing the number of completion queues for different types of listening instances, the additional listening pressure introduced to the listening instances (i.e., the additional listening work introduced to the completion queues) can be effectively reduced, thereby reducing the response latency of the application.

[0107] In the above or following embodiments, after the target application initiates a system call to wait for an event, the target listening instance, through modifications to the relevant calling functions in this embodiment, adds the task of performing read operations on its corresponding completion queue as needed. Therefore, the timing of this read operation becomes a crucial factor in ensuring that the target listening instance can promptly receive information about the event. The target listening instance includes a user-mode listening module and a kernel-mode listening module. This embodiment proposes that the user-mode listening module of the target listening instance can be modified to trigger the target listening instance to perform read operations on the completion queue in a timely manner.

[0108] The following provides an optional implementation method for triggering the target listening instance to perform this read operation. In this optional implementation method:

[0109] The kernel-mode monitoring module can be woken up when a write operation occurs on the completion queue; the kernel-mode monitoring module then marks the file descriptor corresponding to the completion queue as ready.

[0110] The user-mode listening module queries whether the file descriptor corresponding to the completion queue has been marked as ready; if so, the user-mode listening module performs a read operation on the completion queue.

[0111] This approach utilizes the interrupt mechanism of the operating system. As is well known, interrupt signals generated by hardware require immediate processing by the operating system; otherwise, data loss may occur. According to protocols such as TCP / IP, a buffer is allocated for the socket. When data changes in the buffer, an interrupt signal is generated. The operating system will then wake up the listening instance monitoring the socket based on the interrupt signal (here, the kernel-mode listening module of the listening instance is woken up). In this optional implementation, it is proposed that this wake-up mechanism can be applied to the monitoring process of the completion queue. Specifically, in this embodiment, the completion queue is located in memory or a cache. When a write operation occurs on the completion queue, the memory or cache will issue an interrupt signal. Since the file descriptor of the completion queue is within the monitoring range of the target listening instance, the operating system can use the aforementioned wake-up mechanism to wake up the kernel-mode listening module of the target listening instance based on the interrupt signal.

[0112] In this optional implementation, the awakened kernel-mode monitoring module can utilize the file descriptor state maintenance mechanism from first protocols such as TCP / IP to maintain the state of the file descriptor pointed to by the interrupt signal. It is understandable that from the perspective of the kernel-mode monitoring module, its perception level remains unchanged, still at the file descriptor level. Therefore, in this optional implementation, there is no need to modify the file descriptor state maintenance mechanism within the kernel-mode monitoring module; the awakened kernel-mode monitoring module can use the file descriptor state maintenance mechanism from first protocols such as TCP / IP to maintain the state of the file descriptor corresponding to the completion queue.

[0113] Additionally, it is worth noting that the state maintenance mechanisms used in different types of monitoring instances differ. The following section provides an example of the state maintenance logic of the awakened kernel-mode monitoring module in this optional implementation, using the state maintenance mechanisms of several exemplary monitoring instances as examples:

[0114] If the target monitoring instance is a multiplexed monitoring instance that uses a traversal mechanism, then the kernel-mode monitoring module marks the file descriptors corresponding to the completion queue as ready in the set of file descriptors it is interested in.

[0115] If the target listening instance is a multiplexed listening instance using a non-traversal mechanism, the file descriptor corresponding to the completion queue is added to the ready list maintained in kernel mode by the kernel-mode listening module.

[0116] For example, the target monitoring instance could be a select instance employing a traversal mechanism. The state maintenance mechanism within the select instance can be summarized as follows: a data structure (i.e., the set of file descriptors of interest) is maintained in kernel mode. This data structure records the file descriptors of interest. When data changes on the socket corresponding to a file descriptor, the kernel-mode monitoring module select-kennel is awakened. Subsequently, the kernel-mode monitoring module marks the file descriptor as ready in the data structure. Using this state maintenance mechanism, all file descriptors in the completion queue corresponding to the select instance are included in this data structure. After a read or write operation occurs on any completion queue corresponding to the select instance, the kernel-mode monitoring module in the select instance can mark the file descriptor in that completion queue as ready in the data structure.

[0117] For another example, the target monitoring instance could be an epoll instance using a non-traversal mechanism. The state maintenance mechanism within an epoll instance can be summarized as follows: a ready list is maintained in kernel mode. When data changes occur on the socket corresponding to a file descriptor that the epoll instance is monitoring, the kernel-mode monitoring module `epoll wait-kennel` is awakened, and then adds the file descriptor to the ready list. Using this state maintenance mechanism, after a read / write operation occurs on the completion queue corresponding to the epoll instance, the kernel-mode monitoring module within the epoll instance can add the file descriptor in that completion queue to the ready state.

[0118] In this optional implementation, the user-mode listening module in the target listening instance listens to the kernel-mode listening module. Therefore, when the kernel-mode listening module is woken up, the user-mode listening module will also be woken up. Furthermore, the kernel-mode listening module can pass the file descriptor status maintenance results from kernel mode to user mode. The user-mode listening module can then query the status maintenance results to determine which / which file descriptors in the completion queues are marked as ready. A technical detail here is that the user-mode listening module can pre-record the file descriptors used to describe completion queues, distinguishing them from those used to describe sockets. Thus, after obtaining the status maintenance results provided by the kernel-mode listening module, the user-mode listening module can query whether there are file descriptors used to describe completion queues. If so, it can target the corresponding completion queue for the read operation. For example, in the aforementioned select instance, the user-mode listening module can query the status maintenance results (the set of file descriptors of interest) provided by the kernel-mode listening module to see if any file descriptors marked as ready are used to describe completion queues. If so, it can initiate a read operation on the corresponding completion queue. For example, the user-mode listening module in the aforementioned epoll instance can query the state maintenance results (ready list) provided by the kernel-mode listening model to see if there is a file descriptor for describing the completion queue. If so, it can initiate a read operation on the corresponding completion queue.

[0119] Accordingly, in this embodiment, the state maintenance mechanism of various monitoring instances in the first protocol, such as TCP / IP, can be adopted. The kernel-mode monitoring module can maintain the ready state of the file descriptors in the completion queue in a timely manner, thereby ensuring that the user-mode monitoring module can promptly perceive changes in the state of the completion queue. This allows the user-mode monitoring module to accurately and promptly target the completion queue that requires a read operation, improving event notification efficiency. Of course, other implementation methods can also be used in this embodiment to trigger the target monitoring instance to perform read operations on the completion queue. For example, the user-mode monitoring module of the target monitoring instance can initiate read operations on the completion queue corresponding to the target monitoring instance periodically or at other triggering times. Although this may result in some ineffective computational resource consumption even when the completion queue is empty, it does not affect the implementation of this invention. Further examples of implementation methods are not provided here.

[0120] In the above or following embodiments, the process of generating event notification results in the target listening instance has been modified so that the target listening instance can mark network connections with ready events that have been hit based on the completion queue to the event notification results. In this embodiment, this marking operation can be implemented in various ways.

[0121] In one alternative implementation: if a completion queue entry pointing to a target queue pair is read from the completion queue through the target listening instance, the file descriptor corresponding to the network connection can be read from the message header of the target queue pair; the file descriptor corresponding to the network connection is added to the set of ready file descriptors contained in the event notification result to achieve the above marking operation.

[0122] During their research, the inventors discovered that, according to first protocols such as TCP / IP, the event notification results returned by the target monitoring instance to the target application typically include:

[0123] 1. Set of ready file descriptors. This set identifies which file descriptors have ready events.

[0124] 2. Event Type. This tells the application the specific type of event that occurs on each ready file descriptor, such as readable, writable, or exception events.

[0125] Based on this, in this optional implementation, it is proposed that the file descriptor of the corresponding network connection can be recorded in the message header of the target queue pair. In this way, after the target listening instance hits the target queue pair, it can directly read the file descriptor corresponding to the network connection from the message header of the target queue pair, thereby accurately and efficiently obtaining the file descriptor that needs to be marked, and then accurately marking it in the event notification result.

[0126] It is worth noting that, in addition to the above implementation method of obtaining the file descriptors to be marked based on the message header of the queue pair, other implementation methods can also be used in this embodiment. For example, logic for recording the association between the queue pair and the file descriptors of the network connection can be added to any feasible calling function (such as the socket API). After the queue pair is hit, the association can be queried to further hit the file descriptors to be marked. This embodiment is not limited to this, and no further examples of implementation methods will be given here.

[0127] Of course, in this embodiment, the event type of these file descriptors can also be synchronously marked in the event notification result. The event type can be parsed from the list of completion events (i.e., CQE) in the completion queue.

[0128] Furthermore, in this embodiment, appropriate implementation methods can be adopted to add the file descriptor corresponding to the hit network connection to the event notification result for different types of monitoring instances. As mentioned earlier, the target monitoring instance may include a user-mode monitoring module and a kernel-mode monitoring module. This embodiment proposes that the user-mode monitoring module can be modified to cooperate with the kernel-mode monitoring module to add the file descriptor of the socket corresponding to the hit network connection to the event notification result.

[0129] The following examples illustrate several optional implementation methods for different types of listener instances.

[0130] The target listening instance is a multiplexed listening instance that uses a traversal mechanism such as select or poll.

[0131] In one optional implementation: For this type of monitoring instance, the kernel-mode monitoring module can provide the user-mode monitoring module with the set of file descriptors of interest. The user-mode monitoring module then removes the file descriptors corresponding to the completion queues from the file descriptor set and adds the file descriptors corresponding to the network connections, marking them as ready. If other completion queue entries are read from the completion queues, the user-mode monitoring module adds the file descriptors of the network connections corresponding to the queue pairs pointed to by the other completion queue entries to the file descriptor set and marks them as ready. After processing the completion queues managed by the target monitoring instance, the user-mode monitoring module removes the file descriptors not marked as ready from the file descriptor set to obtain the set of ready file descriptors.

[0132] As is well known, the key characteristic of this type of monitoring instance is that it requires multiple rounds of traversal of the set of file descriptors of interest in both kernel space and user space. This optional implementation retains this traversal mechanism, but adds modification operations to the set of file descriptors of interest in user space, namely the aforementioned file descriptor deletion, file descriptor addition, and ready status marking operations. These modification operations can add the file descriptor of the socket corresponding to the hit network connection to the event notification result, thereby converting the monitoring of the completion queue back to monitoring the file descriptors of the socket corresponding to the network connection, returning to the event monitoring mechanism of the first protocol.

[0133] The target listening instance is a multiplexed listening instance using a non-traversal mechanism such as epoll.

[0134] In an optional embodiment: For this type of monitoring instance, a ready list can be provided to the user-mode monitoring module through the kernel-mode monitoring module; the user-mode monitoring module deletes the file descriptors corresponding to the completion queues in the ready list and adds the file descriptors corresponding to the network connections; if other completion queue entries are read from the completion queues, the user-mode monitoring module also adds the file descriptors of the network connections corresponding to the queue pairs pointed to by the other completion queue entries to the ready list; after processing the completion queues managed by the target monitoring instance, the user-mode monitoring module uses the obtained ready list as a set of ready file descriptors.

[0135] As is well known, the key feature of this type of monitoring instance is the proposal to pass a ready list between user space and kernel space, thus eliminating the need for multiple rounds of traversal of the set of file descriptors of interest in both kernel space and user space. This optional implementation retains the ready list from this type of monitoring instance, but adds modification operations to the ready list in user space, namely the aforementioned file descriptor deletion, file descriptor addition, and ready status marking operations. These modification operations can add the file descriptor of the socket corresponding to the hit network connection to the event notification result, thereby converting the monitoring of the completion queue back to monitoring the file descriptors of the socket corresponding to the network connection, returning to the event monitoring mechanism of the first protocol.

[0136] In summary, in this embodiment, for different types of monitoring instances, the logic of the user-space monitoring module in the monitoring instance can be modified to convert the basic data used to generate the event notification result in user space (e.g., the set of file descriptors of interest, the ready list, etc.) back to the socket layer of the first protocol before generating the event notification result. That is, the file descriptors of the completion queue are converted back to the file descriptors of the corresponding sockets in this basic data. In this way, after the monitoring instance generates the event notification result according to this basic data, it can be ensured that the network connection hit by the completion queue in this embodiment can be accurately marked in the event notification result. Accordingly, through the above-mentioned modification operation proposed in this embodiment, the event notification mechanism of the first protocol can be reconnected, ensuring that the target application can obtain event notifications in a timely and accurate manner.

[0137] It should be noted that some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 101, 102, etc., are merely used to distinguish different operations and do not represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0138] Figure 5 is a schematic diagram of an event notification device provided in another exemplary embodiment of this disclosure. This event notification device can be implemented in an operating system. Referring to Figure 5, the event notification device may include:

[0139] Module 50 is configured to create a target queue pair conforming to a second protocol in response to detecting that a target application has established a new network connection in accordance with a first protocol.

[0140] Binding module 51 is configured to bind the target queue pair to a completion queue conforming to the second protocol created for a target listening instance, wherein the target application specifies that the target listening instance listens for events related to the network connection;

[0141] Registration module 52 is configured to register the completion queue to the listening range of the target listening instance;

[0142] The notification module 53 is configured to mark a ready event on the network connection in the event notification result returned to the target application if a completion queue entry pointing to the target queue pair is read from the completion queue through the target listening instance, and the event notification result conforms to the first protocol.

[0143] In an optional embodiment, the creation module 50 may also be configured to create a completion queue for the target listening instance, and the binding module 51 may be specifically configured to bind the target queue pair to the completion queue conforming to the second protocol created for the target listening instance when:

[0144] If the target listening instance is a multiplexed listening instance using a traversal mechanism, then the target queue pair is bound to any idle completion queue created for the target listening instance, and the target queue pair exclusively occupies the completion queue.

[0145] If the target listening instance is a multiplexed listening instance using a non-traversal mechanism, then the target queue pair is bound to a unique completion queue created for the target listening instance, and multiple queue pairs are allowed to be bound to the completion queue;

[0146] If the target listening instance is a single-channel listening instance, then the target queue pair is bound to the unique completion queue created for the target listening instance, and the target queue pair exclusively occupies the completion queue.

[0147] In an optional embodiment, when the registration module 52 registers the completion queue to the listening range of the target listening instance, it may be specifically configured as follows:

[0148] The file descriptor corresponding to the completion queue is added to the set of file descriptors that the target listening instance is interested in, so as to register the completion queue to the listening range of the target listening instance.

[0149] In an optional embodiment, the target monitoring instance includes a user-mode monitoring module and a kernel-mode monitoring module, and the notification module 53 may be specifically configured as follows:

[0150] In the event of a write operation on the completion queue, the kernel-mode monitoring module is woken up.

[0151] The kernel-mode monitoring module marks the file descriptors corresponding to the completion queue as ready.

[0152] The user-mode monitoring module queries whether the file descriptor corresponding to the completion queue has been marked as ready; if so, the user-mode monitoring module performs a read operation on the completion queue.

[0153] In an optional embodiment, when the notification module 53 marks the file descriptor corresponding to the completion queue as ready through the kernel-mode monitoring module, it can be specifically configured as follows:

[0154] If the target monitoring instance is a multiplexed monitoring instance using a traversal mechanism, then the kernel-mode monitoring module marks the file descriptor corresponding to the completion queue as ready in the set of file descriptors it is interested in.

[0155] If the target monitoring instance is a multiplexed monitoring instance using a non-traversal mechanism, then the kernel-mode monitoring module adds the file descriptor corresponding to the completion queue to the ready list maintained in kernel mode.

[0156] In an optional embodiment, when the notification module 53 marks a ready event on the network connection in the event notification result returned to the target application, it can be specifically configured as follows:

[0157] Read the file descriptor corresponding to the network connection from the message header of the target queue pair;

[0158] Add the file descriptor corresponding to the network connection to the set of ready file descriptors included in the event notification result.

[0159] In an optional embodiment, the notification module 53 may also be configured as follows:

[0160] Based on the completion queue entries pointing to the target queue pair, parse the event type corresponding to the target queue pair;

[0161] In the event notification result, the event type is marked for the file descriptor corresponding to the network connection.

[0162] In an optional embodiment, the target listening instance includes a user-mode listening module and a kernel-mode listening module. When the notification module 53 adds the file descriptor corresponding to the network connection to the set of ready file descriptors included in the event notification result, it can be specifically configured as follows:

[0163] If the target monitoring instance is a multiplexed monitoring instance using a traversal mechanism, then the kernel-mode monitoring module provides the user-mode monitoring module with the set of file descriptors of interest.

[0164] The user-mode listening module deletes the file descriptor corresponding to the completion queue from the file descriptor set and adds the file descriptor corresponding to the network connection, marking it as ready.

[0165] If other completion queue entries are read from the completion queue, the file descriptors of the network connections corresponding to the queue pairs pointed to by the other completion queue entries are also added to the file descriptor set and marked as ready by the user-mode monitoring module.

[0166] After processing the completion queue managed by the target listening instance, the user-mode listening module deletes the file descriptors in the file descriptor set that are not marked as ready, so as to obtain the ready file descriptor set.

[0167] In an optional embodiment, the target listening instance includes a user-mode listening module and a kernel-mode listening module. When the notification module 53 adds the file descriptor corresponding to the network connection to the set of ready file descriptors included in the event notification result, it can be specifically configured as follows:

[0168] If the target monitoring instance is a multiplexed monitoring instance using a non-traversal mechanism, then the kernel-mode monitoring module provides a ready list to the user-mode monitoring module.

[0169] The user-mode listening module deletes the file descriptor corresponding to the completion queue from the ready list and adds the file descriptor corresponding to the network connection.

[0170] If other completion queue entries are read from the completion queue, the file descriptor of the network connection corresponding to the queue pair pointed to by the other completion queue entries is also added to the ready list through the user-mode listening module.

[0171] After processing the completion queue managed by the target listening instance, the user-space listening module obtains the ready list as the ready file descriptor set.

[0172] In an optional embodiment, the binding module 51 may also be configured as follows:

[0173] If the target application instructs the target listening instance to no longer manage the network connection, the binding relationship between the target queue and the completion queue corresponding to the target listening instance is released.

[0174] In an optional embodiment, when binding the target queue pair to a completion queue conforming to the second protocol created for the target listening instance, the binding module 51 may be specifically configured as follows:

[0175] If there are multiple target listening instances, then select the completion queue that is bound to the target queue pair under each of the multiple target listening instances;

[0176] Bind the target queue pairs to the selected completed queues;

[0177] When a ready event occurs on the target queue pair, a new completion queue entry pointing to the target queue pair is added to the completion queues bound to the target queue pair under each of the multiple target listening instances.

[0178] It is worth noting that the technical details of the above-mentioned embodiments of the event notification device can be referred to the relevant descriptions in the foregoing method embodiments. To save space, they will not be repeated here, but this should not cause any loss of the scope of protection of this disclosure.

[0179] Figure 6 is a schematic diagram of the structure of a computing device provided in another exemplary embodiment of this disclosure. As shown in Figure 6, the computing device can be any computing device running an application program written based on a first protocol such as TCP / IP. The computing device may include a memory 60 and a processor 61.

[0180] The processor 61, coupled to the memory 60, is used to execute the computer program in the memory 60 for executing the event notification scheme in the foregoing method embodiments.

[0181] Furthermore, as shown in Figure 6, the computing device also includes: communication components 62, such as RDMA devices and ordinary network interface cards, and may also include other components such as a power supply group 63. Figure 6 only schematically shows some components and does not imply that the computing device includes only the components shown in Figure 6.

[0182] It is worth noting that the technical details of the above-mentioned embodiments of the computing device can be referred to the relevant descriptions in the foregoing method embodiments. To save space, they will not be repeated here, but this should not cause any loss of the scope of protection of this disclosure.

[0183] Accordingly, this disclosure also provides a computer-readable storage medium storing a computer program, which, when executed, can implement the steps in the above method embodiments.

[0184] Accordingly, this disclosure also provides a computer program product, which, when executed, can implement the steps in the above method embodiments.

[0185] The memory shown in Figure 6 above is used to store computer programs and can be configured to store various other data to support operation on the computing platform. Examples of this data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, pictures, videos, etc. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0186] The communication component in Figure 6 above is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 6G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component further includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA) technology, Ultra-Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0187] The power supply component in Figure 6 above provides power to various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which it resides.

[0188] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0189] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0190] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0191] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0192] It should also be noted that 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. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0193] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0194] The above description is merely an embodiment of this disclosure and is not intended to limit the scope of this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. An event notification method, applicable to an operating system, the method comprising: In response to the target application establishing a new network connection according to the first protocol, a target queue pair conforming to the second protocol is created for the network connection; The target queue pair is bound to a completion queue conforming to the second protocol created for the target listening instance, wherein the target application specifies that the target listening instance listens for events related to the network connection; Register the completed queue to the listening range of the target listening instance; If a completion queue entry pointing to the target queue pair is read from the completion queue through the target listening instance, then a ready event is marked on the network connection in the event notification result returned to the target application, and the event notification result conforms to the first protocol.

2. The method according to claim 1, wherein, Binding the target queue pair to a completion queue conforming to the second protocol created for the target listening instance includes: If the target listening instance is a multiplexed listening instance using a traversal mechanism, then the target queue pair is bound to any idle completion queue created for the target listening instance, and the target queue pair exclusively occupies the completion queue. If the target listening instance is a multiplexed listening instance using a non-traversal mechanism, then the target queue pair is bound to a unique completion queue created for the target listening instance, and multiple queue pairs are allowed to be bound to the completion queue; If the target listening instance is a single-channel listening instance, then the target queue pair is bound to the unique completion queue created for the target listening instance, and the target queue pair exclusively occupies the completion queue.

3. The method according to claim 1, wherein, Registering the completed queue to the listening range of the target listening instance includes: The file descriptor corresponding to the completion queue is added to the set of file descriptors that the target listening instance is interested in, so as to register the completion queue to the listening range of the target listening instance.

4. The method according to claim 1, wherein, The target monitoring instance includes a user-mode monitoring module and a kernel-mode monitoring module, and the method further includes: In the event of a write operation on the completion queue, the kernel-mode monitoring module is woken up. The kernel-mode monitoring module marks the file descriptors corresponding to the completion queue as ready. The user-mode monitoring module queries whether the file descriptor corresponding to the completion queue has been marked as ready; if so, the user-mode monitoring module performs a read operation on the completion queue.

5. The method according to claim 4, wherein, The kernel-mode monitoring module marks the file descriptors corresponding to the completion queue as ready, including: If the target monitoring instance is a multiplexed monitoring instance using a traversal mechanism, then the kernel-mode monitoring module marks the file descriptor corresponding to the completion queue as ready in the set of file descriptors it is interested in. If the target monitoring instance is a multiplexed monitoring instance using a non-traversal mechanism, then the kernel-mode monitoring module adds the file descriptor corresponding to the completion queue to the ready list maintained in kernel mode.

6. The method according to claim 1, wherein, In the event notification result returned to the target application, a ready event is marked on the network connection, including: Read the file descriptor corresponding to the network connection from the message header of the target queue pair; Add the file descriptor corresponding to the network connection to the set of ready file descriptors included in the event notification result.

7. The method according to claim 6, wherein, Also includes: Based on the completion queue entries pointing to the target queue pair, parse the event type corresponding to the target queue pair; In the event notification result, the event type is marked for the file descriptor corresponding to the network connection.

8. The method according to claim 6, wherein, The target monitoring instance includes a user-mode monitoring module and a kernel-mode monitoring module. It adds the file descriptor corresponding to the network connection to the set of ready file descriptors included in the event notification result, including: If the target monitoring instance is a multiplexed monitoring instance using a traversal mechanism, then the kernel-mode monitoring module provides the user-mode monitoring module with the set of file descriptors of interest. The user-mode listening module deletes the file descriptor corresponding to the completion queue from the file descriptor set and adds the file descriptor corresponding to the network connection, marking it as ready. If other completion queue entries are read from the completion queue, the file descriptors of the network connections corresponding to the queue pairs pointed to by the other completion queue entries are also added to the file descriptor set and marked as ready by the user-mode monitoring module. After processing the completion queue managed by the target listening instance, the user-mode listening module deletes the file descriptors in the file descriptor set that are not marked as ready, so as to obtain the ready file descriptor set.

9. The method according to claim 6, wherein, The target monitoring instance includes a user-mode monitoring module and a kernel-mode monitoring module. It adds the file descriptor corresponding to the network connection to the set of ready file descriptors included in the event notification result, including: If the target monitoring instance is a multiplexed monitoring instance using a non-traversal mechanism, then the kernel-mode monitoring module provides a ready list to the user-mode monitoring module. The user-mode listening module deletes the file descriptor corresponding to the completion queue from the ready list and adds the file descriptor corresponding to the network connection. If other completion queue entries are read from the completion queue, the file descriptor of the network connection corresponding to the queue pair pointed to by the other completion queue entries is also added to the ready list through the user-mode listening module. After processing the completion queue managed by the target listening instance, the user-space listening module obtains the ready list as the ready file descriptor set.

10. The method according to claim 1, wherein, Also includes: If the target application instructs the target listening instance to no longer manage the network connection, the binding relationship between the target queue and the completion queue corresponding to the target listening instance is released.

11. The method according to claim 1, wherein, Binding the target queue pair to a completion queue conforming to the second protocol created for the target listening instance includes: If there are multiple target listening instances, then select the completion queue that is bound to the target queue pair under each of the multiple target listening instances; Bind the target queue pairs to the selected completed queues; When a ready event occurs on the target queue pair, a new completion queue entry pointing to the target queue pair is added to the completion queues bound to the target queue pair under each of the multiple target listening instances.

12. An event notification device, comprising: A module is created to create a target queue pair conforming to a second protocol for a target application that establishes a new network connection in accordance with a first protocol in response to the detection of the target application establishing a new network connection in accordance with a first protocol. A binding module is used to bind the target queue pair to a completion queue conforming to the second protocol created for the target listening instance, wherein the target application specifies that the target listening instance should listen for events on the network connection; The registration module is used to register the completed queue to the listening range of the target listening instance; The notification module is configured to mark a ready event on the network connection in the event notification result returned to the target application if a completion queue entry pointing to the target queue pair is read from the completion queue through the target listening instance, and the event notification result conforms to the first protocol.

13. A computing device, comprising a memory, a processor, and communication components; The memory is used to store one or more computer instructions; The processor is coupled to the memory and the communication component and is used to execute one or more computer instructions for performing the event notification method according to any one of claims 1-11.

14. A computer-readable storage medium storing a computer program, which, when executed by one or more processors, causes the one or more processors to perform the event notification method according to any one of claims 1-11.

15. A computer program product comprising a computer program that, when executed by one or more processors, causes the one or more processors to perform the event notification method according to any one of claims 1-11.

Images