CN114265713A - Rdma事件管理方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本申请实施例提供一种RDMA事件管理方法、装置、计算机设备及存储介质。在本申请实施例中，在上层应用程序与操作系统内核之间增设一种新的用户态事件管理机制，该用户态事件管理机制通过对多个内核态事件管理实例进行封装，得到面向上层应用程序的用户态事件管理实例，进而由该用户态事件管理实例控制其内包含的不同内核态事件管理实例至少同时对RDMA事件和内核事件进行通知管理，解决两种协议混跑场景下的事件通知兼容问题，可进一步拓展RDMA技术的应用场景，解决RDMA技术面临的应用瓶颈问题。

Description

RDMA事件管理方法、装置、计算机设备及存储介质

技术领域

本申请涉及基于RDMA的网络通信技术领域，尤其涉及一种RDMA事件管理方法、装置、计算机设备及存储介质。

背景技术

远程内存访问(Remote Direct Memory Access，RDMA)协议，凭借其旁路内核的特性，允许应用与网卡之间的直接数据读写，可以将数据直接从一台计算机的内存传输到另一台计算机，无需双方操作系统的介入，规避了传输控制协议/网际协议(TransmissionControl Protocol/Internet Protocol，TCP/IP)协议的限制，能有效降低通讯的时延以及CPU的占用率，被广泛应用于内存数据库、分布式存储、高性能计算等领域。

但是，在实际应用中，存在需要TCP/IP协议和RDMA协议混跑的应用需求，即同一应用既要能够通过TCP/IP协议进行网络传输，也要能够通过RDMA协议进行网络传输。但是，TCP/IP协议与RDMA协议的IO通知机制相差较大，因此很难将RDMA协议的IO通知机制直接整合到现有支持TCP/IP协议的应用架构中，需要对既有架构进行较大的改动，甚至重写应用的IO底座。于是，如何在不改动或较少改动应用架构的基础上，解决TCP/IP协议和RDMA协议混跑场景中的事件通知问题是RDMA领域面临的一大问题。

发明内容

本申请的多个方面提供一种RDMA事件管理方法、装置、计算机设备及存储介质，用以解决TCP/IP协议和RDMA协议混跑场景中的事件通知兼容问题。

本申请实施例提供一种事件管理方法，适用于用户态事件管理机制，用户态事件管理机制位于上层应用程序与操作系统内核之间，且依赖内核态事件管理机制，方法包括：响应上层应用程序发起的实例创建操作，创建与上层应用程序适配的用户态事件管理实例，用户态事件管理实例包括至少两个内核态事件管理实例；响应上层应用程序发起的事件注册操作，在至少两个内核态事件管理实例中的不同内核态事件管理实例中分别注册上层应用程序关注的目标RDMA事件和目标内核事件的信息；响应上层应用程序发起的事件管理操作，采用轮询通知机制与中断通知机制相结合的方式，基于至少两个内核态事件管理实例对目标RDMA事件和目标内核事件进行通知管理。

本申请实施例还提供一种事件管理装置，事件管理装置上运行有用户态事件管理机制，用户态事件管理机制位于上层应用程序与操作系统内核之间，且依赖内核态事件管理机制，事件管理装置包括：创建模块，用于响应上层应用程序发起的实例创建操作，创建与上层应用程序适配的用户态事件管理实例，用户态事件管理实例包括至少两个内核态事件管理实例；注册模块，用于响应上层应用程序发起的事件注册操作，在至少两个内核态事件管理实例中的不同内核态事件管理实例中分别注册上层应用程序关注的目标RDMA事件和目标内核事件的信息；通知管理模块，用于响应上层应用程序发起的事件管理操作，采用轮询通知机制与中断通知机制相结合的方式，基于至少两个内核态事件管理实例对目标RDMA事件和目标内核事件进行通知管理。

本申请实施例还提供一种计算机设备，包括：存储器和处理器，存储器中存储有用户态事件管理机制对应的程序代码，用户态事件管理机制位于上层应用程序与操作系统内核之间，且依赖内核态事件管理机制；处理器与存储器耦合，用于执行用户态事件管理机制对应的程序代码，以用于实现本申请实施提供的事件管理方法中的步骤。

本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，当计算机程序被处理器执行时，致使处理器能够实现本申请实施提供的事件管理方法中的步骤。

在本申请实施例中，在上层应用程序与操作系统内核之间增设一种新的用户态事件管理机制，该用户态事件管理机制通过对多个内核态事件管理实例进行封装，得到面向上层应用程序的用户态事件管理实例，进而由该用户态事件管理实例控制其内包含的不同内核态事件管理实例至少同时对RDMA事件和内核事件进行通知管理，解决两种协议混跑场景下的事件通知兼容问题，可进一步拓展RDMA技术的应用场景，解决RDMA技术面临的应用瓶颈问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请示例性实施例提供的一种事件管理方法的流程示意图；

图2为本申请示例性实施例提供的一种用户态事件管理机制、内核以及内核态事件管理机制形成的软件架构的示意图；

图3为本申请示例性实施例提供的一种用户态事件管理机制的架构图；

图4为本申请示例性实施例提供的一种创建用户态事件管理实例的流程示意图；

图5为本申请示例性实施例提供的一种上层应用程序注册目标RDMA事件和目标内核事件的流程示意图；

图6为本申请示例性实施例提供的一种对目标RDMA事件和目标内核事件进行通知管理的流程示意图；

图7为本申请示例性实施例提供的一种事件通知管理的流程示意图；

图8为本申请示例性实施例提供的一种两级管控结构下，对目标内核事件进行通知管理的示意图；

图9为本申请示例性实施例提供的一种事件管理装置的结构示意图；

图10为本申请示例性实施例提供的一种计算机设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

针对TCP/IP协议和RDMA协议混跑场景中的事件通知问题，在本申请实施例中，在上层应用程序与操作系统内核之间增设一种新的用户态事件管理机制，该用户态事件管理机制通过对多个内核态事件管理实例进行封装，得到面向上层应用程序的用户态事件管理实例，进而由该用户态事件管理实例控制其内包含的不同内核态事件管理实例至少同时对RDMA事件和内核事件进行通知管理，解决两种协议混跑场景下的事件通知兼容问题，可进一步拓展RDMA技术的应用场景，解决RDMA技术面临的应用瓶颈问题。

另外，由于是在上层应用程序和内核之间增加新的用户态事件管理机制，在使用时，对上层应用程序的改动非常小，甚至无需修改。例如，若用户态事件管理机制直接面对上层应用程序，则上层应用程序只需将原本对内核态事件管理实例进行调用的函数名修改为对用户态事件管理实例进行调用的函数名即可，对上层应用程序的改动非常小；如果将用户态事件管理实例进一步封装在已有内核态事件管理实例中，以内核态事件管理实例面对上层应用程序，则上层应用程序甚至无需改动。由此，本申请实施例提供的事件管理方案可以在不改动或较少改动应用架构的基础上，解决TCP/IP协议和RDMA协议混跑场景中的事件通知问题。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1为本申请示例性实施例提供的一种事件管理方法的流程示意图。本申请实施例提供的事件管理方法应用于用户态事件管理机制，用户态事件管理机制是本申请实施例新提出的位于上层应用程序与操作系统内核(也可简称为内核)之间的一种事件管理机制；其中，用户态事件管理机制、操作系统内核以及内核态事件管理机制形成的软件架构如图2所示。内核态事件管理机制提供内核态事件管理实例的创建、注册、删除以及管理等操作。用户态事件管理机制提供对用户态事件管理实例的创建、注册、删除以及管理等操作。在本申请实施例中，用户态事件管理机制依赖内核态事件管理机制，可以对两个或两个以上的(即至少两个)内核态事件管理实例进行封装，得到包含至少两个内核态事件管理实例的用户态事件管理实例，进而该用户态事件管理实例通过其内包含的不同内核态事件管理实例对不同网络传输协议下的IO事件进行通知管理，例如可以通过其内封装的不同内核态事件管理实例至少能够同时对同一上层应用程序在RDMA协议下产生的RDMA事件和在TCP/IP协议下产生的内核事件进行通知管理，从而解决两种协议混跑场景面临的事件管理问题。

另外，本申请实施例的用户态事件管理机制向上面对上层应用程序，面向上层应用程序提供有各种接口函数，使得上层应用程序可以通过这些接口函数使用用户态事件管理机制，具体地，用户态事件管理机制可以响应于上层应用程序发起的实例创建操作实现用户态事件管理实例的创建，可响应于上层应用程序发起的事件注册操作实现对上层应用程序请求关注的目标RDMA事件和目标内核事件在用户态事件管理实例中的注册，以及响应于上层应用程序发起的事件管理操作，实现基于用户态事件管理实例内包含的不同内核态事件管理实例对目标RDMA事件和目标内核事件进行通知管理。

基于上述用户态事件管理机制，如图1所示，本实施例提供的事件管理方法包括以下步骤：

101、响应上层应用程序发起的实例创建操作，创建与上层应用程序适配的用户态事件管理实例，用户态事件管理实例包括至少两个内核态事件管理实例；

102、响应上层应用程序发起的事件注册操作，在至少两个内核态事件管理实例中的不同内核态事件管理实例中分别注册上层应用程序关注的目标RDMA事件和目标内核事件的信息；

103、响应上层应用程序发起的事件管理操作，采用轮询通知机制与中断通知机制相结合的方式，基于至少两个内核态事件管理实例对目标RDMA事件和目标内核事件进行通知管理。

在本实施例中，上层应用程序支持RDMA传输协议，且上层应用程序所在宿主设备具有RDMA设备，RDMA设备是指支持RDMA传输协议的网络接口卡，可简称为RNIC。RDMA事件是指上层应用程序绕过内核直接从用户内存空间访问RDMA设备过程中涉及的各种IO事件，这些IO事件包括读事件和写事件。以上层应用程序通过RDMA设备收发数据的过程为例，上层应用程序通过向RDMA设备的发送队列(SQ)和接收队列(RQ)写入WQE，通知网卡进行数据发送和数据接收，RDMA设备在任务完成后向其完成队列(CQ)写入CQE，通知上层应用程序IO任务完成。根据CQE操作的不同，数据收发过程中涉及的RDMA事件包括两种：若收到发送操作的CQE，则表示写事件；若收到接收操作的CQE，则表示读事件。需要说明的是，RDMA设备和网卡可以集成在同一网络接口设备上实现，也可以作为两个独立的设备实现但相互之间通信连接。

其中，目标RDMA事件是上层应用程序需要关注的RDMA事件，从事件数量来看，上层应用程序关注的目标RDMA事件可以是一个或多个，例如，2个、3个或5个等；另外，从事件类型来看，上层应用程序关注的目标RDMA事件可以仅包括写事件，也可以仅包括读事件，还可以同时包括读事件和写事件；从事件涉及的RDMA设备来看，上层应用程序关注的目标RDMA事件可以来自同一RDMA设备，也可以来自不同的RDMA设备。

在本申请实施例中，上层应用程序同时支持TCP/IP传输协议(即网络传输协议)，且上层应用程序所在宿主设备具有传统网卡设备，上层应用程序可通过传统网卡设备进行基于TCP/IP协议的数据传输。其中，TCP/IP协议属于内核协议栈，故基于TCP/IP协议的数据收发和事件管理是需要经过内核处理的，将基于TCP/IP协议的数据收发过程中涉及的IO事件称为内核事件。简单来说，内核事件是指在数据收发过程中需要经过内核处理的IO事件，内核事件包括写事件或读事件。目标内核事件是上层应用程序需要关注的内核事件，从事件类型的角度来看，上层应用程序关注的目标内核事件可以仅包括写事件，也可以仅包括读事件，还可以同时包括读事件和写事件；从事件数量的角度来看，上层应用程序关注的目标内核事件可以是一个，也可以是多个，例如，2个、3个或5个等。

在本申请实施例中，针对同时支持RDMA协议和TCP/IP协议的上层应用程序，在上层应用程序与操作系统内核之间增设一种新的用户态事件管理机制，上层应用程序需要使用该用户态事件管理机制对其关注的目标RDMA事件和目标内核事件进行管理时，可以向该用户态事件管理机制发起实例创建操作，该用户态事件管理机制可响应上层应用程序发起的实例创建操作，创建与该上层应用程序适配的用户态事件管理实例，由该用户态事件管理实例为上层应用程序提供事件管理服务。其中，该用户态事件管理机制可以对至少两个内核态事件管理实例进行封装，得到面向上层应用程序的用户态事件管理实例，也就是说，本实施例的用户态事件管理实例包括至少两个内核态事件管理实例。

进一步，上层应用程序可以针对该用户态事件管理实例发起事件注册操作，以将上层应用程序关注的目标RDMA事件和目标内核事件注册到与其适配的用户态事件管理实例中；用户态事件管理实例可以响应上层应用程序发出的事件注册操作，在该用户态事件管理实例中包含的不同内核态事件管理实例中分别注册目标RDMA事件和目标内核事件的信息，以便于通过不同的内核态事件管理实例分别对目标RDMA事件和目标内核态事件同时进行通知管理。

其中，并不限定负责管理目标RDMA事件的内核态事件管理实例的数量，也不限定负责管理目标内核事件的内核态事件管理实例的数量。内核态事件管理实例的数量为至少两个，若内核态事件管理实例的数量为两个，则一个内核态事件管理实例用于管理目标RDMA事件，另一个内核态事件管理实例用于管理目标内核事件，若内核态事件管理实例的数量大于两个，则可以使用两个或两个以上的内核态事件管理实例管理目标RDMA事件，相应地，也可以使用两个或两个以上的内核态事件管理实例管理目标内核事件。在事件注册过程中，需要向管理目标RDMA事件的内核态事件管理实例注册目标RDMA事件的信息，向管理目标内核事件的内核态事件管理实例注册目标内核事件的信息。

进一步，在完成事件信息注册的基础上，上层应用程序还可以发起事件管理操作，以触发与其适配的用户态事件管理实例对其关注的目标RDMA事件和目标内核事件进行通知管理。相应地，用户态事件管理实例可响应上层应用程序发起的事件管理操作，对上层应用程序向其注册的目标RDMA事件和目标内核事件进行通知管理。在本实施例中，用户态事件管理具体采用轮询通知机制与中断通知机制相结合的方式，对两种协议下的事件进行通知管理，因此，与上层应用程序适配的用户态事件管理实例具体采用轮询通知机制与中断通知机制相结合的方式，基于其内包含的至少两个内核态事件管理实例对目标RDMA事件和目标内核事件进行通知管理，解决两种协议混跑场景下的事件通知兼容问题，可进一步拓展RDMA技术的应用场景，解决了RDMA技术面临的应用瓶颈问题。

另外，从上述过程可知，对上层应用程序来说，只是改变了发起实例创建、事件注册以及事件管理的对象，上述过程并不涉及上层应用程序的IO处理逻辑，也就是说上层应用程序的IO处理逻辑并不受影响，对上层应用程序的改动非常小，只需将原本对内核态事件管理实例进行调用的函数名修改为对用户态事件管理实例进行调用的函数名即可。进一步，用轮询通知机制与中断通知机制相结合的方式，对目标RDMA事件和目标内核事件进行通知管理，一方面轮询通知机制可以提高事件通知的低时延特性，另一方面采用中断通知机制可以减少CPU的占用率，综合使用两种可以提供低时延和低CPU占用的综合优势。

在本申请实施例中，并不限定用户态事件管理机制所实现的用户态事件管理实例的软件架构，凡是能够实现图1所示方法实施例中的各操作的软件架构均适用于本申请实施例。在一可选实施例中，本申请实施例提供的用户态事件管理机制可以实现如图3所示架构的用户态事件管理实例。

如图3所示，与上层应用程序适配的用户态事件管理实例包括第一内核态事件管理实例和第二内核态事件管理实例；其中，第一内核态事件管理实例是负责管理上层应用程序关注的目标RDMA事件的内核态事件管理实例，第二内核态事件管理实例是指负责管理上层应用程序关注的目标内核事件的内核态事件管理实例。需要说明的是，本申请实施例并不限定内核态事件管理实例的实现，可视内核所属操作系统的类型而定。内核所属操作系统可以是Unix系统或Lunix系统。在内核所属操作系统为Lunix系统的情况下，内核态事件管理实例可以是epoll实例，为便于描述和区分，可以将第一内核态事件管理实例称为pub_epoll，将第二内核态事件管理实例称为kn_epoll，并将与上层应用程序适配的用户态事件管理实例称为类epoll实例，记为Repoll，如图3所示。

进一步，本实施例的用户态事件管理实例除了包括第一内核态事件管理实例和第二内核态事件管理实例之外，还包括：设备上下文管理区，如图3所示。该设备上下文管理区用于承载上层应用程序所在宿主设备上各RDMA设备在建立第一类RDMA连接时所需的共享CC资源和共享CQ资源。

在本实施例中，上层应用程序所在宿主设备上可能包含至少一台RDMA设备，上层应用程序有可能使用任何RDMA设备与其它网络设备进行数据传输。上层应用程序在使用各RDMA设备与其它网络设备进行数据传输时需要建立RDMA连接，并需要创建RDMA连接需要使用队列对(Queue Pairs，QP)资源、就绪通知通道(Completion Channel，CC)资源和任务完成队列(Completion Queue，CQ)资源等各种队列资源。其中，QP包括SQ和RQ，SQ用于存储上层应用程序写入的表示发送任务的WQE，RQ用于存储上层应用程序写入的表示接收任务的WQE；CC资源用于监测该CC资源对应的RDMA连接在完成IO任务(该IO任务包括发送任务和接收任务)时产生的中断事件，CQ资源用于存储RDMA连接在完成IO任务时产生的完成队列元素(Completion Queue Element，CQE)消息。其中，可以通过CC通知方式让上层应用程序感知到IO任务完成事件，也可以通过轮训CQ的方式让上层应用程序感知到IO任务完成事件。

其中，RDMA连接对CC资源和CQ资源的使用方式包括两种，一种是共享使用方式，即多个RDMA连接共享CC资源和CQ资源，另一种是独占使用方式，即一个RDMA连接独占CC资源和CQ资源。基于此，在本实施例中，将RDMA连接划分为两类，即第一类RDMA连接和第二类RDMA连接。其中，第一类RDMA连接是指需要多个RDMA连接复用同一共享CC资源或共享CQ资源的一类RDMA连接。第二类RDMA连接是指在对应的RDMA设备上具有独占CC资源和独占CQ资源的一类RDMA连接。在本实施例中，为了便于描述和区分，将可以被多个RDMA连接复用的CC资源或CQ资源分别称为共享CC资源或共享CQ资源；将一个RDMA连接独占的CC资源或CQ资源称为独占CC资源或独占CQ资源。

在实际使用中，具体建立哪类RDMA连接，由上层应用程序根据应用需求而定。也就是说，在上层应用程序使用RDMA设备进行数据传输之前，RDMA设备并不确定上层应用程序会建立哪种RDMA连接，可能是第一类RDMA连接，也可能是第二类RDMA连接。为了便于在这两类中任一类RDMA连接出现时都能对其涉及的目标RDMA事件进行通知管理，在本申请实施例中，在为上层应用程序创建与其适配的用户态事件管理实例时，在该用户态事件管理实例中增设设备上下文管理区，如图3所示。在该设备上下文管理区中预先创建上层应用程序所在宿主设备上各RDMA设备在建立第一类RDMA连接时所需的共享CC资源和共享CQ资源，这样上层应用程序在实际应用中建立第一类RDMA连接提供CC和CQ资源条件。可选地，对同一RDMA设备来说，其上各第一类RDMA连接复用同一共享CC资源，该CC资源，用于监测共享该CC资源的多个第一类RDMA连接在完成IO任务时产生的中断事件；对同一RDMA设备来说，不同第一类RDMA连接可共享CQ资源，该CQ资源用于存储共享CQ资源的多个第一类RDMA连接在完成IO任务时产生的CQE消息。例如，RDMA设备需要建立1000个第一类RDMA连接，CQ资源的数量为10，则每个CQ资源的对列深度为100，则每个CQ资源可被100个第一类RDMA连接共享。

基于图3所示用户态事件管理实例的实现结构，如图4所示，步骤101，即创建用户态事件管理实例的一种实现过程包括：

1011、响应上层应用程序发起的实例创建操作，创建第一内核态事件管理实例和第二内核态事件管理实例，第一内核态事件管理实例用于管理上层应用程序关注的目标RDMA事件，第二内核态事件管理实例用于管理上层应用程序关注的目标内核事件；

1012、创建设备上下文管理区，该设备上下文管理区用于承载上层应用程序所在宿主设备上各RDMA设备在建立第一类RDMA连接时所需的共享CC资源和共享CQ资源。

在本实施例中，用户态事件管理机制对外提供用户态的实例创建函数，上层应用程序可调用该用户态的实例创建函数以发起实例创建操作，用户态事件管理机制可响应上层应用程序对该用户态的实例创建函数发起的调用请求，执行创建与上层应用程序适配的用户态事件管理实例的操作，即上述步骤1011和1012描述的操作，得到与上层应用程序适配的用户态事件管理实例。

进一步，在创建用户态事件管理实例时，还可以为第一内核态事件管理实例和第二内核态事件管理实例分配内核态的标识信息，并将第一内核态事件管理实例的内核态的标识信息作为用户态事件管理实例的全局标识信息返回给上层应用程序，以供上层应用程序基于该全局标识信息向用户态事件管理实例发起事件注册操作和事件管理操作。进一步，在内核所属的操作系统为Lunix或Unix系统的情况下，内核态的标识信息为文件描述符(File Descriptor，FD)。进一步可选地，还可以将第二内核态事件管理实例的内核态的标识信息注册到第一内核态事件管理实例中，以形成两级管理结构。在第二内核态事件管理实例的内核态的标识信息为FD的情况下，具体是指将第二内核态事件管理实例的FD注册到第一内核态事件管理实例中。关于内核态事件同步实例的详细内容可参见后续实施例，在此暂不详述。

进一步可选地，本实施例的用户态事件管理机制还支持嵌套注册机制，嵌套注册机制是指允许将用户态事件管理实例嵌套注册至其它内核态事件管理实例或其它用户态事件管理实例中的机制。基于此，在本实施例中，还可以将与上层应用程序适配的用户态事件管理实例嵌套注册至第三内核态事件管理实例中，将第三内核态事件管理实例的内核态的标识信息返回给上层应用程序，后续上层应用程序可基于该第三内核态事件管理实例的内核态的标识信息向第三内核态事件管理实例中嵌套的用户态事件管理实例发起事件注册和事件管理等操作，以实现基于内部嵌套用户态事件管理实例的第三内核态事件管理实例进行通知管理；或者，也可以将与上层应用程序适配的用户态事件管理实例嵌套注册至另一用户态事件管理实例中，将另一用户态事件管理实例的内核态的标识信息返回给上层应用程序，后续上层应用程序可基于该另一用户态事件管理实例的标识信息向另一用户态事件管理实例中嵌套的与上层应用程序适配的用户态事件管理实例发起事件注册和事件管理等操作，以实现基于内部嵌套与上层应用程序适配的用户态事件管理实例的另一用户态事件管理实例进行通知管理。其中，用户态事件管理实例与另一用户态事件管理实例或内核态事件管理实例之间的嵌套关系，如图3所示。

进一步，结合图3所示的用户态事件管理实例的架构，如图5所示，上述步骤102，即上层应用程序注册目标RDMA事件和目标内核事件的一种实现过程包括：

1021、响应上层应用程序发起的事件注册操作，获取上层应用程序关注的事件的描述信息，事件的描述信息包括事件的标识信息和事件的读写类型；

1022、若上层应用程序关注的事件中包括目标内核事件，则调用内核态的注册函数，将目标内核事件的描述信息注册到第二内核态事件管理实例中；

1023、若上层应用程序关注的事件中包括目标RDMA事件，则调用内核态的注册函数，将目标RDMA事件的描述信息注册到第一内核态事件管理实例中。

在本实施例中，上层应用程序可以发起一次事件注册操作，将目标内核事件的描述信息注册到第二内核态事件管理实例中，同时将目标RDMA事件的描述信息注册到第一内核态事件管理实例中；或者，上层应用程序也可以针对目标RDMA事件单独发起事件注册操作，将目标RDMA事件的描述信息注册到第一内核态事件管理实例中，进一步，在目标RDMA事件的数量为多个的情况下，上层应用程序可以针对多个目标RDMA事件发起多次事件注册操作，或者上层应用程序可以针对该多个目标RDMA事件发起一次事件注册操作。相应地，上层应用程序可以针对目标内核事件单独发起事件注册操作，将目标内核事件的描述信息注册到第二内核态事件管理实例中，进一步，在目标内核事件的数量为多个的情况下，上层应用程序可以针对该多个目标内核事件发起多次事件注册操作，或者上层应用程序可以针对该多个目标内核事件发起一次事件注册操作。

在本实施例中，响应上层应用程序发起的事件注册操作，获取上层应用程序请求注册其所关注的事件的描述信息，事件的描述信息中至少包括事件的标识信息和事件的读写类型，事件的标识信息主要是指内核态的标识信息，例如可以是事件所属的FD；其中，事件的描述信息可以表示事件的类别，具体地，事件的标识信息可表示事件的类别，在本实施例中事件类别包括内核事件、RDMA事件以及外部事件。

基于此，在获取上层应用程序关注的事件的描述信息之后，可基于该描述信息，识别上层应用程序关注的事件类别；若该事件类别指向上层应用程序关注的目标内核事件，则调用内核态的注册函数，将目标内核事件的描述信息注册到第二内核态事件管理实例中；若该事件类别指向上层应用程序关注的目标RDMA事件，则调用内核态的注册函数，将目标RDMA事件的描述信息注册到第一内核态事件管理实例中。无论是将目标内核事件的描述信息注册到第二内核态事件管理实例中，还是将目标RDMA事件的描述信息注册到第一内核态事件管理实例中，在注册之后，可以对事件的标识信息进行标记，以通过事件的标识信息标记不同事件类别。进一步，在上层应用程序所在宿主设备的操作系统实现为Lunix或Unix操作系统的情况下，为事件的标识信息具体为事件的FD。相应地，可以通过对事件的FD进行置位的方式，标记不同事件类别。

进一步，用户态事件管理机制对外提供用户态的事件注册函数，在上层应用程序所属宿主设备的操作系统为Lunix或Unix系统的情况下，用户态的事件注册函数可以表示为Repoll_ctl()。上层应用程序可调用该事件注册函数以发起事件注册操作，与上层应用程序适配的用户态事件管理实例可响应上层应用程序对用户态的事件注册函数发起的调用请求，执行在至少两个内核态事件管理实例中的不同内核态事件管理实例中分别注册上层应用程序关注的目标RDMA事件和目标内核事件的信息的操作，即上述步骤1021-1023描述的操作。

在本实施例中，上层应用程序关注的目标内核事件可以包括读类型的内核事件，也可以包括写类型的内核事件，还可以同时包括读类型的内核事件和写类型的内核事件读类型；相应地，上层应用程序关注的目标RDMA事件可以包括读类型的RDMA事件，也可以包括写类型的RDMA事件，还可以同时包括读类型的RDMA事件和写类型的RDMA事件。举例说明，如图3所示，上层应用程序关注的目标内核事件包含但不限于：套接字(Socket)事件、文件(File)事件、信号(Signal)事件，事件通知(event)事件，这些事件的内核态的标识信息被记录在第二内核态事件管理实例负责管理内核资源区中，具体为：SocketFD、FileFD、SignalFD以及EventFD。

在本实施例中，目标RDMA事件包括以下至少一种：属于第一类RDMA连接的目标CC事件、属于第二类RDMA连接的目标CC事件以及属于第一类RDMA连接的目标IO任务完成事件。其中，IO任务完成事件是一种在轮询通知机制下，RDMA设备通知上层应用程序IO任务完成的事件，又称为CQ事件；CC事件是指在中断通知机制下，RDMA设备通知上层应用程序IO任务的就绪通知的事件；上层应用程序可以关注部分或全部的IO任务完成事件，也可以关注部分或全部的CC事件，为了便于区分和描述，将上层应用程序关注的IO任务完成事件称为目标IO任务完成事件，将上层应用程序关注的CC事件称为目标CC事件。

在本实施例中，用户态事件管理实例为了监测多块RDMA设备的IO任务完成事件，在用户态事件管理实例内部设置有设备上下文管理区，该设备上下文管理区可以在用户态事件管理实例初始化或者用户态事件管理实例有需要时，检测当前宿主设备中安装的RDMA设备，并保存RDMA设备的上下文信息，为了便于保存不同RDMA设备的上下文信息，可在该设备上下文管理区中为每个RDMA设备设置上下文条目，每个上下文条目包括对应RDMA设备所需的共享CC资源和共享CQ资源，除此之外，上下文条目中还会包括对应RDMA设备的IP地址、ID等标识性信息。

在本实施例中，针对不同类别的RDMA连接，上层应用程序注册其所关注的目标RDMA事件的方式也不相同。下面详细说明。

针对第一类RDMA连接，在创建第一类RDNA连接时，在RDMA设备的RDMA连接资源区上创建QP资源，如图3所示；并且需要从RDMA设备的上下文条目中选择合适的共享CQ资源，建立共享CQ资源与QP资源之间的关联关系，以使RDMA设备在QP资源中IO任务完成后，向与该QP资源关联的共享CQ资源中写入CQE消息，表示IO任务完成。基于此，在本申请一些可选实施例中，在上层应用程序关注的目标RDMA事件包括属于第一类RDMA连接的目标IO任务完成事件的情况下，在将目标RDMA事件的描述信息注册到第一内核态事件管理实例中之前，可响应上层应用程序发起的关联操作，获取目标IO任务完成事件所属目标RDMA连接的IP地址，目标IO任务完成事件所属目标RDMA连接属于第一类RDMA连接，该IP地址指向目标RDMA设备，根据该IP地址在设备上下文管理区中确定与目标IO任务完成事件对应的目标共享CQ资源；将目标共享CQ资源的信息通知与目标RDMA连接适配的目标RDMA设备，以使目标RDMA设备将目标RDMA连接对应的CQE消息写入目标共享CQ资源中，从而建立目标RDMA设备中QP与共享CQ资源之间的关联关系，在此之后，可以调用内核态的注册函数，将目标IO任务完成事件的描述信息注册到第一内核态事件管理实例中。其中，在内核所属操作系统实现为Linux或Unix系统的情况下，内核态的注册函数表示为epoll_ctl()。

可选地，上下文条目中包括一个共享CC和一组共享CQ资源，该组中共享CQ资源中CQ的数量可随QP资源规模的变化而变化，从而实现CQ资源数量的动态扩展，另外，因为支持CQ资源数量的动态扩展，所以每个CQ资源的队列深度不用太大，在CQ资源不足的时候，可以随时扩展新的CQ资源，满足RDMA连接对CQ资源的需求。而且，相较于RDMA设备采用重设CQ资源数量ibv_resize_cq()函数一次性申请固定数量的CQ资源的方式，使用需求动态扩展CQ资源数量的方式，可节约CQ资源占用的内存空间，提高存储空间的资源利用率。基于此，上述在设备上下文管理区中确定与目标IO任务完成事件对应的目标共享CQ资源的实施方式，包括：根据目标IO任务完成事件所属目标RDMA连接的IP地址，在设备上下文管理区中进行查找目标RDMA设备的上下文条目；判断该上下文条目中是否存在空闲的共享CQ资源；在该上下文条目中不存在空闲的共享CQ资源的情况下，创建新的共享CQ资源，并将新的共享CQ资源作为与目标IO任务完成事件对应的目标共享CQ资源，以便建立目标共享CQ资源与对应QP资源之间的关联关系。而且，本实施例的动态扩展CQ资源数量的方式，不依赖于ibv_resize_cq()函数，可解决RDMA设备受ibv_resize_cq()函数限制的问题，支持各厂商的RDMA设备，具有较好的设备兼容性。

针对第二类RDMA连接，RDMA设备上的RDMA资源连接区中包含第二类RDAM连接所需的完整QP资源、独占CQ资源以及独占CC资源，相较于第一类RDMA连接，操作约束更小，无需依赖用户态事件管理实例即可完成目标CC事件的消息收发。需要说明的是，在图3中仅对RDMA设备上的RDMA连接资源区进行了图示，关于RDMA设备上实现其它功能的部分，并未在图3中展示。在上层应用程序关注的目标RDMA事件包括属于第二类RDMA连接的目标CC事件的情况下，在对第二类RDMA连接的目标CC事件进行事件注册时，可直接将该目标CC事件的描述信息注册到第一内核态事件管理实例中，进一步还可以目标CC事件的描述信息中的标识信息进行标记，以区分不同的事件类别。例如，在Lunix操作系统下，可以对目标CC事件的FD进行置位，例如将最高两位置为1，从而表示是上层应用程序关注的目标RDMA事件。

进一步，结合图3所示的用户态事件管理实例架构，如图6所示，步骤103，即上述对目标RDMA事件和目标内核事件进行通知管理的一种实现过程包括：

1031、响应上层应用程序发起的事件管理操作，进入忙轮询阶段，对设备上下文管理区中的共享CQ资源进行忙轮询，以对目标RDMA事件中属于第一类RDMA连接的目标IO任务完成事件进行通知管理；

1032、若在设定的忙轮询耗时内未轮询到任何目标IO任务完成事件，进入事件等待阶段，基于第一内核态事件管理实例和第二内核态事件管理实例分别对目标RDMA事件中的目标CC事件和目标内核事件进行通知管理，目标CC事件属于第一类RDMA连接和/或第二类RDMA连接。

在本实施例中，目标IO任务完成事件是第一类RDMA连接涉及的事件中被上层应用程序注册并关注的IO任务完成事件，上层应用程序关注的IO任务完成事件可能只包含读操作对应的IO任务完成事件或写操作对应的IO任务完成事件，或者，同时包含读操作或写操作的IO任务完成事件。目标IO任务完成事件属于上层应用程序注册的目标RDMA事件。

进一步，用户态事件管理机制对外提供用户态的等待函数，在上层应用程序所属宿主设备的操作系统为Linux或Unix的情况下，用户态的等待函数可表示为Repoll wait()。上层应用程序可调用该用户态的等待函数以发起事件管理操作，则与上层应用程序适配的用户态事件管理实例可响应上层应用程序对用户态的等待函数发起的调用请求，采用轮询通知机制与中断通知机制相结合的方式，基于至少两个内核态事件管理实例对目标RDMA事件和目标内核事件进行通知管理。具体地，采用轮询通知机制基于至少两个内核态事件管理实例对目标RDMA事件和目标内核事件进行通知管理，对应于步骤1031描述的过程，采用中断通知机制基于至少两个内核态事件管理实例对目标RDMA事件和目标内核事件进行通知管理，对应于步骤1032描述的过程。

针对步骤1031，在忙轮询阶段中，可按序对用户态事件管理实例中的设备上下文管理区中的所有上下文条目进行遍历，对上文条目中的CQ资源进行逐一轮询，检测CQ资源中是否存在CQE消息，例如，通过调用ibv_poll_cq()函数，获取RDMA设备上已经完成的IO请求，直至轮询到IO任务完成事件，或者在本次轮询耗时超过设定的忙轮询耗时的情况下，停止忙轮询，进入事件等待阶段。若在设定的忙轮询耗时内轮询到共享CQ资源中的CQE消息，则从上层应用程序注册且关注的目标IO任务完成事件中匹配CQE消息对应的IO任务完成事件。具体地，CQE消息中包括事件的标识信息和事件的读写类型，将CQE消息中包括的事件的标识信息和读写类型与目标IO任务完成事件的标识信息和读写类型进行匹配。若CQE消息中事件的标识信息和读写类型匹配中目标IO任务完成事件中的标识信息和读写类型，则认为目标IO任务完成事件中包括CQE消息对应的IO任务完成事件。在目标IO任务完成事件中匹配到CQE消息对应的IO任务完成事件的情况下，向上层应用程序返回CQE消息对应的IO任务完成事件的描述信息，以供上层应用程序对CQE消息对应的IO任务完成事件进行处理。

在一可选实施例中，在上层应用程序发起事件管理操作的情况下，可以根据是否注册了目标IO任务完成事件来决定是否进入忙轮询阶段。具体地，在上层应用程序发起事件管理操作的情况下，响应上层应用程序发起的事件管理操作，判断上层应用程序是否注册了目标IO任务完成事件；在上层应用程序注册了目标IO任务完成事件的情况下，进入忙轮询阶段；在上层应用程序未注册目标IO任务完成事件的情况下，跳过忙轮询阶段，直接进入事件等待阶段。

在一可选实施例中，若在设定的忙轮询耗时内未轮询到任何目标IO任务完成事件，进入事件等待阶段，基于第一内核态事件管理实例和第二内核态事件管理实例分别对目标RDMA事件中的目标CC事件和目标内核事件进行通知管理的实施方式，包括：若在设定的忙轮询耗时内未轮询到任何目标IO任务完成事件，则在设定的忙轮询耗时结束时，调用内核态的等待函数以进入等待阶段，以供第一内核态事件管理实例和第二内核态事件管理实例分别在设定的等待时长内监测是否有相应事件发生；在第一内核态事件管理实例在设定的等待时长内监测到第一目标CC事件的情况下，向上层应用程序返回第一目标CC事件的描述信息，以供上层应用程序对第一目标CC事件进行处理，或者在第二内核态事件管理实例在设定的等待时长内监测到第一目标内核事件发生的情况下，向上层应用程序返回第一目标内核事件的描述信息，以供上层应用程序对第一目标内核事件进行处理。其中，设定的等待时长可以是但不限于：60us、50ms、30s或2min等。

进一步，如图3所示的用户态事件管理实例架构，还包括：将共享CC资源的标识信息与第二内核态事件管理实例的标识信息分别注册到第一内核态事件管理实例中，以形成两级管理结构。其中，共享CC资源或第二内核态事件管理实例在监测到相应事件发生时可将第一内核态事件管理实例唤醒，第一内核态事件管理实例向上层应用程序返回第一目标CC事件或第一目标内核事件的描述信息，以供上层应用程序对第一目标CC事件或第一目标内核事件进行处理。

在此基础上，上述事件通知管理的详细实施过程如图7所示，包括：在TCP和RDMA混跑场景中，上层应用程序发起事件管理操作之后，可响应于上层应用程序发起的事件管理操作，进入忙轮询阶段，并统计忙轮询的当前耗时，并判断该耗时是否超过设定的忙轮询耗时。若当前忙轮询耗时超过设定的忙轮询耗时，则将当前忙轮询耗时清零，进入事件等待阶段，并更新设定的忙轮询耗时；若当前忙轮询耗时未超过设定的忙轮询耗时，则对目标RDMA时间进行忙轮询，并不断更新忙轮询的当前耗时，并判断是否轮询到目标IO任务完成事件。若轮询到目标IO任务完成事件，则更新忙轮询耗时，对目标IO任务完成事件进行通知管理；若未轮询到目标IO任务完成事件，则判断当前耗时是否超过设定的忙轮询耗时。若当前耗时未超过设定的忙轮询耗时，则继续对目标RDMA事件进行忙轮询；若当前耗时超过设定的忙轮询耗时，则进入事件等待阶段，并更新设定的忙轮询耗时。

在一可选实施例中，在上述两级管控结构下，对目标内核事件进行通知管理的实施方式，包括：若在设定的忙轮询耗时内未轮询到任何目标IO任务完成事件，针对用户态事件管理实例调用用户态的等待函数以进入事件等待阶段，如图8中的步骤①所示，用户态的等待函数表示为Repoll_wait。在用户态事件管理实例内部，针对第一内核态事件管理实例调用内核态的等待函数以进入等待阶段，如图8中的步骤②所示，内核态的等待函数表示为epoll_wait(pub_epoll)。如图8中的步骤③所示，若第二内核态事件管理实例在设定的等待时长内监测到第一目标内核事件发生，则向第一内核态事件管理实例发送第一事件通知，以唤醒第一内核态事件管理实例，如图8中的步骤④所示，第一事件通知为kn_epoll事件发生。第一内核态事件管理实例向用户态事件管理实例的主控单元返回epoll_wait结果，即第一目标内核事件发生的通知，如图8中的步骤⑤所示。用户态事件管理实例再次针对第二内核态事件管理实例调用内核态的等待函数，以获取第二内核态事件管理实例监测到的第一目标内核事件的描述信息，如图8中的步骤⑥所示，主控单元针对kn_epoll调用内核态的等待函数epoll_wait，步骤⑥表示为epoll_wait(kn_epoll)，并返回epoll_wait函数的调用结果，如图8中的步骤⑦所示。用户态事件管理实例的主控单元向上层应用程序返回发生的第一目标内核事件的描述信息，以供上层应用程序对第一目标内核事件进行处理，如图8中的步骤⑧所示。在图8中，以内核态事件管理实例是lunix操作系统下的epoll实例为例，并将本申请实施例提供的用户态事件管理实例即为类epoll实例，简称为Repoll。

在一可选实施例中，如图3所示的用户态事件管理实例架构，在创建与上层应用程序适配的用户态事件管理实例，除了可以创建第一内核态事件管理实例和第二内核态事件管理实例之外，还可以创建负责监听外部事件的内核态事件同步实例，内核态事件同步实例用于在事件等待阶段监听到外部事件，在监听到外部事件发生时，向第一内核态事件管理实例发送第二事件通知，以唤醒第一内核态事件管理实例，避免第一内核态事件管理实例一直处于事件等待阶段。

具体地，用户态事件管理机制响应上层应用程序发起的实例创建操作，创建负责监听外部事件的内核态事件同步实例，并将内核态事件同步实例注册到第一内核态事件管理实例中。其中，外部事件是指上层应用程序之外的事件，在上层应用程序所属宿主设备的操作系统实现为Linux或Unix的情况下，内核态事件同步实例可表示为(eventfd)。在事件等待阶段，若内核态事件同步实例在设定的等待时长内监测到外部事件发生，则向第一内核态事件管理实例发送第二事件通知，以唤醒第一内核态事件管理实例。除此之外，内核态事件同步实例还对外提供外部事件对应事件源注册的事件处理函数，第一内核态事件管理实例可针对内核态事件同步实例调用该事件处理函数，以对外部事件进行处理。

在本实施例中，采用轮询通知机制与中断通知机制相结合的方式，基于第一内核态事件管理实例和第二内核态事件管理实例，对目标RDMA事件和目标内核事件进行通知管理，主要涉及如下过程：

响应上层应用程序发起的事件管理操作，进入忙轮询阶段，在忙轮询阶段遍历用户态事件管理实例对设备上下文管理区中的所有上下文条目进行遍历，逐一轮询上下文条目中的共享CQ资源，若监测到共享CQ资源写入了CQE消息，则认为有第一类RDMA连接的IO任务完成事件发生，并在目标IO任务完成事件中匹配到该CQE消息对应的IO任务完成事件，将该IO任务完成事件描述信息返回给上层应用程序，以供上层应用程序对CQE消息对应的IO任务完成事件进行处理，并从忙轮询阶段进入事件等待阶段。若在设定的忙轮询耗时内，未轮询到CQE消息，则从忙轮询阶段进入事件等待阶段。

在事件等待阶段，通过调用用户态的等待函数(Repoll_wait)获取第一内核态事件管理实例(pub_epoll)的就绪事件，根据不同事件的标识信息，分别做如下处理，确定就绪事件的事件类型，并就绪事件的描述信息返回给上层应用程序。

若就绪事件为第二内核态事件管理实例(kn_epoll)返回的就绪事件，则表示当前用户态事件管理实例中存在就绪的内核事件，需对其调用内核态的等待函数epoll_wait()，进一步确定哪一种内核事件就绪。详细过程可参见图8所示的实施方式，在此不再赘述。

若就绪事件为内核态事件同步实例的就绪事件，表示外部事件唤醒用户态事件管理实例，需调用对应事件源注册的事件处理函数；

若就绪事件为第一类RDMA连接或第二类RDMA连接的就绪事件，即检测到第一目标CC事件发生，在第一内核态事件管理实例在设定的等待时长内监测到第一目标CC事件的情况下，向上层应用程序返回第一目标CC事件的描述信息，以供上层应用程序对第一目标CC事件进行处理。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤101至步骤103的执行主体可以为设备A；又比如，步骤101和102的执行主体可以为设备A，步骤103的执行主体可以为设备B；等等。

另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如101、102等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

图9为本申请示例性实施例提供的一种事件管理装置的结构示意图，该事件管理装置上运行有用户态事件管理机制，用户态事件管理机制位于上层应用程序与操作系统内核之间，且依赖内核态事件管理机制，如图9所示，该事件管理装置包括：创建模块91、注册模块92以及通知管理模块93。

创建模块91，用于响应上层应用程序发起的实例创建操作，创建与上层应用程序适配的用户态事件管理实例，用户态事件管理实例包括至少两个内核态事件管理实例；

第一注册模块92，用于响应上层应用程序发起的事件注册操作，在至少两个内核态事件管理实例中的不同内核态事件管理实例中分别注册上层应用程序关注的目标RDMA事件和目标内核事件的信息；

通知管理模块93，用于响应上层应用程序发起的事件管理操作，采用轮询通知机制与中断通知机制相结合的方式，基于至少两个内核态事件管理实例对目标RDMA事件和目标内核事件进行通知管理。

在一可选实施例中，创建模块91具体用于：响应上层应用程序发起的实例创建操作，创建第一内核态事件管理实例和第二内核态事件管理实例，并创建设备上下文管理区，设备上下文管理区用于承载上层应用程序所在宿主设备上各RDMA设备在建立第一类RDMA连接时所需的共享CC资源和共享CQ资源；其中，第一类RDMA连接是指多个RDMA连接复用同一共享CC资源或共享CQ资源的一类RDMA连接，第一内核态事件管理实例用于管理上层应用程序关注的目标RDMA事件，第二内核态事件管理实例用于管理上层应用程序关注的目标内核事件。

在一可选实施例中，事件管理装置还包括：分配模块和第一返回模块；分配模块，用于为第一内核态事件管理实例和第二内核态事件管理实例分配文件描述符FD；第一返回模块，用于将第一内核态事件管理实例的FD作为用户态事件管理实例的全局FD返回给上层应用程序，以供上层应用程序基于全局FD向用户态事件管理实例发起事件注册操作和事件管理操作。

在一可选实施例中，第一注册模块92具体用于：响应上层应用程序发起的事件注册操作，获取上层应用程序关注的事件的描述信息，事件的描述信息包括事件的标识信息和事件的读写类型；若上层应用程序关注的事件中包括目标内核事件，则调用内核态的注册函数，将目标内核事件的描述信息注册到第二内核态事件管理实例中；若上层应用程序关注的事件中包括目标RDMA事件，则调用内核态的注册函数，将目标RDMA事件的描述信息注册到第一内核态事件管理实例中。

在一可选实施例中，事件管理装置还包括：获取模块、确定模块和通知模块；在目标RDMA事件包括属于第一类RDMA连接的目标IO任务完成事件的情况下，在将目标RDMA事件的描述信息注册到第一内核态事件管理实例中之前，获取模块，用于响应上层应用程序发起的关联操作，获取目标IO任务完成事件所属目标RDMA连接的IP地址；确定模块，用于根据IP地址在设备上下文管理区中确定与目标IO任务完成事件对应的目标共享CQ资源；通知模块，用于将目标共享CQ资源的信息通知与目标RDMA连接适配的目标RDMA设备，以使目标RDMA设备将目标RDMA连接的CQE消息写入目标共享CQ资源中。

在一可选实施例中，确定模块具体用于：根据IP地址在设备上下文管理区中进行查找目标RDMA设备的上下文条目；在上下文条目中不存在空闲的共享CQ资源的情况下，创建新的共享CQ资源，并将新的共享CQ资源作为与目标IO任务完成事件对应的目标共享CQ资源。

在一可选实施例中，通知管理模块93具体用于：响应上层应用程序发起的事件管理操作，进入忙轮询阶段，对设备上下文管理区中的共享CQ资源进行忙轮询，以对目标RDMA事件中属于第一类RDMA连接的目标IO任务完成事件进行通知管理；若在设定的忙轮询耗时内未轮询到任何目标IO任务完成事件，进入事件等待阶段，基于第一内核态事件管理实例和第二内核态事件管理实例分别对目标RDMA事件中的目标CC事件和目标内核事件进行通知管理，目标CC事件属于第一类RDMA连接和/或第二类RDMA连接。

在一可选实施例中，通知管理模块93具体用于：若在设定的忙轮询耗时内轮询到CQE消息，且在目标IO任务完成事件中匹配到CQE消息对应的IO任务完成事件，则向上层应用程序返回CQE消息对应的IO任务完成事件的描述信息，以供上层应用程序对CQE消息对应的IO任务完成事件进行处理。

在一可选实施例中，通知管理模块93具体用于：响应上层应用程序发起的事件管理操作，判断上层应用程序是否注册了目标IO任务完成事件；在上层应用程序注册了目标IO任务完成事件的情况下，进入忙轮询阶段；在上层应用程序未注册目标IO任务完成事件的情况下，跳过忙轮询阶段，直接进入事件等待阶段。

在一可选实施例中，通知管理模块93具体用于：若在设定的忙轮询耗时内未轮询到任何目标IO任务完成事件，则在设定的忙轮询耗时结束时，调用内核态的等待函数以进入等待阶段，以供第一内核态事件管理实例和第二内核态事件管理实例分别在设定的等待时长内监测是否有相应事件发生；在第一内核态事件管理实例或第二内核态事件管理实例在设定的等待时长内监测到第一目标CC事件或第一目标内核事件发生的情况下，向上层应用程序返回第一目标CC事件或第一目标内核事件的描述信息，以供上层应用程序对第一目标CC事件或第一目标内核事件进行处理。

在一可选实施例中，事件管理装置还包括：第二注册模块；第二注册模块，用于将共享CC资源的标识信息与第二内核态事件管理实例的标识信息分别注册到第一内核态事件管理实例中，以形成两级管理结构；其中，共享CC资源或第二内核态事件管理实例在监测到相应事件发生时可将第一内核态事件管理实例唤醒。

在一可选实施例中，通知管理模块93具体用于：在设定的忙轮询耗时结束时，针对第一内核态事件管理实例调用内核态的等待函数以进入等待阶段；以及若第二内核态事件管理实例在设定的等待时长内监测到第一目标内核事件发生，则向第一内核态事件管理实例发送第一事件通知，以唤醒第一内核态事件管理实例；再次针对第二内核态事件管理实例调用内核态的等待函数，以获取第二内核态事件管理实例监测到的第一目标内核事件的描述信息；向上层应用程序返回发生的第一目标内核事件的描述信息，以供上层应用程序对第一目标内核事件进行处理。

在一可选实施例中，创建模块91还用于：创建负责监听外部事件的内核态事件同步实例，并将内核态事件同步实例注册到第一内核态事件管理实例中，外部事件是指上层应用程序之外的事件；事件管理装置还包括：发送模块和调用模块；发送模块，用于在事件等待阶段，若内核态事件同步实例在设定的等待时长内监测到外部事件发生，则向第一内核态事件管理实例发送第二事件通知，以唤醒第一内核态事件管理实例；调用模块，用于针对内核态事件同步实例调用外部事件对应事件源注册的事件处理函数，以对外部事件进行处理。

在一可选实施例中，用户态事件管理机制对外提供用户态的实例创建函数、用户态的事件注册函数以及用户态的等待函数；创建模块91具体用于：响应上层应用程序对用户态的实例创建函数发起的调用请求；或者，响应上层应用程序对用户态的事件注册函数发起的调用请求；或者，响应上层应用程序对用户态的等待函数发起的调用请求。

在一可选实施例中，事件管理装置还包括：嵌套注册模块和第二返回模块；嵌套注册模块，用于将用户态事件管理实例嵌套注册至第三内核态事件管理实例中或另一用户态事件管理实例中；第二返回模块，用于将第三内核态事件管理实例或另一用户态事件管理实例的FD返回给上层应用程序。

图10为本申请示例性实施例提供的一种计算机设备的结构示意图，如图10所示，该计算机设备包括：存储器1004和处理器1005。

存储器1004，用于存储用户态事件管理机制对应的程序代码，用户态事件管理机制位于上层应用程序与操作系统内核之间，且依赖内核态事件管理机制，并可被配置为存储其它各种数据以支持在计算机设备上的操作。这些数据的示例包括用于在计算机设备上操作的任何应用程序或方法的指令。

存储器1004可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

处理器1005，与存储器1004耦合，用于执行存储器1004中的计算机程序，以用于：响应上层应用程序发起的实例创建操作，创建与上层应用程序适配的用户态事件管理实例，用户态事件管理实例包括至少两个内核态事件管理实例；响应上层应用程序发起的事件注册操作，在至少两个内核态事件管理实例中的不同内核态事件管理实例中分别注册上层应用程序关注的目标RDMA事件和目标内核事件的信息；响应上层应用程序发起的事件管理操作，采用轮询通知机制与中断通知机制相结合的方式，基于至少两个内核态事件管理实例对目标RDMA事件和目标内核事件进行通知管理。

在一可选实施例中，处理器1005在响应上层应用程序发起的实例创建操作，创建与上层应用程序适配的用户态事件管理实例时，具体用于：响应上层应用程序发起的实例创建操作，创建第一内核态事件管理实例和第二内核态事件管理实例，并创建设备上下文管理区，设备上下文管理区用于承载上层应用程序所在宿主设备上各RDMA设备在建立第一类RDMA连接时所需的共享CC资源和共享CQ资源；其中，第一类RDMA连接是指多个RDMA连接复用同一共享CC资源或共享CQ资源的一类RDMA连接，第一内核态事件管理实例用于管理上层应用程序关注的目标RDMA事件，第二内核态事件管理实例用于管理上层应用程序关注的目标内核事件。

在一可选实施例中，处理器1005还用于：为第一内核态事件管理实例和第二内核态事件管理实例分配文件描述符FD，并将第一内核态事件管理实例的FD作为用户态事件管理实例的全局FD返回给上层应用程序，以供上层应用程序基于全局FD向用户态事件管理实例发起事件注册操作和事件管理操作。

在一可选实施例中，处理器1005在响应上层应用程序发起的事件注册操作，在至少两个内核态事件管理实例中的不同内核态事件管理实例中分别注册上层应用程序关注的目标RDMA事件和目标内核事件的信息时，具体用于：响应上层应用程序发起的事件注册操作，获取上层应用程序关注的事件的描述信息，事件的描述信息包括事件的标识信息和事件的读写类型；若上层应用程序关注的事件中包括目标内核事件，则调用内核态的注册函数，将目标内核事件的描述信息注册到第二内核态事件管理实例中；若上层应用程序关注的事件中包括目标RDMA事件，则调用内核态的注册函数，将目标RDMA事件的描述信息注册到第一内核态事件管理实例中。

在一可选实施例中，在目标RDMA事件包括属于第一类RDMA连接的目标IO任务完成事件的情况下，则在将目标RDMA事件的描述信息注册到第一内核态事件管理实例中之前，处理器1005还用于：响应上层应用程序发起的关联操作，获取目标IO任务完成事件所属目标RDMA连接的IP地址，根据IP地址在设备上下文管理区中确定与目标IO任务完成事件对应的目标共享CQ资源；将目标共享CQ资源的信息通知与目标RDMA连接适配的目标RDMA设备，以使目标RDMA设备将目标RDMA连接的CQE消息写入目标共享CQ资源中。

在一可选实施例中，处理器1005在根据IP地址在设备上下文管理区中确定与目标IO任务完成事件对应的目标共享CQ资源时，具体用于：根据IP地址在设备上下文管理区中进行查找目标RDMA设备的上下文条目；在上下文条目中不存在空闲的共享CQ资源的情况下，创建新的共享CQ资源，并将新的共享CQ资源作为与目标IO任务完成事件对应的目标共享CQ资源。

在一可选实施例中，处理器1005在响应上层应用程序发起的事件管理操作，采用轮询通知机制与中断通知机制相结合的方式，基于至少两个内核态事件管理实例对目标RDMA事件和目标内核事件进行通知管理时，具体用于：响应上层应用程序发起的事件管理操作，进入忙轮询阶段，对设备上下文管理区中的共享CQ资源进行忙轮询，以对目标RDMA事件中属于第一类RDMA连接的目标IO任务完成事件进行通知管理；若在设定的忙轮询耗时内未轮询到任何目标IO任务完成事件，进入事件等待阶段，基于第一内核态事件管理实例和第二内核态事件管理实例分别对目标RDMA事件中的目标CC事件和目标内核事件进行通知管理，目标CC事件属于第一类RDMA连接和/或第二类RDMA连接。

在一可选实施例中，处理器1005在对设备上下文管理区中的共享CQ资源进行忙轮询，以对目标RDMA事件中属于第一类RDMA连接的目标IO任务完成事件进行通知时，具体用于：若在设定的忙轮询耗时内轮询到CQE消息，且在目标IO任务完成事件中匹配到CQE消息对应的IO任务完成事件，则向上层应用程序返回CQE消息对应的IO任务完成事件的描述信息，以供上层应用程序对CQE消息对应的IO任务完成事件进行处理。

在一可选实施例中，处理器1005在响应上层应用程序发起的事件管理操作，进入忙轮询阶段时，具体用于：响应上层应用程序发起的事件管理操作，判断上层应用程序是否注册了目标IO任务完成事件；在上层应用程序注册了目标IO任务完成事件的情况下，进入忙轮询阶段；在上层应用程序未注册目标IO任务完成事件的情况下，跳过忙轮询阶段，直接进入事件等待阶段。

在一可选实施例中，处理器1005若在设定的忙轮询耗时内未轮询到任何目标IO任务完成事件，进入事件等待阶段，基于第一内核态事件管理实例和第二内核态事件管理实例分别对目标RDMA事件中的目标CC事件和目标内核事件进行通知管理时，具体用于：若在设定的忙轮询耗时内未轮询到任何目标IO任务完成事件，则在设定的忙轮询耗时结束时，调用内核态的等待函数以进入等待阶段，以供第一内核态事件管理实例和第二内核态事件管理实例分别在设定的等待时长内监测是否有相应事件发生；在第一内核态事件管理实例或第二内核态事件管理实例在设定的等待时长内监测到第一目标CC事件或第一目标内核事件发生的情况下，向上层应用程序返回第一目标CC事件或第一目标内核事件的描述信息，以供上层应用程序对第一目标CC事件或第一目标内核事件进行处理。

在一可选实施例中，处理器1005还用于：将共享CC资源的标识信息与第二内核态事件管理实例的标识信息分别注册到第一内核态事件管理实例中，以形成两级管理结构；其中，共享CC资源或第二内核态事件管理实例在监测到相应事件发生时可将第一内核态事件管理实例唤醒。

在一可选实施例中，处理器1005在设定的忙轮询耗时结束时，调用内核态的等待函数以进入等待阶段时，具体用于：在设定的忙轮询耗时结束时，针对第一内核态事件管理实例调用内核态的等待函数以进入等待阶段；处理器1005在第二内核态事件管理实例在设定的等待时长内监测到第一目标内核事件发生的情况下，向上层应用程序返回第一目标内核事件的描述信息，以供上层应用程序对第一目标内核事件进行处理时，具体用于：若第二内核态事件管理实例在设定的等待时长内监测到第一目标内核事件发生，则向第一内核态事件管理实例发送第一事件通知，以唤醒第一内核态事件管理实例；再次针对第二内核态事件管理实例调用内核态的等待函数，以获取第二内核态事件管理实例监测到的第一目标内核事件的描述信息；向上层应用程序返回发生的第一目标内核事件的描述信息，以供上层应用程序对第一目标内核事件进行处理。

在一可选实施例中，处理器1005在响应上层应用程序发起的实例创建操作，创建与上层应用程序适配的用户态事件管理实例时，具体用于：创建负责监听外部事件的内核态事件同步实例，并将内核态事件同步实例注册到第一内核态事件管理实例中，外部事件是指上层应用程序之外的事件；处理器1005还用于：在事件等待阶段，若内核态事件同步实例在设定的等待时长内监测到外部事件发生，则向第一内核态事件管理实例发送第二事件通知，以唤醒第一内核态事件管理实例；针对内核态事件同步实例调用外部事件对应事件源注册的事件处理函数，以对外部事件进行处理。

在一可选实施例中，用户态事件管理机制对外提供用户态的实例创建函数、用户态的事件注册函数以及用户态的等待函数；处理器1005在响应上层应用程序发起的实例创建操作时，具体用于：响应上层应用程序对用户态的实例创建函数发起的调用请求；处理器1005在响应上层应用程序发起的事件注册操作时，具体用于：响应上层应用程序对用户态的事件注册函数发起的调用请求；处理器1005在响应上层应用程序发起的事件管理操作时，具体用于：响应上层应用程序对用户态的等待函数发起的调用请求。

在一可选实施例中，处理器1005还用于：将用户态事件管理实例嵌套注册至第三内核态事件管理实例中或另一用户态事件管理实例中；将第三内核态事件管理实例或另一用户态事件管理实例的FD返回给上层应用程序。

进一步，如图10所示，该计算机设备还包括：通信组件1006、显示器1007、电源组件1008、音频组件1009等其它组件。图10中仅示意性给出部分组件，并不意味着计算机设备只包括图10所示组件。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，当计算机程序被处理器执行时，致使处理器实现图1所示方法实施例中的各步骤。

相应地，本申请实施例还提供一种计算机程序产品，包括计算机程序/指令，当计算机程序/指令被处理器执行时，致使处理器实现图1所示方法实施例中的各步骤。

上述图10中的通信组件被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如WiFi，2G、3G、4G/LTE、5G等移动通信网络，或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

上述图10中的显示器包括屏幕，其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。

上述图10中的电源组件，为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

上述图10中的音频组件，可被配置为输出和/或输入音频信号。例如，音频组件包括一个麦克风(MIC)，当音频组件所在设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器或经由通信组件发送。在一些实施例中，音频组件还包括一个扬声器，用于输出音频信号。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (14)

1.一种事件管理方法，其特征在于，适用于用户态事件管理机制，所述用户态事件管理机制位于上层应用程序与操作系统内核之间，且依赖内核态事件管理机制，所述方法包括：

响应上层应用程序发起的实例创建操作，创建与所述上层应用程序适配的用户态事件管理实例，所述用户态事件管理实例包括至少两个内核态事件管理实例；

响应所述上层应用程序发起的事件注册操作，在所述至少两个内核态事件管理实例中的不同内核态事件管理实例中分别注册所述上层应用程序关注的目标远程直接数据存取RDMA事件和目标内核事件的信息；

响应所述上层应用程序发起的事件管理操作，采用轮询通知机制与中断通知机制相结合的方式，基于所述至少两个内核态事件管理实例对所述目标RDMA事件和所述目标内核事件进行通知管理。

2.根据权利要求1所述的方法，其特征在于，响应上层应用程序发起的实例创建操作，创建与所述上层应用程序适配的用户态事件管理实例，包括：

响应上层应用程序发起的实例创建操作，创建第一内核态事件管理实例和第二内核态事件管理实例，并创建设备上下文管理区，所述设备上下文管理区用于承载所述上层应用程序所在宿主设备上各RDMA设备在建立第一类RDMA连接时所需的共享就绪通知通道CC资源和共享任务完成队列CQ资源；

其中，所述第一类RDMA连接是指多个RDMA连接复用同一共享CC资源或共享CQ资源的一类RDMA连接，所述第一内核态事件管理实例用于管理上层应用程序关注的目标RDMA事件，所述第二内核态事件管理实例用于管理上层应用程序关注的目标内核事件。

3.根据权利要求2所述的方法，其特征在于，响应所述上层应用程序发起的事件注册操作，在所述至少两个内核态事件管理实例中的不同内核态事件管理实例中分别注册所述上层应用程序关注的目标RDMA事件和目标内核事件的信息，包括：

响应上层应用程序发起的事件注册操作，获取所述上层应用程序关注的事件的描述信息，所述事件的描述信息包括事件的标识信息和事件的读写类型；

若所述上层应用程序关注的事件中包括目标内核事件，则调用内核态的注册函数，将所述目标内核事件的描述信息注册到所述第二内核态事件管理实例中；

若所述上层应用程序关注的事件中包括目标RDMA事件，则调用内核态的注册函数，将所述目标RDMA事件的描述信息注册到所述第一内核态事件管理实例中。

4.根据权利要求3所述的方法，其特征在于，在所述目标RDMA事件包括属于第一类RDMA连接的目标IO任务完成事件的情况下，则在将所述目标RDMA事件的描述信息注册到所述第一内核态事件管理实例中之前，还包括：

响应所述上层应用程序发起的关联操作，获取所述目标IO任务完成事件所属目标RDMA连接的IP地址，根据所述IP地址在所述设备上下文管理区中确定与所述目标IO任务完成事件对应的目标共享CQ资源；

将所述目标共享CQ资源的信息通知与所述目标RDMA连接适配的目标RDMA设备，以使所述目标RDMA设备将所述目标RDMA连接的完成队列元素CQE消息写入所述目标共享CQ资源中。

5.根据权利要求4所述的方法，其特征在于，根据所述IP地址在所述设备上下文管理区中确定与所述目标IO任务完成事件对应的目标共享CQ资源，包括：

根据所述IP地址在所述设备上下文管理区中进行查找所述目标RDMA设备的上下文条目；

在所述上下文条目中不存在空闲的共享CQ资源的情况下，创建新的共享CQ资源，并将所述新的共享CQ资源作为与所述目标IO任务完成事件对应的目标共享CQ资源。

6.根据权利要求2-5中任一项所述的方法，其特征在于，响应所述上层应用程序发起的事件管理操作，采用轮询通知机制与中断通知机制相结合的方式，基于所述至少两个内核态事件管理实例对所述目标RDMA事件和所述目标内核事件进行通知管理，包括：

响应所述上层应用程序发起的事件管理操作，进入忙轮询阶段，对所述设备上下文管理区中的共享CQ资源进行忙轮询，以对所述目标RDMA事件中属于第一类RDMA连接的目标IO任务完成事件进行通知管理；

若在设定的忙轮询耗时内未轮询到任何目标IO任务完成事件，进入事件等待阶段，基于所述第一内核态事件管理实例和所述第二内核态事件管理实例分别对所述目标RDMA事件中的目标CC事件和所述目标内核事件进行通知管理，所述目标CC事件属于第一类RDMA连接和/或第二类RDMA连接。

7.根据权利要求6所述的方法，其特征在于，响应所述上层应用程序发起的事件管理操作，进入忙轮询阶段，包括：

响应所述上层应用程序发起的事件管理操作，判断所述上层应用程序是否注册了所述目标IO任务完成事件；

在所述上层应用程序注册所述目标IO任务完成事件的情况下，进入忙轮询阶段；

在所述上层应用程序未注册所述目标IO任务完成事件的情况下，跳过忙轮询阶段，直接进入所述事件等待阶段。

8.根据权利要求6所述的方法，其特征在于，若在设定的忙轮询耗时内未轮询到任何目标IO任务完成事件，进入事件等待阶段，基于所述第一内核态事件管理实例和所述第二内核态事件管理实例分别对所述目标RDMA事件中的目标CC事件和所述目标内核事件进行通知管理，包括：

若在设定的忙轮询耗时内未轮询到任何目标IO任务完成事件，则在设定的忙轮询耗时结束时，调用内核态的等待函数以进入等待阶段，以供所述第一内核态事件管理实例和所述第二内核态事件管理实例分别在设定的等待时长内监测是否有相应事件发生；

在所述第一内核态事件管理实例或所述第二内核态事件管理实例在设定的等待时长内监测到第一目标CC事件或第一目标内核事件发生的情况下，向所述上层应用程序返回所述第一目标CC事件或第一目标内核事件的描述信息，以供所述上层应用程序对第一目标CC事件或第一目标内核事件进行处理。

9.根据权利要求8所述的方法，其特征在于，所述方法还包括：

将所述共享CC资源的标识信息与所述第二内核态事件管理实例的标识信息分别注册到所述第一内核态事件管理实例中，以形成两级管理结构；其中，所述共享CC资源或所述第二内核态事件管理实例在监测到相应事件发生时可将所述第一内核态事件管理实例唤醒。

10.根据权利要求9所述的方法，其特征在于，在设定的忙轮询耗时结束时，调用内核态的等待函数以进入等待阶段，包括：

在设定的忙轮询耗时结束时，针对所述第一内核态事件管理实例调用内核态的等待函数以进入等待阶段；

相应地，在所述第二内核态事件管理实例在设定的等待时长内监测到第一目标内核事件发生的情况下，向所述上层应用程序返回所述第一目标内核事件的描述信息，以供所述上层应用程序对第一目标内核事件进行处理，包括：

若所述第二内核态事件管理实例在设定的等待时长内监测到第一目标内核事件发生，则向所述第一内核态事件管理实例发送第一事件通知，以唤醒所述第一内核态事件管理实例；

再次针对所述第二内核态事件管理实例调用内核态的等待函数，以获取所述第二内核态事件管理实例监测到的第一目标内核事件的描述信息；

向所述上层应用程序返回发生的第一目标内核事件的描述信息，以供所述上层应用程序对第一目标内核事件进行处理。

11.根据权利要求9所述的方法，其特征在于，响应上层应用程序发起的实例创建操作，创建与所述上层应用程序适配的用户态事件管理实例，包括：

创建负责监听外部事件的内核态事件同步实例，并将所述内核态事件同步实例注册到所述第一内核态事件管理实例中，所述外部事件是指所述上层应用程序之外的事件；

所述方法还包括：在所述事件等待阶段，若所述内核态事件同步实例在设定的等待时长内监测到外部事件发生，则向所述第一内核态事件管理实例发送第二事件通知，以唤醒所述第一内核态事件管理实例；针对所述内核态事件同步实例调用所述外部事件对应事件源注册的事件处理函数，以对所述外部事件进行处理。

12.一种事件管理装置，其特征在于，所述事件管理装置上运行有用户态事件管理机制，所述用户态事件管理机制位于上层应用程序与操作系统内核之间，且依赖内核态事件管理机制，所述事件管理装置包括：

创建模块，用于响应上层应用程序发起的实例创建操作，创建与所述上层应用程序适配的用户态事件管理实例，所述用户态事件管理实例包括至少两个内核态事件管理实例；

注册模块，用于响应所述上层应用程序发起的事件注册操作，在所述至少两个内核态事件管理实例中的不同内核态事件管理实例中分别注册所述上层应用程序关注的目标RDMA事件和目标内核事件的信息；

通知管理模块，用于响应所述上层应用程序发起的事件管理操作，采用轮询通知机制与中断通知机制相结合的方式，基于所述至少两个内核态事件管理实例对所述目标RDMA事件和所述目标内核事件进行通知管理。

13.一种计算机设备，其特征在于，所述计算机设备包括：存储器和处理器，所述存储器中存储有用户态事件管理机制对应的程序代码，所述用户态事件管理机制位于上层应用程序与操作系统内核之间，且依赖内核态事件管理机制；所述处理器与所述存储器耦合，用于执行所述用户态事件管理机制对应的程序代码，以用于实现权利要求1-11任一项所述方法中的步骤。

14.一种存储有计算机程序的计算机可读存储介质，其特征在于，当所述计算机程序被处理器执行时，致使所述处理器能够实现权利要求1-11任一项所述方法中的步骤。

Images