Event listening method, device and electronic equipment
By using proxy threads and multiplexed listening technology in RDMA event notification, the inflexibility of RDMA event notification is solved, compatibility between RDMA and TCP/IP event notification is achieved, and the efficiency and flexibility of event notification are improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- ALIBABA CLOUD COMPUTING CO LTD
- Filing Date
- 2022-09-30
- Publication Date
- 2026-05-19
AI Technical Summary
The event notification mechanism of the RDMA protocol is not flexible enough and cannot simultaneously meet the event notification requirements of both the TCP/IP and RDMA protocols.
By listening for RDMA event notifications through a proxy thread, querying the target CQ in multiple completion queues (CQs), obtaining the RDMA event, and determining the target QP in multiple queue pairs (QPs) associated with the target CQ, and using the thread in the waiting queue to notify the waiting thread to receive the event notification, combined with multiplexing listening techniques such as epoll, poll, and select functions, a hybrid approach of RDMA and TCP/IP event notifications is achieved.
It improves the flexibility of RDMA event notification, meets the needs of monitoring RDMA and TCP/IP event notifications, decouples CQ and QP from each other, and improves the efficiency of event notification.
Smart Images
Figure CN115509771B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of network communication technology, and in particular to an event monitoring method, apparatus and electronic device. Background Technology
[0002] Remote Direct Memory Access (RDMA) technology allows applications to directly read and write data with network cards. It can transfer data directly from the memory of one computer to another without the intervention of the operating systems of both computers. This avoids the limitations of Transmission Control Protocol / Internet Protocol (TCP / IP) and can effectively reduce communication latency and CPU utilization.
[0003] In practical applications, a single application needs to be able to perform event notifications via both TCP / IP and RDMA protocols. However, the event notification mechanisms of TCP / IP and RDMA differ significantly, and the RDMA mechanism is not flexible enough to simultaneously meet the event notification requirements of both protocols. Summary of the Invention
[0004] This application provides an event monitoring method, apparatus, and electronic device, which can improve the flexibility of monitoring RDMA event notifications to meet the needs of monitoring both RDMA and TCP / IP event notifications.
[0005] In a first aspect, embodiments of this application provide an event listening method, the method comprising:
[0006] When a Remote Direct Memory Access (RDMA) event notification is detected by the agent thread, the target CQ corresponding to the RDMA event notification is queried from multiple completion queues (CQs); multiple CQs are used to store RDMA events.
[0007] Obtain the target RDMA event corresponding to the RDMA event notification in the target CQ, and determine the target QP corresponding to the RDMA event notification in the multiple queue pairs QP associated with the target CQ based on the target RDMA event.
[0008] Identify a waiting thread in at least one thread in the waiting queue of the target QP, and notify the waiting thread that it has received an RDMA event notification.
[0009] Secondly, embodiments of this application provide an event monitoring device, the device comprising:
[0010] The query module is used to query the target CQ corresponding to the RDMA event notification from multiple completion queues when a remote direct memory access (RDMA) event notification is detected by the agent thread; multiple CQs are used to store RDMA events.
[0011] The determination module is used to obtain the target RDMA event corresponding to the RDMA event notification in the target CQ, and determine the target QP corresponding to the RDMA event notification in the multiple queue pairs QP associated with the target CQ based on the target RDMA event.
[0012] The notification module is used to identify a waiting thread in at least one thread in the waiting queue of the target QP and notify the waiting thread that it has received an RDMA event notification.
[0013] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the method described in any of the above-mentioned embodiments.
[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method described in any of the above-mentioned embodiments.
[0015] Compared with the prior art, this application has the following advantages:
[0016] This application provides an event monitoring method, apparatus, and electronic device. When a Remote Direct Memory Access (RDMA) event notification is detected by a proxy thread, the method involves querying the target CQ corresponding to the RDMA event notification from multiple completion queues (CQs). Multiple CQs are used to store RDMA events. The target RDMA event corresponding to the RDMA event notification is obtained from the target CQ. Based on the target RDMA event, the target QP corresponding to the RDMA event notification is determined from multiple queue pairs (QPs) associated with the target CQ. A waiting thread is determined from at least one thread in the waiting queue of the target QP, and the waiting thread is notified that the RDMA event notification has been received. In this embodiment, monitoring RDMA event notifications through a proxy thread and notifying waiting threads through waiting queues improves the flexibility of monitoring RDMA event notifications and meets the requirements for monitoring both RDMA and TCP / IP event notifications.
[0017] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description
[0018] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments according to this application and should not be construed as limiting the scope of this application.
[0019] Figure 1 A schematic diagram illustrating an application scenario of the event listening method provided in this application;
[0020] Figure 2 A schematic diagram illustrating an application scenario of the event listening method provided in this application;
[0021] Figure 3 This is a flowchart of an event listening method according to an embodiment of this application;
[0022] Figure 4 This is a structural block diagram of an event monitoring device according to an embodiment of this application; and
[0023] Figure 5 This is a block diagram of an electronic device used to implement embodiments of this application. Detailed Implementation
[0024] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the concept or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.
[0025] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and all of them fall within the protection scope of the embodiments of this application.
[0026] Figure 1 This is a schematic diagram illustrating an application scenario of the event listening method provided in this application. For example... Figure 1 As shown, the method in this embodiment is applied to the operating system of a computing device (e.g., a server) to listen for RDMA event notifications and TCP / IP event notifications. This can be implemented in various ways, such as through a network acceleration engine. The operating system can include various types, such as the Linux operating system.
[0027] like Figure 1As shown, RDMA event notification methods include: when creating an RDMA connection, multiple queue pairs (QP) (QP1, QP2…QPn as shown in the figure) and completion queues (CQ) (CQ1…CQn as shown in the figure) are created. Each QP corresponds one-to-one with an RDMA connection. Multiple QPs can be bound to the same CQ. RDMA events can be obtained through the CQ, but QPs do not have event notification functionality. Multiple CQs can be bound to the same event channel, which contains file handles used for RDMA event notification.
[0028] TCP / IP event notification methods include blocking and non-blocking modes. Blocking mode means that when performing a read or write operation on a TCP / IP socket, data is not returned until the operation is complete. If the condition is not met, the system will block and wait for an event notification; it will be awakened when the condition is met. Non-blocking mode means that it will not block when the condition is not met and will directly return failure. Input / output (I / O) multiplexing and listening refers to monitoring multiple file descriptors simultaneously. Once a file descriptor is ready (usually ready for reading or writing), the program is notified to perform the corresponding read or write operation. For example, it can wait for multiple socket events simultaneously, and perform a read or write operation only when at least one socket's event is triggered.
[0029] The difference between RDMA and TCP / IP event notification lies in how they bind the relationship between the QP, CQ, and event channel during connection establishment. In contrast, TCP / IP event notification binds the event notification listener instance after the connection is established. For example, a TCP / IP socket can be bound to an epoll instance after connection establishment, then unbound and bound to two other epoll instances. Therefore, RDMA event notification is less flexible; the relationship between the QP and event channel cannot be changed after binding.
[0030] To address the aforementioned problems, one embodiment of this application provides an event listening method, such as... Figure 1As shown, RDMA is used to simulate TCP / IP socket event notifications. In blocking mode, multiple events are monitored simultaneously. If the operation of one event is not completed, the system blocks and waits for the event notification. A proxy thread listens to the event channel. Upon receiving an RDMA event notification, it queries the target CQ corresponding to the RDMA event notification in multiple completion queues (CQ1...CQn as shown in the figure). The RDMA event corresponding to the RDMA event notification is retrieved from the target CQ. Based on the retrieved RDMA event, the corresponding QP for the RDMA event notification is determined from multiple QPs. The blocking wait event corresponding to the RDMA event notification is determined based on the waiting queues in the QP (waiting queue (QP1), waiting queue (QP2)...waiting queue (QPn)). As shown in the multiplexed listening instance (e.g., an epoll instance), the thread corresponding to this multiplexed listening instance is the waiting thread. The proxy thread wakes up and notifies the epoll instance that it has received the RDMA event notification, and also wakes up the thread corresponding to the blocking wait event, i.e., the read thread, to read the message content of the RDMA event notification, thus solving the limitation problem of RDMA event notifications. In this context, the epoll instance and read thread for RDMA events are pre-registered in the waiting queue. Multiple event channels and proxy threads can be configured, which addresses the issue of a single proxy thread potentially becoming a performance bottleneck. The specific number of event channels and proxy threads can be set as needed.
[0031] Another embodiment of this application provides an event listening method, such as... Figure 2 As shown, a proxy thread listens for RDMA and TCP / IP event notifications, transparently replacing a portion of the TCP / IP connection with an RDMA connection without modifying the application code. This is achieved through a dynamic library, replacing some TCP / IP connection call functions with RDMA connection call functions. The proxy thread simultaneously listens for RDMA and TCP event notifications using I / O multiplexing technology. "Notification and wake-up" are implemented using eventfd, and event notifications can be received using any of the multiplexed listening functions such as epoll, poll, and select. One eventfd corresponds to one RDMA connection, and one socket corresponds to one TCP / IP connection, allowing the use of any of the epoll, poll, and select functions to achieve a hybrid RDMA and TCP / IP event notification effect. The multiplexed listening function uses the epoll function, reimplementing an epoll instance in user space, encapsulating the native TCP / IP epoll function and eventfd, resulting in... Figure 2The encapsulated epoll instance shown maintains a list of ready events. The agent thread notifies and wakes up the epoll instance (e.g., ...). Figure 2 The epoll (blocking wait) shown is an epoll instance created using the native epoll function. It updates the ready event list by adding RDMA and TCP / IP event notification messages to the ready event list. The wrapped epoll instance blocks and waits for event notifications through the native epoll instance. After being awakened, the wrapped epoll instance checks the ready event list and reads the RDMA or TCP / IP event notification messages. Both the native epoll instance and the wrapped epoll instance are pre-registered in the waiting queue.
[0032] This application provides an event monitoring method. This method can be applied to a computing device, which may include a server, a user terminal, etc. Figure 3 The diagram shown is a flowchart of an event listening method according to an embodiment of this application, including:
[0033] Step S301: When a Remote Direct Memory Access (RDMA) event notification is detected by the agent thread, the target CQ corresponding to the RDMA event notification is queried from multiple completion queues (CQs); multiple CQs are used to store RDMA events.
[0034] Step S302: Obtain the target RDMA event corresponding to the RDMA event notification in the target CQ, and determine the target QP corresponding to the RDMA event notification in the multiple queue pairs QP associated with the target CQ based on the target RDMA event.
[0035] Step S303: Determine a waiting thread in at least one thread in the waiting queue of the target QP, and notify the waiting thread that it has received an RDMA event notification.
[0036] When creating an RDMA connection, multiple queue pairs (QPs) and completion queues (CQs) are created. Each QP corresponds one-to-one with an RDMA connection. Multiple QPs can be bound to the same CQ. CQs can store RDMA events, and QPs can store the message content of RDMA event notifications. Multiple CQs can be bound to the same event channel, which contains file handles used for RDMA event notifications. These RDMA event notifications can be sent by other devices or generated from messages sent by other devices; this application does not limit the scope of these notifications.
[0037] A proxy thread is created to listen to the event channel. If an RDMA event notification is detected, it queries the target CQ corresponding to the RDMA event notification from multiple completion queues (CQs) based on the RDMA event identifier information. The target RDMA event corresponding to the RDMA event notification is retrieved from the target CQ. Based on the retrieved target RDMA event, the target QP corresponding to the target RDMA event notification is queried from multiple QPs associated with the target CQ. At least one waiting thread in the waiting queue of the target QP is queried to receive the event notification. The number of proxy threads, QPs, CQs, and event channels can be configured according to specific needs.
[0038] RDMA events are events sent via RDMA connections. Event types can include at least one of read and write events. Target RDMA events can originate from the same terminal device or from different terminal devices. After obtaining the target RDMA event in the target CQ, the target QP is determined from among multiple QPs based on the target RDMA event and the binding relationship between the CQ and QP.
[0039] The event monitoring method provided in this application, when a Remote Direct Memory Access (RDMA) event notification is detected by a proxy thread, queries the target CQ corresponding to the RDMA event notification in multiple completion queues (CQs). Multiple CQs are used to store RDMA events. The target RDMA event corresponding to the RDMA event notification is obtained from the target CQ. Based on the target RDMA event, the target QP corresponding to the RDMA event notification is determined from multiple queue pairs (QPs) associated with the target CQ. A waiting thread is determined from at least one thread in the waiting queue of the target QP, and the waiting thread is notified that the RDMA event notification has been received. In this embodiment, by monitoring RDMA event notifications through a proxy thread and notifying the waiting thread through the waiting queue, the binding relationship between CQs and QPs can be removed, improving the flexibility of RDMA event notifications and meeting the needs of monitoring both RDMA and TCP / IP event notifications.
[0040] In one possible implementation, before identifying a waiting thread in at least one thread in the waiting queue of the target QP and notifying the waiting thread that an RDMA event notification has been received, the method further includes:
[0041] Multiple multiplexed listening instances corresponding to multiple RDMA events are registered to multiple QP waiting queues respectively, so as to determine the waiting thread based on the multiplexed listening instance.
[0042] In practical applications, a multiplexed listener instance is created for each RDMA event, and these instances are registered in the wait queues of multiple QPs. Thus, when determining the waiting thread corresponding to an RDMA event notification, the target QP queries the wait queue for the file descriptor (eventfd) corresponding to the RDMA event notification. The eventfd corresponds to a multiplexed listener instance, thus obtaining the multiplexed listener instance for the RDMA event notification, waking up and notifying the corresponding waiting thread.
[0043] In one possible implementation, the multiplexed listener instance is created by a multiplexed listener function; the multiplexed listener function includes any one of the epoll, poll, or select functions.
[0044] Multiplexing listener functions are used in input / output (I / O) multiplexing techniques to simultaneously listen for multiple event notifications. I / O multiplexing involves monitoring multiple file descriptors simultaneously; once a descriptor is ready (usually read-ready or write-ready), the program is notified to perform the corresponding read or write operation. For example, it can wait for multiple events simultaneously, and perform a read or write operation only when at least one event is triggered. Multiplexing listener functions include any one of the following: epoll, poll, or select.
[0045] The `epoll`, `poll`, and `select` functions are operating system call functions, each capable of listening for multiple event notifications simultaneously. The `select` function monitors changes in file descriptors; after being called, it blocks until a descriptor becomes ready (data is available to read or write), or after a specified waiting time, at which point it returns. After `select` returns, a ready descriptor can be found by iterating through a structure storing file descriptor information. The `poll` function manages multiple descriptors using a polling method, processing them based on their status. `epoll` uses a single file descriptor to manage multiple descriptors, storing events for file descriptors of interest to the user in a kernel event table, and uses an "event" ready notification method, receiving a notification when an event is ready.
[0046] In one possible implementation, the multiplexing listener function is the epoll function, and this method also includes:
[0047] The file descriptor eventfd and TCP / IP socket of any one of the multiple RDMA events are encapsulated to obtain an epoll instance. The multiplexed listening instance includes the epoll instance.
[0048] `eventfd` is a file descriptor used to notify events and can be used for inter-process communication. The multiplexing listener function uses the `epoll` function, reimplementing an `epoll` instance in user space. This encapsulates the native TCP / IP `epoll` function and `eventfd`, specifically by encapsulating the RDMA event file descriptor `eventfd` and the TCP / IP socket, resulting in the `epoll` instance. One `eventfd` corresponds to one RDMA connection, and one socket corresponds to one TCP / IP connection, allowing the `epoll` function to achieve a hybrid RDMA and TCP / IP event notification effect.
[0049] Alternatively, the poll or select functions can be used, with corresponding encapsulation to obtain poll or select instances.
[0050] In this embodiment, a portion of the TCP / IP connection is transparently replaced with an RDMA connection. This is achieved through a dynamic library, by replacing some of the TCP / IP connection calling functions with RDMA connection calling functions. This allows the use of a multiplexed listening function to monitor RDMA and TCP / IP event notifications without modifying the application code.
[0051] In one possible implementation, a blocking wait event is identified in at least one thread in the wait queue of the target QP, and the blocking wait event is notified that an RDMA event notification has been received, including:
[0052] In the target QP, query the epoll instance corresponding to the RDMA event notification in the waiting queue, wake up the epoll instance, and notify the waiting thread corresponding to the epoll instance that it has received the RDMA event notification.
[0053] In practical applications, regardless of whether the process is reading or writing, if the triggering condition is not met (i.e., if it is a blocking operation), the process will suspend and sleep. After querying the wait queue in the target QP and finding the epoll instance corresponding to the RDMA event notification, the process wakes up and notifies the waiting thread corresponding to the epoll instance that it has received the RDMA event notification message and can read the message.
[0054] In one possible implementation, after obtaining the target RDMA event corresponding to the RDMA event notification in the target CQ, the following is also included:
[0055] Add the message content of the target RDMA event to the ready event list of the epoll instance.
[0056] The epoll instance has a list of ready events. The agent thread updates this list before "waking up and notifying" the epoll instance, adds the message content of the RDMA event notification to the ready event list, and reads the message content of the target RDMA event notification directly from the ready event list after being woken up.
[0057] In one possible implementation, after determining a blocking wait event in at least one thread in the waiting queue of the target QP and notifying the blocking wait event that an event notification has been received, the method further includes:
[0058] Read the message content of the target RDMA event from the list of ready events.
[0059] In practical applications, the encapsulated epoll instance blocks and waits for event notifications through the native epoll instance. After the encapsulated epoll instance is woken up, it checks the list of ready events and reads the message content of the RDMA event notification.
[0060] In this embodiment, since the epoll instance created by the epoll function can query the message content of the event notification in the ready event list, the time complexity is lower compared with the poll and select functions that traverse all sockets to check the event notification messages.
[0061] Corresponding to the application scenarios and methods provided in the embodiments of this application, the embodiments of this application also provide an event monitoring device. For example... Figure 4 The diagram shown is a structural block diagram of an event monitoring device according to an embodiment of this application. The device includes:
[0062] The query module 401 is used to query the target CQ corresponding to the RDMA event notification in multiple completion queues when a remote direct memory access (RDMA) event notification is detected by the agent thread; multiple CQs are used to store RDMA events.
[0063] The determination module 402 is used to obtain the target RDMA event corresponding to the RDMA event notification in the target CQ, and determine the target QP corresponding to the RDMA event notification in the multiple queue pairs QP associated with the target CQ based on the target RDMA event.
[0064] The notification module 403 is used to identify a waiting thread in at least one thread in the waiting queue of the target QP and notify the waiting thread that it has received an RDMA event notification.
[0065] The event monitoring device provided in this application, when detecting a Remote Direct Memory Access (RDMA) event notification through a proxy thread, queries the target CQ corresponding to the RDMA event notification in multiple completion queues (CQs). These multiple CQs store RDMA events. The device retrieves the target RDMA event corresponding to the RDMA event notification from the target CQ. Based on the target RDMA event, it determines the target QP corresponding to the RDMA event notification from multiple queue pairs (QPs) associated with the target CQ. Finally, it determines a waiting thread in at least one thread in the waiting queue of the target QP and notifies the waiting thread that it has received the RDMA event notification. In this embodiment, by monitoring RDMA event notifications through a proxy thread and notifying the waiting thread through the waiting queue, the flexibility of RDMA event notifications can be improved to meet the needs of monitoring both RDMA and TCP / IP event notifications.
[0066] In one possible implementation, the device further includes a registration module for:
[0067] Multiple multiplexed listening instances corresponding to multiple RDMA events are registered to multiple QP waiting queues respectively, so as to determine the waiting thread based on the multiplexed listening instance.
[0068] In one possible implementation, the multiplexed listener instance is created by a multiplexed listener function; the multiplexed listener function includes any one of the epoll, poll, or select functions.
[0069] In one possible implementation, the multiplexing listener function is the epoll function, and the device also includes a wrapper module for:
[0070] The file descriptor eventfd and TCP / IP socket of any one of the multiple RDMA events are encapsulated to obtain an epoll instance. Multiplexed listening instances include epoll instances.
[0071] In one possible implementation, the notification module 403 is used for:
[0072] In the target QP, query the epoll instance corresponding to the RDMA event notification in the waiting queue, wake up the epoll instance, and notify the waiting thread corresponding to the epoll instance that it has received the RDMA event notification.
[0073] One possible implementation also includes adding a module for:
[0074] After obtaining the target RDMA event corresponding to the RDMA event notification in the target CQ, add the message content of the target RDMA event to the ready event list of the epoll instance.
[0075] In one possible implementation, a reading module is also included, used for:
[0076] Read the message content of the target RDMA event from the list of ready events.
[0077] The functions of each module in each device in the embodiments of this application can be found in the corresponding description in the above method, and they have corresponding beneficial effects, which will not be repeated here.
[0078] Figure 5 This is a block diagram of an electronic device used to implement embodiments of this application. For example... Figure 5 As shown, the electronic device includes a memory 510 and a processor 520. The memory 510 stores a computer program that can run on the processor 520. When the processor 520 executes the computer program, it implements the method described in the above embodiments. The number of memories 510 and processors 520 can be one or more.
[0079] The electronic device also includes:
[0080] The communication interface 530 is used to communicate with external devices and exchange and transmit data.
[0081] If the memory 510, processor 520, and communication interface 530 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0082] Optionally, in a specific implementation, if the memory 510, processor 520, and communication interface 530 are integrated on a single chip, then the memory 510, processor 520, and communication interface 530 can communicate with each other through an internal interface.
[0083] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method provided in this application.
[0084] This application also provides a chip including a processor for calling and executing instructions stored in a memory, causing a communication device with the chip installed to perform the method provided in this application.
[0085] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in the application embodiment.
[0086] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.
[0087] Further, optionally, the aforementioned memory may include read-only memory and random access memory. The memory may be volatile memory or non-volatile memory, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).
[0088] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.
[0089] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.
[0090] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.
[0091] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.
[0092] The logic and / or steps described in the flowchart or otherwise herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).
[0093] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.
[0094] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.
[0095] The above description is merely an exemplary embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope described in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. An event listening method, characterized in that, The method includes: Multiple multiplexed listening instances corresponding to various RDMA events are registered to multiple QP waiting queues. When a Remote Direct Memory Access (RDMA) event notification is detected by the proxy thread, the target CQ corresponding to the RDMA event notification is queried from multiple completion queues (CQs). The multiple CQs are used to store RDMA events. Obtain the target RDMA event corresponding to the RDMA event notification in the target CQ, and determine the target QP corresponding to the RDMA event notification in the multiple queue pairs QP associated with the target CQ based on the target RDMA event; Based on the target QP, the corresponding multiplexing monitoring instance is determined, and then the waiting thread is determined. The waiting thread is then notified that the RDMA event notification has been received.
2. The method according to claim 1, characterized in that, The multiplexed listener instance is created by a multiplexed listener function; the multiplexed listener function includes any one of the epoll function, poll function, or select function.
3. The method according to claim 1, characterized in that, The multiplexing monitoring function is the epoll function, and the method further includes: The file descriptor eventfd of any one of the multiple RDMA events and the socket of Transmission Control Protocol / Internet Protocol TCP / IP are encapsulated to obtain an epoll instance, and the multiplexed listening instance includes the epoll instance.
4. The method according to claim 3, characterized in that, The step of determining a waiting thread in at least one thread in the waiting queue of the target QP and notifying the waiting thread that it has received the RDMA event notification includes: The epoll instance corresponding to the RDMA event notification is queried in the waiting queue of the target QP, the epoll instance is woken up, and the waiting thread corresponding to the epoll instance is notified that the RDMA event notification has been received.
5. The method according to claim 3, characterized in that, After obtaining the target RDMA event corresponding to the RDMA event notification in the target CQ, the method further includes: Add the message content of the target RDMA event to the ready event list of the epoll instance.
6. The method according to claim 5, characterized in that, After determining a waiting thread in at least one thread in the waiting queue of the target QP and notifying the waiting thread that the RDMA event notification has been received, the method further includes: Read the message content of the target RDMA event from the list of ready events.
7. An event monitoring device, characterized in that, The device includes: The registration module is used to register the multiplexed listening instances corresponding to multiple RDMA events into the waiting queues of multiple QPs respectively; The query module is used to query the target CQ corresponding to the RDMA event notification from multiple completion queues (CQs) when an RDMA event notification is detected by the proxy thread; the multiple CQs are used to store RDMA events. The determination module is used to obtain the target RDMA event corresponding to the RDMA event notification in the target CQ, and determine the target QP corresponding to the RDMA event notification in the multiple queue pairs QP associated with the target CQ based on the target RDMA event; The notification module is used to determine the corresponding multiplexing listening instance in the waiting queue of the target QP, so as to determine the waiting thread and notify the waiting thread that it has received the RDMA event notification.
8. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory, wherein the processor, when executing the computer program, implements the method of any one of claims 1-6.
9. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-6.