HCA 有多个可生成事件的源(完成事件、异步事件/错误)。一旦内部生成事件,就可以通过事件队列机制将其报告给主机软件。EQ 是一个驻留在内存中的循环缓冲区,硬件使用它来写入事件原因信息,供主机软件使用。一旦启用事件报告,事件发生时硬件就会将事件原因信息写入 EQ。如果 EQ 已启用(armed),则 HW 随后将按照 EQ 中的配置在设备接口上生成中断(发送 MSI-X 消息或断言引脚(assert the pin))。每个 HCA EQ 都可以与主机上的不同事件处理程序相关联。每个事件组都可以配置为向其中一个 EQ 报告事件,从而实现将事件硬件解复用(demultiplexing)到不同的事件处理程序。具体而言,可以根据报告事件的 CQ 将完成报告报告给不同的 EQ。在虚拟环境中,EQ 可以导出到客户虚拟机,客户虚拟机中的内核驱动程序将控制 EQ。HCA HW 强制执行 EQ 之间的保护和隔离。 SW 可以使用 GEN_EQE 命令创建新的 EQE。
EQ 是一个包含以下实体的对象:
EQ 是一个虚拟连续的内存缓冲区,HCA 使用它来发布事件报告,应用程序软件使用它来轮询事件报告。此缓冲区由主机软件在创建 EQ 时分配,其物理地址传递给 HCA。与此缓冲区关联的内存作为物理页面列表传递给 HCA。EQ 缓冲区必须在 EQE 大小(64B)边界上对齐。EQ 如图 34 所示
硬件将事件记录(写入 EQE)发布到 EQ。在 EQE 消耗后,SW 会更新 EQ Doorbell 寄存器,指定消费者索引并更改 EQ 的状态(例如,将其设置为在下一个事件发布时生成中断)。EQ 是一个几乎连续的循环缓冲区,可由 HCA 硬件访问,包含 EQE。缓冲区由生产者计数器和消费者计数器管理,与 CQ 的管理方式相同。成功轮询 EQ(即找到新的 EQE)后,软件会更新消费者计数器,硬件会使用该计数器来监视潜在的 EQ 溢出。如果在需要发布事件(EQE)时 EQ 已满,则该事件将被推迟,直到 SW 轮询 EQE 并释放空间以发布新的 EQE。可以推迟的完成事件数量不受 HW 限制。但是,如果在需要发布其他(非完成事件)时 EQ 已满,则它们将丢失。 SW 负责确保用于报告未完成事件的事件队列足够深(或轮询频率足够高),以避免事件丢失。必须修复此 EQ 超限处理(如果尚未修复)
EQE 所有权由 EQE 中的 Owner 位定义。此位遵循 CQE 中 Owner 位的逻辑,有关详细信息,请参阅第 450 页上的“CQE 所有权”
每个 EQE 都包含足够的信息来将 EQE 与其 CQE 关联起来。EQE 布局如表 173 所示
在消费(draining)(消耗(consuming))EQ时,软件应执行以下算法:
EQ DoorBell 寄存器映射到其中一个 UAR(DoorBell)页。有关详细信息,请参考第 250 页上的“UAR 页面格式”。
HCA 实现了 CQ,详细描述见第 248 页上的“软件接口”。创建 CQ 时,软件会配置此 CQ 将向其报告完成事件的 EQ 编号。有关完成事件和完成事件通知请求的进一步描述,请参见第 451 页上的“请求完成通知”。
某些应用程序可能使用 EQ 而不生成中断。当中断率过高且轮询对于降低 CPU 负载有意义时,这很有用。在这种情况下,应在触发状态下创建 EQ,并且永不装备(in fired state and never be armed)。进一步,将通过轮询 EQ 并使用 DoorBells 更新 EQ 消费者索引来管理 EQ(请参阅第 250 页上的“UAR 页面格式”)。
在某些情况下,多个 EQ 会向同一个 MSI-X 向量或中断引脚报告。在这种情况下,当服务中断时,设备驱动程序应该装备所有向同一个 MSI-X 向量/中断引脚报告的 EQ。
每种事件类型都可以映射到一个 EQ。将事件映射到 EQ 和从 EQ 取消映射是通过命令接口执行的(请参阅第 1647 页上的“命令参考”)。将完成事件映射到 EQ 是通过命令接口为每个 CQ 单独执行的(请参阅第 1647 页上的“命令参考”)
event_type 字段的编码如表 175“事件类型和编码”所示。
写入 EQ 的 Event_Data 字段在以下部分中定义。
可以通过 QUERY_HCA_CAP 命令检索 HCA 支持的 EQ 数量。注意:EQ 枚举是针对多功能设备中的每个功能的。每个功能都拥有从 0x0 开始编号的 EQ。访问 EQ 时,它也由EQ 编号标识。
向 EQ 报告事件可能伴随着硬件中断的生成(在主机接口总线上生成中断消息)。每个 EQ 都可以独立配置为断言其中一个中断引脚或在主机接口总线上生成其中一个中断消息 (MSI-X)
如果 EQ 已由中断处理软件启用,则会产生硬件中断。当 EQ 处于启用(armed)状态时,如果生成事件,硬件会解除 EQ 的启用,并且不会生成其他中断,直到 EQ 重新启用(re-armed)。EQ 状态机和状态转换如图 35“EQ 状态机”所示
通过写入 EQ ARM DoorBell 来启用 EQ 以触发中断。请参阅第 250 页上的“UAR 页面格式”。仅当在设备的相应 PCI 配置寄存器中设置了 MSI-X 启用位时,才会生成 MSI-X。根据 PCI 规范,当启用 MSI-X 时,禁止设备使用 INTA# 引脚。因此,必须根据 PCI 配置空间中的 MSIX 启用位配置 EQ,以避免与 PCI 规范发生冲突。当设备重新配置为不同的中断方案(从 MSI-X 到 INTA# 或反之亦然)时,应拆除 EQ 并使用新配置重新建立。此外,HCA 提供机制来调节事件队列的中断请求生成,如第 507 页上的“中断调节”中所述
HCA 支持分层事件传递方案。WQ 上的工作请求完成情况会报告给 CQ。多个 WQ 可以向同一个 CQ 报告完成情况。CQ 可以在工作请求完成时生成事件,并将事件发布到其中一个 EQ。多个 CQ 可以向同一个 EQ 报告事件。EQ 可以在事件报告时生成中断,通过配置的方法生成中断(例如,特定的 MSI-X 消息、某个引脚断言等)。多个 EQ 可以通过相同的方法生成中断(例如,通过生成相同的 MSI-X 消息或断言相同的引脚)。在网络流量高负载的情况下,非常需要审核事件报告,从而使 SW 能够在每次进入事件处理程序时处理多个事件。 HCA 部署了两阶段调节方案:
完成事件调节 (CEM) 会延迟准备就绪的 CQ 发布完成事件,直到该队列上报告了多个完成。这样就可以在多个工作完成之间分摊完成事件处理程序调用的开销。可以为每个 CQ 单独启用 CEM。当满足以下任一条件时,已启动的 CQ 将生成事件:
• cq_period 计时器已过期,并且此 CQ 有一个待处理事件(如果不进行调节,则会产生该事件)。cq_period 计时器在事件生成或完成生成时重新启动,具体取决于 CQ.cq_period_mode(请参见第 467 页上的表 171,“完成队列上下文布局”)。
• 自触发上次事件生成的完成数达到 cq_max_count 以来生成的完成数。在受 CEM 约束的 CQ 中配置了 cq_max_count 和 cq_period 参数。图 36 说明了配置为在发布 4 个完成后报告事件(左)或自上次完成报告过期后超时(右)后报告事件的 CQ 的事件生成
事件报告后,CQ 将转为触发状态(fired)。 CEM 预计将部署在整合来自多个独立且同时运行的 WQ 的完成报告的 CQ 上
对于 CQ.scqe_break_moderation_en==1 的 CQ,请求的 CQE(启用了 CQE.SE 标志)会中断调节并生成立即的 EQE。请注意,如果启用了 HCA_CAP.scqe_break_moderation,则支持此功能
中断频率调节 (IFM) 可调整芯片接口上的中断断言频率。IFM 在每个中断(引脚或消息)上实现,并确保此中断的断言速率不高于配置的速率。每个中断消息/引脚都可以独立配置以调整中断频率;此属性在中断上下文表中配置。在启用 IFM 的中断上生成中断请求后,HW 将检查中断相关计时器的值。如果此计时器值为零,则在芯片接口上生成中断,计时器将使用中断上下文表中相应条目的 int_period 字段重新加载,计时器开始倒计时。如果在生成中断请求时计时器值不为零,则芯片接口上的中断生成将被延迟,直到计时器到期。每次在芯片接口上触发(生成)中断时,计时器都会重新加载并开始倒计时。 XXX - 指定中断上下文表 此机制确保中断的生成频率不会超过 int_period 时间间隔。但是,如果长时间没有生成中断,中断请求将导致片上接口立即生成中断。图 37 说明了 IFM 机制
始终可以部署中断频率调节,以确保 HCA 不会以过高的速率生成中断。中断调节可通过 CONFIG_INT_MODERATION 命令进行配置
MLX PRM 8.20 Events and Interrupts
中断分析(XB): https://cloud.tencent.com/developer/article/2472554
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。