IBA功能

IBA功能(Features)

队列对（Queue Pairs）

QP是硬件提供给IBA消费者的虚拟接口；它为消费者提供虚拟通信端口。该体系结构支持每个通道适配器（channel adapter）最多2²⁴个QP；每个QP的操作与其他QP无关。每个QP提供高度的隔离和保护，以防止其他QP操作和其他消费者。因此，可以将QP视为分配给单个消费者的私有资源。如图17所示，消费者可能会使用多个QP。

消费者通过分配QP并指定其服务类别来创建此虚拟通信端口。通信在源QP和目标QP之间进行。对于连接定向服务，每个QP都与一个其他QP紧密绑定，通常位于不同的节点上。消费者启动任何必要的通信建立以将QP与目标QP绑定，并使用某些信息（例如目标LID，服务级别和协商的操作限制）配置QP上下文。

消费者向QP发布工作请求以通过该QP调用通信。

服务类型（Types of Service）

根据源QP和接收QP的交互方式，为每个QP配置一定的操作类别（称为服务类型）。源QP和目标QP都必须配置为相同的服务类型。每种服务类型都基于以下属性。

已收到消息. 根据源QP和接收QP的交互方式，为每个QP配置一定的操作类别（称为服务类型）。源QP和目标QP都必须配置为相同的服务类型。每种服务类型都基于以下属性。

• 面向连接与数据报 - 对于面向连接的服务，QP与一个其他QP关联，并且所有发布到QP的工作请求都会导致发送到已建立的目标QP的消息。数据报操作允许使用单个QP向任何节点上的任何适当QP发送和接收消息。
• 可靠与不可靠 - IBA传输通过一系列确认来保证可靠性。对于可靠服务，传输保证在没有错误的情况下按顺序且仅一次地传递每个消息。为了提供这种可靠性，接收QP使用肯定确认（ACK）或否定确认（NAK）确认所有接收到的入站请求。对于不可靠的服务，传输协议不能保证传递所有数据，尽管有机制可以确保所有接收到的数据最多传递一次，并且传递的数据未损坏。此外，某些情况下，布线配置的更改可能导致数据无序传递；可靠服务可以检测并从这些情况中恢复。不可靠的服务可以检测到这些情况，但无法独立从中恢复。
• IBA传输与其他传输 - IBA传输服务为基于通道和基于内存的操作定义了特定的传输协议。IBA还支持使用通道适配器作为数据链路引擎在节点之间发送原始数据包，这对于支持遗留协议堆栈和遗留网络非常有用。

IBA定义的服务类型

服务类型	面向连接	Acknowledged	Transport
可靠连接（Reliable Connection）	√	√	IBA
不可靠连接（Unreliable Connection ）	√	×	IBA
可靠数据报（Reliable Datagram ）	×	√	IBA
不可靠数据报（Unreliable Datagram）	×	×	IBA
原始数据报（RAW Datagram ）	×	×	IBA

某些IBA操作仅适用于某些服务类别。如果操作不适用于配置的服务类别，则QP会拒绝WQE。

面向连接的服务要求消费者启动与目标节点的通信建立过程（连接设置）以关联QP并在任何QP操作之前建立QP上下文。实际上，除了原始数据报之外的所有服务类别都需要某种形式的通信设置来关联队列对。对于可靠数据报服务，节点执行通信建立过程以将端到端（EE）上下文（稍后将进行解释）与每个目标节点关联。为可靠数据报服务配置的所有QP都使用已建立的EE上下文，并且工作请求指定要用于该操作的EE上下文。

原始数据报与不可靠数据报类似，只是源QP不知道将接收和处理消息的QP的身份。原始数据报允许路由器将原始数据报分组转发到没有等效QP的不同结构（如LAN或WAN）上的非IBA目的地。有两种类型的原始数据报，IPv6和Ethertype。IPv6原始数据报包含全局路由报头，并且分组有效载荷包含在全局路由报头中标识的传输协议服务数据单元。以太网类型原始数据报包含以太网类型字段，数据包有效载荷包含以太网类型字段中标识的传输协议服务数据单元。

IBA定义了通道（发送/接收）和内存（RDMA）语义。原始数据报和不可靠数据报服务不支持内存语义。

密钥（Keys）

IBA使用各种密钥提供隔离和保护。密钥是由管理实体分配的值，以各种方式在消息中使用。密钥本身不提供安全性，因为密钥在跨越结构的消息中是可用的，因此任何能够到达结构内部的实体都可以确定密钥值。 IBA确实对应用程序如何访问某些密钥施加了限制。

• 管理密钥（M_Key）：强制执行主子网管理器的控制。由子网管理器管理，并用于某些子网管理数据包。每个通道适配器端口都有一个由SM设置并启用的M_Key。SM可以为每个端口分配不同的密钥。启用后，端口拒绝某些不包含编程M_Key的管理数据包。因此，只有具有编程M_Key的SM才能更改节点的布线配置。只要SM处于活动状态，SM可以防止读取端口的M_Key。端口维护超时时间，因此如果SM失败，则端口将恢复到未受管理状态。交换机只有一个M_Key。

• 基板管理密钥（B_Key）：强制控制子网基板管理器。由子网基板管理器管理并在某些MAD中使用。每个通道适配器端口都有一个由基板管理器设置的B_Key。基板管理器可以为每个端口分配不同的密钥。启用后，端口拒绝不包含编程B_Key的某些管理数据包。因此，只有具有编程B_Key的基板管理器才能更改节点的基板配置。只要基板管理器处于活动状态，基板管理器就可以防止读取端口的B_Key。端口维护超时时间，因此如果基板管理器失败，则端口将恢复到未受管状态。交换机有一个B_Key。

• 分区密钥（P_Key）：强制成员身份。分区管理器（PM）通过子网管理器进行管理。每个通道适配器端口都包含一个由PM设置的分区密钥表。需要为相同的分区配置QP才能进行通信（除了QP0，QP1和配置为原始数据报的端口），因此P_Key在每个IB传输数据包中都会携带。通信建立过程的一部分确定特定QP或EEC使用的P_Key。EEC包含可靠数据报服务的P_Key，而QP上下文包含其他IBA传输类型的P_Key。在发送的每个数据包中，将QP或EEC中的P_Key放置，并将其与接收到的每个数据包中的P_Key进行比较。比较P_Key失败的接收数据包将被拒绝。每个交换机都有一个用于管理消息的P_Key表，并且可以选择支持基于其P_Key过滤数据包的分区强制表。

• 队列密钥（Q_Key）：强制可靠和不可靠数据报服务的访问权限（不包括RAW数据报服务类型）。由通道适配器管理。在数据报服务的通信建立期间，节点为特定队列对交换Q_Key，节点在发送到远程QP的所有数据包中使用传递给其远程QP的值。同样，远程节点使用提供的Q_Key。接收到具有不同于节点提供给远程队列对的Q_Key的数据包意味着该数据包无效，因此被拒绝。

  具有最高有效位集的Q_Key被认为是受控Q_Keys（例如GSI Q_Key），并且HCA不允许消费者任意指定受控Q_Key。尝试发送受控Q_Key会导致使用QP上下文中的Q_Key。因此，操作系统保持控制权，因为它可以为特权消费者配置受控Q_Key的QP上下文。

• 内存密钥（L_Key和R_Key）：启用虚拟地址并为消费者提供控制访问其内存的机制。这些密钥由通道适配器通过注册过程进行管理。消费者向通道适配器注册一个内存区域，并接收L_Key和R_Key。消费者在工作请求中使用L_Key来描述本地内存，并将R_Key传递给远程消费者以用于RDMA操作。当消费者排队RDMA操作时，它指定了从远程消费者传递给它的R_Key，并且R_Key包含在RDMA请求数据包中，发送到原始通道适配器。 R_Key验证发送方访问目标内存的权利，并为目标通道适配器提供将虚拟地址转换为物理地址的手段。

虚拟内存地址（Virtual Memory Address）

IBA针对虚拟寻址进行了优化。也就是说，IBA消费者在工作请求中使用虚拟地址，通道适配器能够根据需要将虚拟地址转换为物理地址。为了实现这一点，每个消费者都向通道适配器注册虚拟内存区域，并且通道适配器返回2个内存句柄，称为L_Key和R_Key。然后，消费者在需要访问该区域的每个工作请求中使用L_Key。有关L_Key使用的说明，请参见密钥。
内存注册提供了机制，允许IBA消费者描述一组虚拟连续的内存位置或一组物理连续的内存位置，以便HCA使用虚拟地址将内存作为虚拟连续缓冲区访问。

IBA还支持远程内存访问（RDMA），允许远程消费者访问已注册的内存。对于RDMA，消费者将R_KEY和该内存区域中缓冲区的虚拟地址传递给另一个消费者。该远程消费者在其RDMA WQE中提供该R_Key，以访问原始节点中的内存。有关R_Key使用的详细说明，请参见密钥。

保护域（Protection Domains）

内存注册不仅允许使用虚拟内存寻址，而且还提供了更高级别的保护，以防止意外和未经授权的访问。

由于消费者可能与许多不同的目标通信，但不希望让所有这些目标都对其注册的内存具有相同的访问权限，因此IBA提供了保护域。保护域允许使用者控制哪一组内存区域和哪一组QP可以访问内存窗口。

在消费者分配QP或注册内存之前，它会创建一个或多个保护域。 QP分配给保护域，并向保护域注册内存。特定内存域的L_Key和R_Key仅在为同一保护域创建的QP上有效。

分区（Partitions）

分区强制在共享InfiniBand结构的系统之间实现隔离。分区与子网，交换机或路由器建立的边界无关。相反，分区描述了结构中可以通信的一组终节点。

端节点的每个端口都是至少一个分区的成员，并且可能是多个分区的成员。分区管理器为每个通道适配器端口分配分区键（P_Keys）。每个P_Key表示一个分区。每个QP^[1]和EE上下文都分配给一个分区，并在其发送的所有数据包中使用该P_Key，并检查其接收到的所有数据包中的P_Key。接收到无效的P_Key会导致数据包被丢弃。

交换机和路由器可以选择用于强制分区。在这种情况下，分区管理器使用P_Key信息对交换机或路由器进行编程，当交换机或路由器检测到具有无效P_Key的数据包时，它会丢弃该数据包。

虚拟通道（Virtual Lanes）

虚拟通道（VL）提供了一种用于在单个物理链路内创建多个虚拟链路的机制。虚拟通道表示端口中的一组传输和接收缓冲区。所有端口都支持VL₁₅，该VL专门用于子网管理。还有15个其他VL（VL₀到VL₁₄）称为数据VL，所有端口都支持至少一个数据VL（VL₀），并且可以提供VL₁到VL_n-1，其中n是端口支持的数据VL的数量）。端口使用的实际数据VL由SM配置，并基于数据包中的服务级别（SL）字段。默认情况下，使用VL0，直到SM确定链接两端支持的VL数量并将端口的SL编程为VL映射表。

该端口对每个数据VL保持单独的流量控制，使得一个VL上的过多流量不会阻塞另一个VLAN上的流量。

VL分配仅存在于链路两端的端口之间，并且一个链路上的VL分配独立于其他链路上的分配与其他链接上的分配无关。

每个数据包都有一个SL，该SL在数据包报头中指定。当数据包遍历结构时，其SL确定在每个链路上将使用哪个VL。

每个端口维护一个SL到VL映射表，以便在适当的VL上发送数据包。

当链路两端的端口支持不同数量的数据VL时，数量较高的端口会降级为另一个端口支持的数量。因此，对于仅支持单个数据VL的端口，所有数据流量默认为VL₀。

服务质量（Quality of Service）

IBA提供了几种机制，允许子网管理器管理连接和无连接服务的各种服务质量保证。这些机制是服务级别，服务级别到虚拟通道映射和分区。 IBA不定义服务质量（QoS）级别（例如，尽力而为）。

服务级别（Server Level）

IBA定义了一个服务级别（SL）属性，允许数据包在16个服务级别中的一个级别上运行。每个服务级别的定义和目的都超出了架构的范围，并作为结构管理策略留给了管理员。因此，服务级别的分配是每个节点的通信管理器及其与子网管理器协商的功能。

SL到VL映射

与服务级别相关的另一个IBA机制是虚拟通道。每个数据包都标识其SL，当数据包遍历结构时，数据包的SL是确定下一个链接上使用哪个VL的组成部分。为此，每个端口（交换机，路由器，终节点）都有一个由子网管理配置的SL到VL_s映射表。当然，对于终止于仅支持一个数据VL的端口的所有链路，所有SL都映射到VL₀。

否则，子网管理策略确定将每个SL映射到可用VL。

寻址QP0的数据包是子网管理数据包（SMP），并且仅使用VL15，并且忽略其SL。 VL₁₅（管理VL）不是数据VL，并且不用于未寻址QP₀的数据包。

分区（Partitions）

与服务级别相关的另一个IBA机制是分区。结构管理可以为特定分区分配某些SL_s。这允许SM隔离这些分区之间的业务流，即使两个分区都以相同的QoS级别运行，也可以保证每个分区公平地共享带宽，而不管其他分区中的节点是否行为不当或订阅过多。

注入速率控制（Injection Rate Control）

IBA定义了许多不同的链路速率。最低的2.5 Gb/sec比特率称为1x（一倍）链路。其他链路速率为10Gb/sec（4x）和30 Gb/sec（x12）。请参见InfiniBand Trade Association网站（www.infinibandta.org）以了解当前速度路线图规划。为了在结构内支持多个链路速度，IBA定义了一种静态速率控制机制，该机制可防止具有高速链接的端口超出具有较低速度链接的端口的容量。

作为路径解析过程的一部分，SubnAdm:PathRecord为节点提供路径的MTU和速率信息。路径信息用于确定限制因素是交换机端口还是端节点。

图19中的示例说明，具有12x链路速度的端口A具有以3倍端口B的容量和12倍端口C、D或E的容量注入流量的潜力。此外，端口B有可能以端口C、D或E的4倍容量注入流量。由于流量往往是突发性的，因此每次端口A发送到其他端口时，结构都有很高的拥塞概率。链路流控制使结构不会因为拥塞而丢失数据包，但是反向压力会影响其他本来不会拥塞的路径。

IBA通过为以大于1x的链路速度运行的端口定义静态速率控制机制来解决此问题。

每个目的地都有一个与其相关的超时值，该超时值基于源和目的地比特率之间的比率。当源和目标比特率相等时，超时值为0（不需要）。否则，当端口将数据包发送到目的地时，它会将该目的地LID和超时值放入其静态速率控制表中。超时期限到期后，端口将删除该条目。当条目保留在表中时，端口不再向该目的地发送任何数据包（即，推迟表中未包含的其他目的地的流量）。当表中没有条目时，端口通过将数据包放在适当的VL输出队列中来传输数据包。

寻址（Addressing）

每个端节点包含一个或多个通道适配器，每个通道适配器包含一个或者多个端口。此外，每个通道适配器都包含许多队列对（QP）。

每个QP具有由通道适配器分配的队列对编号（QPN），该队列对编号唯一地标识通道适配器内的QP。每个端口有两个众所周知的QP（QP0和QP1），所有其他QP都配置为通过特定端口进行操作。对于可靠的数据报服务，决定端口的是EE上下文而不是QP上下文。

原始数据报以外的数据包包含目标QP的QPN。当信道适配器接收到数据包时，它使用目标QPN(和EE上下文用于可靠数据报)的上下文来处理该分组。

每个端口都有由本地子网管理器(即子网管理器)分配的本地ID(LID)。在子网中，LID是唯一的。交换机使用LID在子网内路由数据包。本地子网管理器根据LID和该端口相对于特定交换机的位置配置交换机中的路由表。每个数据包都包含一个源LID(SLID)，用于标识将数据包注入子网的端口，以及一个目的LID(DLID)，用于标识结构将在其中传递数据包的端口。

IBA还通过定义LID Mask Control(LMC)在物理端口中提供多个虚拟端口。LMC指定在验证数据包DLID是否与分配的LID匹配时，物理端口屏蔽(忽略)的LID的最低有效位的数目。这些位不会被交换机忽略，因此子网管理器可以基于这些最低有效位编程通过Fabric的不同路径。因此，该端口似乎是2^LMC端口，用于跨Fabric路由。

每个端口还至少有一个IPv6地址格式的全局ID(GID)。GID是全局唯一的。每个数据包可选地包含一个全局路由报文头(GRH)，指定一个源GID(SGID)，该源GID(SGID)标识将数据包注入到结构中的端口，以及一个目标GID(DGID)，该目标GID标识结构将在其中传递包的端口。路由器使用GRH在子网之间路由数据包。交换机忽略GRH。

每个通道适配器都有一个全局唯一标识符(GUID)，称为由通道适配器供应商分配的节点GUID。它的每个端口都有一个端口GUID，也是由通道适配器供应商分配的。端口GUID与本地子网前缀组合在一起成为端口的默认GID。

子网管理为LID/GID解析服务提供GUID。因此，一个节点可以通过记住一个节点或端口GUID来持久地标识另一个节点。

QP的地址是端口地址(GID+LID)和QPN的组合。为了与QP通信，需要一个信息向量，包括端口地址(LID和/或GID)、QPN、服务级别、路径MTU，以及可能的其他信息。此信息可通过发送到子网管理的路径查询请求获得。

服务ID用于解析QP。有些服务ID是众所周知的(即，某些功能具有指定的服务ID)，有些服务ID在I/O控制器的服务条目列表中公布。子网管理器提供GID/LID解析的GUID，但目标提供QP解析的服务ID作为通信管理过程的一部分。

一般来说，请求通信消息的目标节点使用服务ID将请求定向到实体，该实体决定是否继续进行通信建立。如果判定是肯定的，则目标返回建立通信所需的信息，其中包括QPN加上特定于传输服务类型的其他信息。

简化的地址解析过程如图20所示。

在图中，目标是一个I/O控制器，在这里发起者通过查询IOC以获得支持的I/O协议列表来学习服务ID。只有当正在建立的服务使用与管理MAD不同的路径特性(SL、QoS、MTU等)时，才需要第二个路径解析。

多播（Multicast）

多播是一种一对多/多对多的通信模式，旨在简化和提高一组终端节点之间的通信效率。

每个多播组由唯一的GID标识。多播将通过一个端口为每个节点提供一个参与管理的端口。这些信息被分发到交换机。每个交换机都配置了多播通信的路由信息，该信息指定了分组需要传输的所有端口。注意确保不存在循环(即，单个生成树使得包不会转发到已经处理该包的交换机)。

节点在它发送给该多播组的所有数据包中使用多播LID和GID。当交换机接收到多播数据包(即，在数据包的DLID字段中有多播限制的数据包)时，它复制该数据包并将其发送到除到达端口之外的每个指定端口。以这种方式，每个级联交换机复制分组，使得分组仅到达每个订阅的端节点一次。

信道适配器可以限制可以为同一多播地址注册的QP的数量。通道适配器将多播数据包分发给为该多播地址注册的QP。一个QP可以为同一个端口的多个地址注册，但是如果使用者希望在多个端口上接收多播流量，则每个端口需要一个不同的QP。信道适配器通过分组的DLID或分组的目的地QP字段中的特殊值来识别多播分组，并将分组路由到为该地址和端口注册的QP。注意，多播数据包中的目的地QP字段不是QPN。

多播示例

图21举例说明了不可靠的多播IBA操作：

• 在IBA路由元件(交换机或路由器)端口接收PSN=1129的数据包。

• 交换/路由组件检查包报文头并提取DLID/多播GID以确定它是否对应于多播组。一个实现可以将该数据维护为其内部路由表的一部分，例如，对应于该分组应转发的输出端口的位掩码。

• 交换机或路由器复制数据包(取决于实现)，并将数据包转发到输出端口。

组管理

IBA没有定义多播组管理协议来实现加入和离开操作。然而，管理接口和相关的MAD用于实现多播组协议被指定。虽然这些机制是子网管理(SA)的一部分，但某些操作是由子网管理器(SM)隐式执行的。在下面的讨论中，术语多播管理实体用于描述SA/SM关于多播管理的预期责任。有关详细信息，请参阅多播成员记录的子网管理属性。

组播组创建

多播组的创建是IBA中的一个显式操作，目的是提供对组特征的单一控制，并允许成员进行颠覆性的加入。在能够成功加入组之前，必须由多播管理实体创建组：

1） (管理)应用程序定义(或确定)目标多播组地址(GID)。它指定特定的组特征(PMTU、P-Key等)，并通过调用多播管理实体的多播组创建(multicast group create)来创建多播组。此应用程序可以请求特定的多播GID或为其分配一个。

2）多播管理实体可以通知正在创建的新组(IBA V1.1中未定义)的子网上的适当路由器。路由器协议应该确定这个多播组是否在另一个子网中运行。如果是，路由器返回现有多播组的PMTU，以确定是否允许创建。

3）多播管理实体将多播组地址映射到多播LID。

组播组加入

多播组加入算法(适用于IBA不可靠数据报多播组)定义如下：

1. 应用程序定义或确定目标多播组地址并调用多播加入操作。
2. 底层join实现确定关联的端节点是否参与多播组。如果是，应用程序将建立一个新的本地QP并执行加入该组所需的步骤。否则，应用程序将调用管理接口与多播组管理实体通信。
3. 多播管理实体在接收到加入请求时执行以下步骤：

——a) 验证多播组地址——如果无效，则加入操作失败。

——b) 验证请求的PMTU——加入操作失败(如果无效)。

——c) 验证连接到端节点的交换机是否能够进行多播操作。交换机可以通过数据包复制支持多播操作，也可以配置为将所有多播数据包发送到端节点连接端口。

——d) 如果多播组地址当前在此子网内运行，请执行以下操作：

————i) 验证参与此多播组的所有交换机和路由器都能支持请求的PMTU。如果不能，则加入操作将失败。

————ii)每个多播组通过在参与交换机之间定义逻辑路由树来实现。重新生成/修改路由树以包含新的端节点。多播管理实体通知结构管理更新所有交换机和路由器中的关联路由转发表，以反映此新拓扑。

——e) 如果多播组地址不在此子网内运行，请执行以下步骤。

————i) 通知此子网内的每个路由器加入操作。路由器协议应该确定这个多播组是否在另一个子网中运行。如果是这样，路由器返回现有多播组的PMTU，以确定是否允许创建和后续的加入操作。

————ii)将多播组地址映射到未使用的多播LID。

————iii)建立多播路由树，并相应地更新相关的交换机和路由器路由转发表。

————iv)创建组并将PMTU分配给多播组。

————v) 将多播LID和相关的组特征返回到端节点，并允许多播操作启动。

——f) 此子网中的每个路由器都被通知成功的多播加入操作。路由器调用适当的多播组管理操作来添加此子网作为参与关联多播组的成员。本协议不符合IBA规范。

4. 将成员添加到组中。

退出多播组

当应用程序离开多播组时，将使用以下算法：

1. 应用程序的QP作为多播组的目标被删除。如果仍有QP参与该多播组，则无需进一步操作。
2. 如果在这个端口上没有更多的QP在多播组中参与，则退出实现通知多播管理实体该端节点不再参与该多播组。多播管理实体执行以下步骤：

——a) 更新交换机和路由器路由转发表，以有效地删除此端节点作为与此多播组关联的数据包的目标。

——b) 从组中删除成员。

删除多播组

当(管理)应用程序认为不需要多播组或没有其他端节点参与多播组时，可以删除该多播组。在接收到删除请求时，多播管理实体采取以下步骤：

1. 从多播组地址取消多播LID的映射。
2. 通知此子网中的每个路由器此子网不再参与关联的多播组。

多播删减

为了提高结构效率，多播组管理实体应定期验证参与多播组的所有终端节点和路由器仍在参与，如果没有，则应通过执行多播组离开算法将它们从多播组中删除。验证周期不在IBA的范围内。

Verbs

IBA描述了主机通道适配器和该主机通道适配器提供的I/O服务的使用者之间的服务接口。向使用者公开的所需行为由一组称为Verb的语义来描述。Verbs描述基于向通道适配器提交工作请求并返回完成状态的特定队列模型在主机通道适配器和使用者之间发生的操作。

Verbs的目的不是指定API，而是充分描述接口，以允许定义API，从而允许I/O服务的使用者充分利用该体系结构。

翻译自《InfiniBand IB.Specification.Vol.1-Release-1.4-2020-04-07.3》3.5节。

1. 除了为原始数据报服务类型配置的QP0、QP1和QPs。 ↩