当前位置：首页 > RDMA > 正文

【Infiniband手册】第7章：链路层

RDMA
2022-10-25
4294
更新：2022-10-26 11:06:38

# 7.1 概述

本章描述链路层的行为，并指定连接到IBA网络的设备的链路级操作。链路层在**包级别**处理跨链路的数据发送和接收。**链路层提供的服务包括寻址、缓冲、流量控制、错误检测和交换。**

本规范使用状态机将链路层的逻辑操作定义为外部可见。它们并不打算定义实施的内部细节。例如，分组接收器状态机以字节流的形式对从链路层接收到的数据进行操作，尽管预期链路层的许多实现将并行处理数据流的多个字节。

## 7.1.1 状态机约定

描述状态机是为了提供对设备外部行为的清晰描述。它们的描述并不意味着IBA设备的内部实现。实际实现必须考虑其他因素，例如效率和对实现技术的适用性。

本章中的状态机使用以下约定：

<span>◼ </span>每个状态用方框表示。

<span>◼ </span>方框顶部包含状态名称。

<span>◼ </span>动作发生在方框底部的状态。

<span>◼ </span>转换箭头表示满足箭头旁边的表达式时将进行的状态转换。

<span>◼ </span>并非源自某个状态的转换箭头表示全局转换。无论当前状态如何，都会发生这种转换。例如，在图50中，有一个到LinkDown状态的全局转换。

<span>◼ </span>如果不满足状态的退出条件，机器将保持当前状态。

<span>◼ </span>“Or”用“+”表示。

<span>◼ </span>“And”用“*”表示。

<span>◼ </span>状态图表示其所描述功能的主要规范。当状态图和描述性文本之间存在冲突时，状态图优先。

# 7.2 链路状态

**C7-1**：本合规声明已过时，已由C7-1.1.1替换。

**C7-1.1.1**：端口应控制其状态和整体操作，如图50链路状态机和**第7.2.7节“状态机术语”**所示。

子网管理使用状态LinkInitialize和LinkArm来配置子网上的设备。有关如何使用这些状态的更多信息，请参阅**第14.3.6节"端口状态更改"**。

链路状态机如图50所示。以下是此状态机的状态描述。

## 7.2.1 LINKDOWN状态

在LinkDown状态下，物理链路没有启动（即，物理层正在向链路层发送phy_link=down），链路层空闲。在这种状态下，链路层丢弃提交给它进行传输的所有数据包。

## 7.2.2 LINKINITIALIZE状态

在LinkInitialize状态下，物理链路启动（即，物理层正在向链路层发送phy_link=up），链路层只能接收和发送子网管理包（SMP）和流控制链路包。在这种状态下，链路层丢弃接收到或呈现给它以供传输的所有其他分组。

## 7.2.3 LINKARM状态

在LinkArm状态下，物理链路处于开启状态，链路层可以接收和发送SMPs和流控制链路包。另外，链路层可以接收所有其他分组，但是丢弃呈现给它以供传输的所有非SMP数据分组（注：意思是能接收分组不能发送分组）。

把分组从LinkArm移动到LinkActive的交换机端口也可以是该分组的输出端口。在VCRC检查数据包之前，端口不会被激活。一个数据包应该能够通过网络，使其路径上交换机上的所有待命（armed）端口都转换为活动端口。因此，当此类数据包转发到尚未转换为活动的端口时，不要丢弃该数据包。

**C7-1.a1**：交换机应确保使其输出端口从待命状态转换为活动状态的数据包不会被端口丢弃。交换机端口可以在处于待命状态时启用数据包的传输。

## 7.2.4 LINKACTIVE状态

在LinkActive状态下，物理链路处于开启状态，链路层可以发送和接收所有分组类型。

## 7.2.5 LINKACTDEFER状态

当物理层指示链路出现故障时，从LinkActive状态进LinkActDefer状态入。如果错误仍然存在，LinkDownTimeout将过期/超时，端口状态将转换为LinkDown状态。如果物理层在LinkDownTimeout过期之前恢复，端口状态机将返回到LinkActive状态。当处于LinkActDefer状态时，链路层将不发送或接收数据包。它可以像在相应的状态下那样处理已经接收到的包。它将丢弃提交给它进行传输的数据包。

此状态的目的是允许重新训练物理链路，而不需要重新初始化链路和更高层。

## 7.2.6 管理状态变更命令

管理层可以通过向PortInfo中的link端口状态发送set请求来发送命令，试图更改链路状态。在状态图中，这些命令被指定为CPortState=<something>，其中<something>为Down、Arm或Active。发出这些命令并不总是导致到该状态的转换。这在状态机图中得到了说明，其中链路必须首先处于正确的状态才能响应这样的命令。例如，状态图指示命令CPortState=Acitve只能在当前链接状态为LinkArm时导致转换到LinkActive状态。

**C7-2**：除Down、Arm或Active以外的任何管理状态更改命令都不会导致状态更改。

**C7-3**：在当前状态下无效的管理状态更改命令不会导致状态更改。

注意，发出无效的管理状态更改命令（即不引起状态变化）不一定意味着错误。例如，在LinkActive状态下发出CPortState=Active不应导致状态转换，并且可能会报告为错误，也可能不会报告为错误（有关错误的讨论，请参阅**第14.2.6.6节“SMP属性组件错误"**（status_field[4:2]=0x7））。

## 7.2.7 状态机术语

**Reset**——复位接口的内部信号。

**Remote_init**——已收到带有流控制初始化操作代码的链接数据包（见**第7.9.4节“流控制数据包”**），并通过了链路数据包检查状态机的检查。

**Active_enable**——防止从待命状态过早转换到活动状态的标记。当退出LinkInitialize状态时，它被设置为false。当接收到具有正常流控制操作码的链路包并在处于LinkArm状态时通过了链路包检查状态机的检查时，它被设置为true。

**PhyLink**——物理层的物理链路状态，phy_link，物理层的概念（请参阅**第6.3.1.1节“PHY_LINK-物理链路状态”**）。有效值为Up和Down。

PortState-PortInfo属性的PortState组件的值。（参考**第14.2.5.6节“PortInfo”**。）有效值为“Down”、“Initialize”、“Arm”和“Active”。

**CPortState**—一个值，指示管理层更改端口状态的命令。有效值为“Down”、“Arm”和“Active”。注意，当phy_link=up和CPortState=down时，状态机将转换到LinkDown状态，这将重置其他链路状态机。由于phy_link=up，这之后将转换到LinkInitialize状态。因此，提供了一种更改链路状态的方法。要禁用端口，需要向物理层端口状态机发出命令。CPortState的值只应在收到它的状态中保持。如果它满足从该状态的一个转换项，它将导致转换。如果没有，则不会导致转换。任何状态转换都会清除CPortState。

**DataPktXmitEnable**-一个布尔值，指示链路层与非SMP数据包的传输有关的操作。如果为True，则启用非SMP数据包的传输。当为False时，将丢弃提交到链路层进行传输的非SMP数据包。

**DataPktRcvEnable**-一个布尔值，指示链路层从物理层接收非SMP数据包的操作。如果为True，则启用非SMP数据包的接收。如果为False，则丢弃从物理层接收的非SMP数据包。

**SMPEnable**-一个布尔值，指示链路层与子网管理包（SMP）的传输和接收有关的操作。如果为真，则启用SMPs的发送和接收。当为False时，提交给链路层用于传输或接收的SMP被丢弃。

**LinkPktEnable**-一个布尔值，表示链路层与链路包的传输和接收有关的操作。如果为True，则启用链路数据包的传输和接收。当为False时，链路层不生成链路包，并且丢弃接收到的任何链路包。

**ForwardInArm**-一个布尔常量，指示在Arm状态下是否启用数据包的传输。对于CA，这将等于False。交换机可以选择使用False或True。

RcvInArm-一个布尔常量，指示在Arm状态下是否接收数据包。对于CA，这应等于True。对于交换机，所有端口都将设置为True，但ESP0（如果支持）除外，后者将被设置为False（这是为了保证在ESP0处于待命状态时，此ESP0后面的虚拟CA将无法将非VL15数据包注入到Fabric中。这相当于一个独立的CA在Arm状态时通过其自己的端口状态来表现的方式。由于ESP0后面的虚拟CA没有自己的端口状态，此机制基于交换机ESP0的端口状态来防止非VL15数据包的注入。

**ActiveTrigger**-一个设备相关触发器，用于启动从LinkArm到LinkActive的转换。对于路由器和信道适配器，ActiveTrigger在接收到通过端口上的VCRC检查的非VL15包时发生。对于路由器和通道适配器，ActiveTrigger只在接收包的端口上生成。

对于交换机，ActiveTrigger在接收到通过交换机任何端口上的VCRC检查的非VL15数据包时发生。请注意，对于交换机，接收数据包的端口可以处于活动状态或已防护状态，并且将为交换机上处于防护状态的所有端口（包括增强型端口0）生成ActiveTrigger。

**LinkDownTimeout**——表示物理链路断开（LinkDown）状态的超时时间。当端口状态机连续处于LinkActDefer状态10毫秒+3%/-51%时，会发生LinkDownTimeout。

# 7.3 分组接收机状态

**C7-4**：本合规声明已过时，已由C7-4.1.1替换:。

**C7-4.1.1**：每当物理链路接通时，数据包接收器应处理来自物理层的接收流，如图51分组接收器状态机所定义。

分组接收器的主要输入是rcv_stream（参见**第6.3.1.3节“RCV_STREAM-接收流”**）。请参阅IBA规范第二卷中的链路/物理接口章节，了解rcv_stream=idle的定义以及出现在状态机中的数据。（需要注意的是，对于IBA版本1.1及更早版本中定义的Phy，从数据pkt receive和link pkt receive状态不能出现rcv_stream=idle转换情况。此转换术语仅适用于在接收器处提供空闲显式通知的Phy。）**分组接收器监视来自物理层的接收流rcv_stream，并将接收到的具有适当分隔符且没有代码冲突的任何分组传递给链路分组检查或数据包检查（视情况而定）**。rcv_ stream的每个字节由状态机测试一次，最多导致一次状态转换。例如，当SLP导致从RcvDataPacket到BadPacket的转换时，该SLP不会导致从BadPacket到RcvLinkPacket的进一步转换。

虽然这个逻辑状态机表示一旦接收到结束分隔符，就将整个数据包发送到数据包检查器，但允许实现在这之前开始处理数据包。当处于RcvDataPacket状态时，如果数据包通过了数据包检查状态机的所有检查（这些检查要求在失败时丢弃该数据包），则交换机和路由器可以开始转发该数据包。所需的检查均基于LRH内的字段。如果对分组的进一步处理导致到标记的BadPacket或BadPacket状态的转换，并且交换机或路由器已经开始转发分组，则交换机或路由器应损坏（破坏）该分组。

**C7-5**：为了损坏数据包，交换机或路由器应将为传输数据包计算的VCRC的1的补码放在VCRC字段中，并用EBP分隔符终止数据包。

**o7-1**：当损坏一个数据包时，交换机或路由器可能会截断数据包，而不是发送所有接收到的字节。

**C7-6**：如果交换机或路由器转发的损坏数据包的长度超过LRH的“数据包长度”字段所示的长度，则应将该数据包截断为小于或等于“数据包长度”字段值。

**C7-7**：除非CA已经通过了数据包接收器和数据包检查状态的所有检查，否则CA不应向其客户端发送接收到的数据包机器。因此，当状态中的操作为“丢弃或损坏”时，CA应丢弃该包。

没有正确的起始分隔符的数据包会导致进入错误的数据包丢弃状态并被丢弃。接收到的带有一个或多个rcv_stream=error字节或没有正确的结束定界符的数据包会导致进入错误的数据包状态，并被CAs丢弃并被交换机丢弃或损坏。导致进入坏包丢弃和坏包状态的错误表明本地链路上发生了错误。接收到的数据包没有字节rcv_stream=error、数据包起始分隔符（SDP）和错误的数据包结束分隔符（EBP）表示交换机转发的数据包发生了不在本地链路上的错误。这些数据包导致进入标记bad pkt的状态。由于链路数据包不是由交换机和路由器转发的，所以它们不应该有错误的数据包结束分隔符。起始分隔符为SLP、结束分隔符为EBP的数据包被视为本地链路错误，并导致进入错误的数据包状态。

# 7.4 数据包检查

CA中的数据包检查机在将数据包传递到网络层之前对其进行验证。交换机或路由器端口中的数据包检查机验证接收到的数据包。

**C7-8**：本合规声明已过时，已由C7-8.1.1:。

**C7-8.1.1**：应按照图52数据包检查机和第7.4节“数据包检查”的规定检查数据包。此状态机中的检查顺序指示报告错误的优先级，而不一定指示检测错误的顺序。

例如，大多数实现将在分组开始后不久检测到无效的VL，并且直到分组结束时才检测到CRC错误。然而，CRC错误首先在状态机中检查，因为如果这两个错误都发生，CRC错误表示数据包已损坏，应该报告该错误，而不是VL错误。

**C7-9**：交换机或路由器应对以交换机或路由器为目的地的数据包（如发往交换机或路由器的管理包）执行与CA相同的检查。

CA中的数据包检查机将数据包传递到排队的接收方。参见**第18.2.5.2节“接收器排队”**。

**C7-10**：如果一个数据包未能通过在数据包检查状态机的状态下的任何测试并以“discard”结束，则交换机、路由器和CA应丢弃该数据包。

C7-11：对于仅在指定“损坏或丢弃”操作的数据包检查状态机状态中丢弃的测试失败的数据包，CA应丢弃该数据包，交换机或路由器应丢弃或损坏该数据包，如**第7.3节“数据包接收器状态”**所述。

交换机或路由器的链路层只需要检查发送到该交换机或路由器的数据包上的ICRC。在所有其他数据包上，交换机或路由器可以通过返回ICRC_check=good而忽略ICRC检查。

**接收长度是SDP和EGP之间的字节数**。MTU是PortInfo.MTUCap. 原始数据包的最小长度为5，IBA传输数据包的最小长度为6。参见**第7.7.8节“数据包长度（PktLen）-11位”**。

除上述检查外，如果DLID是多播LID，CA可以选择检查是否为此CA配置了DLID。如果CA执行此检查，且如果没有为此CA配置DLID，则dlid_check结果可能无效。因此，如果没有为此CA配置特定的DLID，则在0xC000到0xFFFE范围内的DLID可能会被CA声明为无效。

# 7.5 链路包检查

当前定义的唯一链路包类型是流控制包。见**第7.9.4节“流量控制包”**。

C7-12：在将链路包传递给流量控制之前，端口应按照图53“链路包检查机”和**第7.5节“链路包检查”**的规定验证链路包。

在初始化过程中，活动VL的数量可能尚未配置，因此接收不支持的VL的credits只是处于活动状态时的错误。

# 7.6 虚拟通道机制

虚拟通道（VLs）提供了在单个物理链路上实现多个逻辑流的方法。链路级流量控制可以应用于一个通道，而不会影响其他通道。表16总结了VLs的关键属性。

**C7-13**：InfiniBand协议感知设备应符合表16中标记为所需VLs、缓冲和排序的行所定义的要求。

**o7-2**：实现多个数据VL的InfiniBand协议感知设备应符合表16中标记为流控制的行所定义的要求

## 7.6.1 VL标识

**C7-14**：InfiniBand协议感知设备的发送端口应使用拟使用的虚拟通道标识每个数据包，该信息在链路头的**4位VL字段（VL Field）**中携带。此外，本地路由报头应包含4位服务级别（SL）。

SL字段（SL Field）的使用见**第7.6.5节**。

## 7.6.2 支持的VLS数量

**C7-15**：InfiniBand协议感知设备应符合表17，VL编号和配置行定义的要求

**C7-16**：InfiniBand协议感知设备的所有端口应支持VL15。此外，所有端口应支持数据VL0。

**o7-3**：端口可以支持多个数据VL。如果有，则应按照表17规定的允许数量进行。

**C7-17**：数据VL应从零开始按顺序编号。因此，如果一个实现支持4个数据VL，它们应编号为0、1、2和3。

## 7.6.3 特殊VLs

VL15是一种特殊的VL，必须由所有端口支持。以下列出了VL15的特性：

**C7-18**：VL15不受流控制（链路级和端到端），即VL15数据包可以随时发送。

**C7-19**：如果没有足够的接收空间，InfiniBand协议感知设备应丢弃VL15数据包。除了包丢弃计数器（**第16.1.3.5节“PortCounter”**），此丢弃是静默进行的。

**C7-20**：所有InfiniBand协议感知设备应支持VL15数据包的发送和接收(sourcing and sinking)。

**C7-21**：CA和路由器应在每个端口上为VL15在每个端口上提供至少一个单独的包缓冲区，以便接收。

**C7-22**：交换机应为每个交换机的VL15提供至少一个单包缓冲区。

**C7-23**：VL15数据包应预先（preemptively）调度，即在所有其他数据包（包括流控制数据包）之前传输。

**C7-24**：交换机中的VL映射不适用于VL15。也就是说，VL15上的交换机接收到的数据包应在VL15上传输，而在另一个VL上接收的数据包不得在VL15上传输。

**C7-25**：此符合性声明已过时并已删除。

VL15数据包的**源设备**应将SL字段设置为0，而检查和接收VL15数据包的设备应忽略SL字段。

**C7-26**：VL15数据包不应在子网之间转发，即它们不应具有GRH，也不应为原始数据包。

**C7-27**：使用VL15的数据包的最大有效载荷应为256个有效载荷字节。

## 7.6.4 数据VLs的缓冲和流量控制

虚拟通道在同一物理链路上提供独立的数据流。

对于数据VLs，应提供单独的保证性的缓冲资源(guaranteed buffering resources)和单独的流量控制。（对于VL15，应用不同的流量控制和缓冲限制，并在上文中描述。）

**C7-28**：对于数据VLs，每个端口上的每个VL应提供独立缓冲资源的外观，即虽然不需要专用的缓冲资源，但端口的行为必须与它们一样。

**C7-29**：每个端口应通告其使用流控制包配置的每个数据VL可用的信用数量。

这些信用包和流量控制流程在**第7.9节“流量控制”**中进行了说明。

表18链路分组的处理详细说明了端口在发送和接收给定数据VL的链路分组时的行为。本表（以及本规范其他部分）中使用了以下术语：

<span>◼ </span>如果数据VL的VL编号在PortInfo.VLCap属性指示的范围内，则支持数据VL。说明该端口支持数据VL。

<span>◼ </span>如果数据VL的VL编号在PortInfo.OperationalVLs属性指定的范围内，则配置数据VL。这表明数据VL目前被配置为由端口使用。

（请参阅**第14.2.5.6节“PortInfo”**了解PortInfo..VLCap以及PortInfo.OperationalVLs的描述.）

**C7-30**：每个端口应发送和接收链路数据包，如表18“链路数据包处理”所述。

注意，在本表中，对于支持数据VL但当前未配置的情况，尚未指定所需的行为。这是为了支持更改数据VL配置。进一步注意，数据VL配置可以在任何端口状态下改变，包括LInkActive。还应注意的是，在LinkActive状态下更改数据VL配置可能会导致生成FlowControlUpdateErrors，而FlowControlUpdateErrors又会导致LinkActive和LinkActiveDefer状态之间的转换，并影响性能计数器LinkErrorRecoveryCounter的值。

**C7-31**：每个端口应为每个配置的数据VL提供足够的缓冲，以便能够为至少一个具有MTU有效载荷的包通告信用。

注意，这里的MTU有效载荷是指该端口的MTUCap和neighborMTU中的较小者（见**第7.7.8节“数据包长度（PktLen）-11位”**，以了解相应的数据包大小要求的定义）。

**C7-32**：当数据包到达端口时，应将其放在与该输入端口和数据包中VL字段相关联的缓冲区中。

## 7.6.5 服务水平(SL)

服务级别（SL）用于标识IBA子网中的不同流。它被**携带在包的本地路由报头中**。

**C7-33**：当数据包跨越子网时，不应更改数据包的SL。

SL是关于分组的服务类别的指示。IBA不赋予SL值任何特定含义。SLs旨在作为一种机制来帮助提供差异化服务、提高fabric利用率和避免死锁。但是，关于如何实现这一点的细节超出了本规范的范围。

然而，IBA规范确实定义了两种使用SLs和VLs的机制，这两种机制被用作实现服务质量（QoS）相关服务的工具。一种是SL到VL的映射，另一种是数据VL仲裁。下面将详细介绍这两种方法。

**o7-4**：如果支持多个数据VL，则必须同时支持SL到VL映射和数据VL仲裁（两个都在下面描述）。

注意，如果只支持一个数据VL，那么SL到VL的映射仍然可以用于SL过滤(SL filtering)——请参见**第7.6.6节“子网内VL映射”**）。

**C7-34**：SLs和VLs对仅支持单个数据VL的设备的唯一要求是：当向IBA子网提供数据包时，设备应在SL字段中包含SL值。

请注意，此设备列表中包含交换机，因为它们可以通过SMI或GSI接口作为数据包的源。还请注意，本规范不要求在分组目的地验证SL字段。

不同SL的数据包之间没有排序保证。

不同传输服务的SL来源详见**第9.10节“报头和数据字段来源”**。对于连接的服务（不可靠连接、可靠连接和可靠数据报），与同一连接的正向和反向路径相关联的SL可能不同（即在同一连接上，DeviceA:transmitWQ可能与DeviceB:transmitWQ不同). 然而，对于不可靠的原始数据报，节点总是可以使用与原始数据报相同的SL来响应来自其他节点的数据报。

用于给定目的地（DLID）、QOS、分区等的SL最终由子网管理器提供。它也可以来自派生源(derived sources)，如请求包、本地管理代理等。

## 7.6.6 子网内VL映射

当数据包在子网中路由时，它可能在使用给定链路时需要更改VLs。可能需要的示例包括：

1） 链路可能不支持分组先前使用的VL。当Fabric中的设备支持有限的VL集时，可能会发生这种情况。

2） 到达交换机的不同输入端口的两个业务流可以使用相同的出站链路，并且在到达交换机时也可能碰巧使用相同的VL。如果不支持VL映射，则两个流量流必须在输出端口上使用相同的VL。VL映射允许在出站链路上为这两个流分配不同的VL。一般来说，VL映射在保持Fabric内的独立业务流方面提供了更大的灵活性。

**SL-to-VL映射**用于在数据包穿过子网时更改VLs。

在支持多个数据VL的信道适配器、交换机和路由器中，需要SL到VL的映射。在那些只支持一个数据VL的设备中，它是可选的。如果实施，则应按照本节要求执行。

SL到VL的映射是使用**可编程映射表**完成的。这是由SLtoVLMappingTable提供的。

**o7-5**：在支持SL到VL映射的信道适配器和路由器中，应该有一个逻辑表，将包LRH中的SL字段映射到用于该输出端口的VL。这个表有16个条目，设备的每个端口都有一个独立的表。本表应包括所有16个可能的SL值。该表显示了当该数据包通过端口传输时要使用的VL号。

**o7-6**：在支持SL到VL映射的交换机中，应该有一个逻辑表，该表将包的SL、输入端口和输出端口映射到下一跳使用的VL。

最好将此表视为一组表，每个输出端口一个。然后，每个输出端口表都根据其SL字段和到达的端口来指示出发包应该使用哪个VL。由于交换机支持一个**内部端口**（请参阅**第18.2.4.1节“交换机端口”**），该端口也需要将源数据包进行VL映射，因此**该端口**作为输入端口之一包含在表中。有关表大小和布局的详细信息，请参阅**第14.2.5.8节“SLtoVLMappingTable”**。

**o7-7**：本合规声明已过时，已被删除。

该表根据分组SL、输入端口和输出端口指示该分组用于下一跳传输的VL。

此表提供了从n+1个输入端口（包括内部端口）到n个输出端口的映射关系。

有关SLtoVLMappingTable的详细信息，请参阅表159“SLtoVLMappingTable”。

**o7-8**：实现SL到VL映射的设备应如表19所示。

支持的VLs数量由PortInfo属性的VLCap组件定义，而配置的数量由PortInfo属性的操作VLs组件定义。（参考**第14.2.5.6 节“PortInfo”**了解PortInfo.VLCap以及PortInfo.OperationalVLs.）

注意，SLtoVLMappingTable可以用VL15编程，用于没有授权使用该端口（用于信道适配器和路由器）或输入输出端口路径（用于交换机）的任何SL。如上表所示，如果SLtoVLMappingTable返回VL15，则丢弃数据包。此过滤旨在作为一种机制来帮助防止未经授权使用SLs，并帮助打破路由依赖循环（从而避免路由死锁）。

## 7.6.7 初始化和配置

为了允许设备构建不同数量的VL，SM必须能够配置在给定链路上使用的VL的数量。SM可以查询每个端口以确定其支持的VL数量，然后配置为链路上两个端口都支持的数量。表17描述了每个设备必须支持的VLs组合的数量。支持的VL数量由PortInfo.VLCap组件定义，而配置的VL数量由PortInfo.OperationalVL定义（请参阅**第14.2.5.6 节“PortInfo”**）。

端口可以配置为1、2、4、8或15个VL，并且必须配置为等于或小于支持数量的值。如果试图将OperationalVLs编程为大于VLCap的值，端口可以使用任何有效值加载OperationalVLs。

端口的发送和接收方向必须配置相同数量的VL。

可以在端口运行时修改SLtoVLMappingTable。

**o7-9**：如果一个端口实现了从SL到VL的映射，则不允许由于更改SLtoVLMappingTable内容而导致的对传输中的任何数据包进行分片（再次分片）。

但是，在这种改变过程中，数据包可能会被丢弃或映射错误。

当通道适配器、路由器或交换机初始化时，不需要初始化SLtoVLMappingTable（即内容未定义）。在数据流量使用表之前，该表应由SM初始化。

## 7.6.8 VL15和流量控制包的VL调度和流量控制

VL15（即子网管理数据包）流量和流量控制数据包将使用**抢占式调度(preemptive scheduling)**。优先级顺序如表20所示。

## 7.6.9 VL仲裁和优先级

VL仲裁是指对交换机、路由器或信道适配器上的传出链路进行的仲裁。每个输出端口都有一个独立的仲裁器。仲裁器从该端口上可供传输的候选分组集合中选择下一个要传输的分组。

**C7-35**：仲裁器不得违反数据包排序规则，即给定VL上的数据包不得重新排序。

下面描述VL仲裁器要使用的算法。

### 7.6.9.1 仅实施一个数据VL时的VL仲裁方式

表20描述了仅实现单个数据VL的交换机、路由器或信道适配器的仲裁规则。这是一个简单的优先级方案，其中高优先级级别的所有数据包在较低优先级级别的任何数据包之前发送。

o7-10：**仅实现单个数据VL**的设备应使用表20“仅具有一个数据VL的设备的仲裁规则”中描述的仲裁规则在其输出端口上传输数据包。

### 7.6.9.2 执行多个数据VL时的VL仲裁

多数据VLs的实现是IBA的可选功能。但是，如果实施了这些措施，则实施应符合本节详述的规范。

**o7-11**：对于实现一个以上数据VL的设备，VL15包和流控制包的传输应与表20所示相同，但此处所有数据VL的优先级低于VL15（最高优先级）和流控制包（第二高优先级）。

**o7-12**：实现多个数据VL的设备还应实现**第7.6.9.2节**中描述的在数据VLs上的分组之间进行仲裁的算法。

采用了两级调度方案，在加权公平方案的基础上采用了抢占式调度。此外，该方案还提供了一种保证低优先级VLs向前推进的方法。权重、优先级和最小前向进度带宽都是可编程的。

VL仲裁由VLArbitrationTable控制（参见**第14.2.5.9节“VLArbitrationTable”**）。本表由**高优先级、低优先级和高优先级限制**三部分组成。**高优先级和低优先级**组件都是VL/权重对的列表。高优先级列表的最小长度为1，最大长度为64。低优先级列表的最小长度应等于支持的数据VL数量，最大长度为64。允许高优先级和低优先级组件列表具有不同的长度。

**每个列表条目应包含（1）一个VL编号（0-14之间的值）和（2）一个加权值（值0-255），指示当该VL在仲裁中轮到它时可以从该VL传输的64字节单元的数量。**LRH中的PktLen字段用于确定包中的单元数。（注意，VCRC和物理层引入的数据包之间的符号不应包括在VL仲裁权重计算中。）计算应保持为4字节增量。

权重为0表示应跳过此项。

如果为VL15或‘不受支持或端口当前未配置的VL’编程一个列表条目，则端口可以跳过该条目或从任何支持的VL发送该条目（意思是说，没有必要为VL15或这些VL设置列表条目，随便找个条目打发了即可）。

注意，同一数据VL可以在高优先级或低优先级组件列表中多次列出，并且，可以在两个列表中列出。

每个配置的数据VL应至少在一个组件列表中列出。但是，没有要求设备检查这种情况。如果配置的数据VL没有出现在两个组件列表中，则该数据VL的数据包可能会被丢弃，在仲裁器没有数据包要发送或从未发送时发送（三种情况都可能出现）。

高优先级限制组件（Limit of High-Priority）表示在没有机会发送低优先级分组的情况下可以发送的高优先级分组的数量。具体地说，可以发送的字节数是高优先级限制乘以4K字节（二者相乘），计数方法与上面描述的按权重方式相同（即，计算以4字节为增量，如果当前字节计数没有超过高优先级限制，则可以发送高优先级包）。**值255表示字节限制是无限的。**（注意，如果使用255值，此仲裁方案不能保证低优先级数据包的转发进度。）值为0表示在给低优先级表分配机会之前，只能发送来自高优先级表的单个数据包（高优先级发一次后，就开始发送较低优先级了，不会一直占用）。

当端口处于活动状态时，可以修改VLArbitrationTable。此修改不得导致对传输中的任何数据包进行切片。然而，在这一变更过程中，可能会违反仲裁规则。

当通道适配器、路由器或交换机初始化时，不需要初始化VLArbitrationTable（即内容未定义）。在数据流量使用表之前，该表应由SM初始化。

#### 7.6.9.2.1 VL15、链路控制和数据VL包之间的仲裁规则

表20的规则适用，其中数据VLs（VL0-VL14）具有最低优先级。

#### 7.6.9.2.2 数据VL包仲裁规则

当没有VL15或流控制包要发送时，本节中的仲裁规则适用。

#### 7.6.9.2.3 高优先级组件和低优先级组件之间的仲裁规则

高优先级组件和低优先级组件形成两级优先级方案。这些组件(或表)中的每一个都可能有一个可用于传输的包。如果以下测试成功，则数据包可以从高优先级表中传输：

对于高优先级表中的每个条目，确定是否：

1）VL字段与当前正在等待此端口传输的任何数据包的VL字段相匹配，并且

3）有可用的信用来发送该数据包

权重为0的条目被认为不在列表中。

注意，在确定包是否可用时，实现可以检查HiPriAvailWeight是否可用。

完成数据包传输后，应进行以下测试，以确定使用哪个表来传输下一个数据包：

如果高优先级表具有可用于传输的分组（如上所定义），并且HighPriCounter没有过期，则称高优先级是活动的，并且可以从高优先级表发送分组。

如果高优先级表没有可用于传输的数据包（如上所定义），或者如果高优先级计数器已过期，则应重置高优先级计数器，低优先级表被称为活动的，并且可以从低优先级表发送数据包。

用以下规则管理HighPriCounter的操作：

1） 当HighPriCounter的当前值为负数时，HighPriCounter将过期。

2） 如果高优先级限制组件中的值不是255，则对于每个发送的高优先级分组，从HighPriCounter的当前值中扣除包的大小（由LRH中的PktLen字段定义）。计算应保持为4字节增量。

3） 当HighPriCounter复位时，高优先级限制值乘以4K字节的值被加载到HighPriCounter中。

#### 7.6.9.2.4 高低组件内的仲裁规则

在每个高优先级或低优先级表中，使用加权公平仲裁，每个表中的条目顺序指定VL调度的顺序，权重值指定分配给该条目的带宽量。按顺序处理表中的每个条目。

两个表中的每一个都维护一个单独的指针和可用的权重计数。指针标识表中的当前项，而可用权重计数表示当前项可用于数据包传输的权重量。当表处于活动状态时（如前一节所定义），将检查表中的当前条目。与此条目相对应的数据包将被发送到输出端口进行传输，如果以下所有条件均为真，则数据包大小（以4字节为增量）将从当前条目的可用重量计数中扣除：

1）列表项的可用权重为正。

2）有一个数据包可用于该VL条目

3）缓冲区信用可用于此数据包。

注意，如果新分组开始时的可用权重为正，则满足上述条件1，即使分组大于可用权重。

当这些条件中的任何一个不为真时，将检查表中的下一个条目。将当前指针移动到表中的下一个条目，将可用的权重计数设置为该新条目的权重值，并重复上述测试。重复此操作，直到找到可以发送到端口进行传输的数据包。如果检查了整个表，并且没有找到满足上述条件的条目，则另一个表将变为活动的。

此描述描述了仲裁过程的逻辑流程，但没有指定性能要求。实现应以与上述描述逻辑一致的方式执行。实现可以并行处理这些步骤，也可以进行管道测试。作为测试流水线的一个例子，如果一个包最近被转发到输出端口，但仲裁器逻辑没有处理它的到达，那么检查是否有可用的数据包可能返回false。

此外，实现不需要实现指针、可用的weight counter和HighPriCounter。但是，它们的行为方式必须与本节所述的方式相同。

# 7.7 本地路由报头 Local Route Header

本地路由标头—LRH—8字节

本地路由报头（LRH）包含IBA子网内交换机本地路由的字段。LRH在每个包的开始处，包以可变CRC结束。LRH的长度为8字节（64bit位）。有关数据包总体格式的更多信息，请参阅**第5章“数据报文格式”**。

**C7-36**：LRH应使用图54本地路由标题（LRH）中规定的格式。

## 7.7.1 虚拟通道（VL）—4位（bits）

指定要用于数据包的虚拟通道。此字段标识接收的数据包应使用哪个接收缓冲区和哪些接收流控制credit。

**C7-37**：VL字段应设置为发送数据包的VL。

虚拟通道可以在子网中从一个链路更改为另一个链路。由于虚拟通道可以改变，所以链路虚拟通道不包含在不变CRC字段中。

## 7.7.2 链路版本（LVER）-4位

指定用于此数据包的本地路由标头的版本。该版本适用于包括LRH字段和可变CRC的一般分组结构。

**C7-38**：LVer字段应设置为0x0。

如果接收设备不支持指定的链路版本，则丢弃该数据包。

## 7.7.3 服务水平（SL）-4位

服务级别字段。交换机使用此字段来确定用于此数据包的虚拟通道。**第7.6.5节**对此进行了说明。

## 7.7.4 保留-2位

**C7-39**：2位保留字段应作为00发送，接收时应忽略。

## 7.7.5 链路下一个报头（LNH）-2位

指定本地路由标头后面的标头。第一位（msb）指示数据包是否使用IBA传输。第二位（lsb）指示是否存在GRH/IPv6报头。

**C7-40**：LNH字段应根据表21“链接下一报头定义”指示后面数据包的数据包类型。

## 7.7.6 目的地本地标识符（DLID）-16位

指定子网将数据包传递到的端口的LID。LID在子网中是唯一的。更具体地说，它标识到目的端口的路由。如果数据包要路由到另一个子网，那么这就是路由器的LID。

## 7.7.7 保留-5位

**C7-41**：5位保留字段应作为00000传输，并在接收时忽略。

## 7.7.8 数据包长度（PKTLEN）-11位

数据包中包含的4字节字的数目。

**C7-42**：PktLen字段的值应等于**从本地路由标头的第一个字节开始的所有字段中的字节数，以及可变CRC之前的最后一个字节，除以4**。

**所有标头加上CRC字段的最大允许大小为126字节**。此字段的最大值为（4096+126-2）/4=4220/4=1055，反映了所有头和CRC的最大126字节减去未计算的可变CRC。注意, IBA的当前版本限制为106字节（即，最长的当前数据包头可能是RD原子操作（LRH+GRH+BTH+RDETH+DETH+AtomicETH+VCRC+ICRC）。额外的允许尺寸是为了将来的扩展。

**C7-43**：对于使用IBA传输的数据包，允许的最小数据包长度值为6（24字节），包括LRH。

**C7-44**：对于原始数据包，允许的最小数据包长度值为5（20字节），包括LRH。

**C7-45**：包长度的最大允许值为表22包大小中MTUCap和NeighborMTU中较小的值。

注意，这个符合性声明定义了数据包的最大大小。根据**第7.4节“数据包检查”**中规定的d_length_check而不是通过PortInfo:MTUCap进行的。

## 7.7.9 源本地标识符（SLID）-16位

**C7-46**：对于所有非定向路由数据包，SLID应为将数据包注入子网的端口LID。

有关定向(directed)路由数据包中DLID的要求，请参阅**第14.2节“子网管理类”**。

子网管理器为每个节点分配一个在子网中唯一的LID。

# 7.8 CRC

## 7.8.1 不变CRC（ICRC）-4字节

指定一个循环冗余码（Cyclic Redundancy Code），覆盖包的所有通过网络上的所有交换机和路由器端到端保持不变的哪些字段。此字段存在于所有IBA数据包中，但在原始数据包中不存在，因为对于原始数据包，不知道哪些字段是不变的。对消息中的每个包重新开始CRC计算。包含哪些报头字段取决于是否存在全局路由报头，因为路由器可能会修改其他报头字段。

**C7-47**：ICRC字段应出现在所有IBA传输包中。

**C7-48**：ICRC字段应按照**第7.8.1节“不变CRC（ICRC）-4字节”**的规定进行计算。

如果数据包是子网的本地数据包（不存在全局路由报头），则ICRC计算如下：

<span>◼ </span>在没有GRH的情况下，ICRC包括：

<span>   </span><span>✸ </span>本地路由头：VL除外。

<span>   </span><span>✸ </span>基本传输报头：除了Resv8a字段

<span>   </span><span>✸ </span>扩展传输标头（如果存在）；

<span>   </span><span>✸ </span>分组有效载荷（如果存在）

<span>◼ </span>如果没有GRH，**ICRC排除**：（这些字段在ICRC计算中被替换为1s）

<span>   </span><span>✸ </span>本地路由报头：VL，

<span>   </span><span>✸ </span>基本传输报头：Resv8a。

如果包在子网之间路由，因此存在全局路由报头，则ICRC计算如下：

<span>◼ </span>对于GRH，ICRC包括：

<span>   </span><span>✸ </span>全局路由报头：版本、有效负载长度、下一个报头、源IPV6地址和目标IPV6地址

<span>   </span><span>✸ </span>基本传输标头，除Resv8a字段外，

<span>   </span><span>✸ </span>扩展传输标头（如果存在）；

<span>   </span><span>✸ </span>数据包有效负载（如果存在）。

<span>◼ </span>对于GRH，ICRC排除：（在CRC计算中，这些字段替换为1）

<span>   </span><span>✸ </span>本地路由标头、所有字段

<span>   </span><span>✸ </span>全局路由标头：流标签、流量类别和Hop限制字段。

<span>   </span><span>✸ </span>基本传输头：Resv8a。

数据包中的所有字段，包括那些排除在不变CRC之外的，由下一节描述的可变CRC保护。

使用的多项式（用于计算CRC）与以太网0x04C11DB7使用的CRC-32相同。计算过程如下：

1） CRC-32计算的初始值为0xFFFFFFFF。

2） CRC计算以大端字节顺序进行，最高有效字节的最低有效位是CRC计算的第一位。

3） 对计算得到的位序列进行补码，得到的结果是ICRC。

4） 从表示余数多项式的最高项的系数的位按顺序发送得到的位。包的最低有效位、最高有效字节优先顺序不适用于ICRC字段。

CRC总是以LRH:LVer位0开始，无论GRH是否存在。

这种位和字节顺序与以太网的CRC计算一致。

## 7.8.2 可变CRC（VCRC）-2字节

指定覆盖数据包所有字段的循环冗余代码。该字段出现在包括原始数据包在内的所有数据包中，并且**包括从LRH的第一个字节到可变CRC之前的最后一个字节的所有字节**。由于这些字段中的许多字段在包被交换机和路由器处理时会发生变化，因此可能必须在通过子网的每个链路上重新生成可变CRC。如果交换机不改变任何字段，包括链路虚拟通道，则不必重新生成可变CRC。

**C7-49**：VCRC字段应出现在所有数据包中。

**C7-50**：VCRC字段应按照**第7.8.2节“可变CRC（VCRC）-2字节”**的规定进行计算。

使用的多项式与HIPPI-6400-0x100B使用的CRC-16相同。计算过程如下：

1） CRC-16计算的初始值为0xFFFF。

2） CRC计算以大端字节顺序进行，本地路由头的第一个字节的最低有效位（第0位LRH：左心室)是CRC计算中的第一位。

3） 对计算得到的位序列进行补码，得到VCRC。

4） 从表示余数多项式的最高项的系数的位按顺序发送得到的位。数据包的最低有效位、最高有效字节优先顺序不适用于VCRC字段。

这种位和字节顺序与以太网的CRC计算一致。

## 7.8.3 链路包CRC（LPCRC）-2字节

指定覆盖链路包的所有字段的循环冗余码。该字段出现在包括流控制链路包在内的所有链路包中，并且包括**从操作码的第一个字节到LPCRC之前的最后一个字节的所有字节**。始终为每个Linkpacket计算此字段。

**C7-51**：LPCRC字段应出现在所有链路包中。

**C7-52**：LPCRC字段应按照**第7.8.3节“链路包CRC（LPCRC）-2字节”**的规定进行计算。

使用的多项式与可变CRC和HIPPI-6400-0x100B使用的CRC-16相同。计算过程如下：

1） CRC-16计算的初始值为0xFFFF。

2） CRC计算以大端字节顺序进行，本地路由头的第一个字节的最低有效位（第0位LRH：LVer)是CRC计算中的第一位。

3） 计算得到的位序列被补，结果是LPCRC；

4）从表示余数多项式最高项系数的位按顺序发送结果位。数据包的最低有效位、最高有效字节优先顺序不适用于LPCRC字段。

这种位和字节顺序与以太网的CRC计算一致。

## 7.8.4 CRC计算举例

下面是CRC计算的一个例子。CRC计算的要求如上所述，本节仅供参考。

### 7.8.4.1 ICRC生成器

用于ICRC计算的多项式是0x04C11DB7。种子值为0xFFFFFFFF。CRC Generator Remainder是对计算结果的补充。没有指定**ICRC生成器**的实际执行情况。图56中的图表仅供参考，其唯一目的是澄清计算细节，并不意味着需要实现。

在每次生成ICRC之前，32个触发器被初始化为1。按照第207页**第7.8.1节**规定的顺序，一次一位地将数据包送入图56的参考设计。剩余部分是在数据包的最后一位被时钟送入ICRC生成器后，32个触发器中存储的值的位非。如图56所示，从余数中获得ICRC字段。ICRC字段像InfiniBand数据包的每个字段一样使用大端字节顺序进行传输。

### 7.8.4.2 VCRC生成器

用于VCRC和LPCRC计算的多项式为0x100B。种子值为0xFFFF。VCRC/LPCRC生成器余数是结果计算的补充。

VCRC和LPCRC的生成方式与上述ICRC相同。图57显示了VCRC/LPCRC发生器的参考设计。

### 7.8.4.3 数据包格式举例

#### 7.8.4.3.1本地数据包示例

图58显示了示例中使用的本地包的结构。该包是一个RDMA Write Only类型, 携带14字节的有效负载。

示例包的报头值分别见表23、表24和表25。数据有效载荷如表26所示。

本地包的组合字节流（在ICRC和VCRC之前）如表27所示。

表28显示了用于ICRC计算的屏蔽（masked）字节流。

生成的ICRC是:0x9625B75A

生成的VCRC是:0x45FA

表29显示了完整的本地分组字节流（Local Packet Byte Stream）。

#### 7.8.4.3.2 全局包示例

图59显示了示例中使用的全局包的结构。

全局示例包的BTH、RETH和数据有效载荷与本地示例包相同。LRH和GRH字段的值如表30和表31所示。

表32显示了全局数据包的组合字节流（在ICRC和VCRC之前）。

表33显示了用于ICRC计算的屏蔽（masked）字节流。

ICRC结果是：0xB67D1ED1

VCRC结果是：0xB148

表34显示了完整的全局数据包字节流。

#### 7.8.4.3.3 链路包示例

链路分组示例的字段值如表35所示。

生成的LPCRC:0xF9C9

# 7.9 流量控制

## 7.9.1 简介

本节描述IBA使用的链路级流控制机制，以防止由于链路两端的接收器的缓冲区溢出而丢失数据包。此机制不描述端到端的流控制，例如，当接收缓冲区未通告时，可以使用这种控制来防止消息的传输。端到端流量控制规范见**第9.7.7.2节“端到端（消息级）流控制”**。

在本节中，术语“发送方/transmitter”和“接收方/receiver”用于描述给定链路的每一端。发送方是获取sourcing数据包的节点。接收方是数据包的消费者。链路的每一端都有一个发送方和一个接收方。

IBA采用基于“绝对”信用的流量控制方案。与许多传统的流量控制方案不同的是，IBA接收方提供了一个“信用限额”，这些方案提供了增量更新，并添加到发送方可用的缓冲池中。信用限额是指自链路初始化以来发送方被授权发送的数据总量。

传输、数据包或流控制信息交换中的错误可导致发送方和接收方感知到的流控制状态的不一致。IBA流量控制机制可从这种情况下恢复。发送方定期发送自链路初始化以来已发送的数据总量的指示。接收方使用这些数据在接收方和发送方之间重新同步状态。

## 7.9.2 流控制块/Flow Control Blocks

术语“流控制块”或简单的“块”表示数据包中的数据量。这个数量被定义为数据包的（以字节为单位）大小（本地路由头和可变CRC之间的每个字节，包括在内）**除以64字节**，然后四舍五入到下一个整数值。

## 7.9.3 与虚拟通道的关系

本章定义的流量控制算法独立应用于每个虚拟通道，但不受链路级流量控制的虚拟通道15除外。

## 7.9.4 流量控制包

**C7-53**：在进入LinkInitialize状态时，应为除VL15以外的每个VL发送流量控制包。当处于LinkInitialize、LinkArm或LinkActive端口状态时，给定虚拟通道的流量控制数据包应在自上次发送给定虚拟通道的流量控制数据包以来65536个**符号时间**之前传输。

**C7-54**：流量控制包应采用图60流量控制包格式中规定的格式。

**符号时间**定义为将8bit数据量传输到物理通道所需的时间，即对于以2.5Gb/s的链路速度运行的链路，符号时间是4nsec，与链路的宽度无关。

流控制分组可以根据需要经常发送，以返回信用并使链路的有效利用成为可能。更多信息见**第7.6.4节“数据VLs的缓冲和流量控制”**。

### 7.9.4.1 流控制包字段

#### 7.9.4.1.1 OPERAND（OP）-4位

流控制数据包是具有两个操作（operan）数之一的链接数据包：操作数0x0表示正常的流控制数据包。操作数值0x1表示流控制初始化数据包。

**C7-55**：在PortState LinkInitialize中，流控制数据包应使用流控制初始化操作数0x1发送。

**C7-56**：在端口状态LinkArm或LinkActive时，应使用正常的流控制操作数0x0发送流控制数据包。

**C7-57**：Op字段的所有其他值保留给IBA将来可能定义的操作。任何接收到的具有保留值的数据包都将被丢弃。

#### 7.9.4.1.2 发送的流控制总块数（FCTBS）-12位

FCTBS（流控制发送的总块数，FLOW CONTROL TOTAL BLOCKS SENT）字段由发送侧逻辑生成。FCTBS值的计算在后面描述。

#### 7.9.4.1.3 流量控制信用额度（FCCL）-12位

FCCL（流控制信用额度，Flow Control Credit Limit）字段由接收方逻辑生成。FCCL值的计算在后面描述。

#### 7.9.4.1.4 虚拟通道（VL）-4位

VL（虚拟通道）设置为应用FCTBS和FCCL字段的虚拟通道。

#### 7.9.4.1.5 链路分组循环冗余校验（LPCRC）-16位

LPCRC（Link Packet Cyclic Redundancy Check）字段是一个16位的CRC，它覆盖流控制包的前四个字节。参见第7.8.3节“链路包CRC（LPCRC）-2字节”。

### 7.9.4.2 FCTBS的计算

**C7-58**：流控制包传输后，FCTBS应设置为自链路初始化以来在虚拟通道中传输的总块数。

**C7-59**：在端口状态初始化时，FCTBS应设置为零。

### 7.9.4.3 FCCL的计算

FCCL计算基于在接收方处为每个虚拟通道维护的12位调整块接收（ABR，Adjusted Blocks Received）计数器。

**C7-60**：在端口状态初始化时，ABR计数器应设置为零。

**C7-61**：收到每个流量控制包后，ABR应设置为FCTBS字段的值。

**C7-62**：在接收到每个数据包时，ABR应增加所接收的块，模4096，但对于由于接收方中缺少接收容量而丢弃的接收包，ABR不应增加。

**C7-63**：FCCL字段应按照**第7.9.4.3节“FCCL计算”**的规定进行设置。

在传输流量控制数据包时，FCCL应设置为以下值之一：

<span>◼ </span>如果接收方的当前缓冲器状态允许从有效IBA分组的所有组合中接收2048个或更多个块而不丢弃，则FCCL应设置为ABR加2048模4096。

<span>◼ </span>否则，FCCL应设置为ABR加上接收方能够从有效IBA分组的所有组合中接收的块数，而无需丢弃模4096。

**接收方能够接收的块数意味着无论到达的数据包的大小，接收方都可以保证在没有缓冲区溢出的情况下接收的块数**。例如，如果接收方能够在大数据包到达时接收到比小数据包更多的数据，则接收方必须使用较小的容量来计算FCCL。

此规范不排除在链路激活时重新配置接收缓冲器。这种重新配置可能导致FCCL值的变化，包括减少可用credit的可能性。此外，链路错误可能导致接收方的ABR和发送方的FCTBS之间的差异。当这种情况发生时，下一次对接收方的流量控制更新将纠正ABR的值，并可能导致FCCL的变化，从而减少或增加信用。更新FCCL时，传出数据包的信用计算应使用新值。当前正在传输或排队的数据包可以基于先前的FCCL值发送。

### 7.9.4.4 数据包传输

如果数据包可用于传输：

<span>◼ </span>让CR表示自链路初始化以来发送的总块数加上要发送的数据包中的块数，全部为模4096。

<span>◼ </span>让CL表示流控制包中接收到的最后一个FCCL。

如果（CL-CR）模4096≤2048，则可以发送数据分组。如果条件不为真，则在条件变为真之前，数据包可能不会被发送。流控制分组包传输不受此限制，虚拟信道15上的任何分组也不受此限制。

**C7-64**：只有当根据**第7.9.4.4节“数据包传输”**中的计算确定有足够的信用时，才能发送非VL15数据包。

**C7-65**：VL15数据包不受流量控制。

# 7.10 IBA和原始数据包多播

## 7.10.1 概述

多播是一种一对多的通信模式，旨在提高一组终端节点之间的通信效率。图61说明了一个不可靠的多播IBA操作的示例：

<span>◼ </span>在IBA路由元件（交换机或路由器）端口接收PSN=1129的数据包。

<span>◼ </span>交换机从LRH提取多播DLID，以确定它是否对应于多播组。一个实现可以将该数据维护为其内部路由表的一部分，例如，对应于该分组应转发的输出端口的位掩码。

<span>◼ </span>路由器从GRH中提取GID用于IBA多播，或为了支持原始数据包，检查RWH内的IPv6报头或以太网类型，以确定数据包是否对应于多播组。它使用此信息将数据包转发到下一个Hop再到目的地。

<span>◼ </span>交换机或路由器复制数据包（取决于实现），并将数据包转发到输出端口。

## 7.10.2 IBA不可靠组播操作规则

**o7-13**：本合规声明已过时，已被o7-13.1.1取代：。

**o7-13.1.1**：IIBA不可靠多播是一种可选功能。实施时，应根据**第7.10.2节“IBA不可靠多播操作规则”**中的操作规则运行。

1） 多播能力发现、路由表修改、状态和控制应由IBA管理实体管理。参考**第15.2.5.8节“MulticastForwardingTableRecord”**和**第14.2.5.12节“MulticastForwardingTable”**。

2） 在网络中，数据包在IBA交换机和路由器中被复制并转发到相应的输出端口。

3） 包在确认生成或传递保证方面不可靠。

4） 交换机和路由器可以在其支持多播分组的能力上有所不同，因此可以具有在IBA范围之外的特定于实现的调度、资源管理和拥塞策略。

5） 应用程序多播数据包可以通过子网管理器通过SL-to-VL映射表在VLs上传输。禁止使用VL15进行多播。

6） 应用程序多播数据包报头可以包含子网管理器提供的或从子网管理器派生的任何SL。

7） 以多播组为目标的应用程序使用多播组GID—参与多播组的每个端口应分配相应的多播组GID。

8）支持多播的每个CA、交换机或路由器可以参与零个、一个或多个多播组。

9）多播数据包可能需要横跨多个子网才能转发到下一个多播组。

10）多播数据包可以由端口生成。

多播组成员身份对参与的终端节点是不透明的，即：除**第15.2.5.17.5节“查询多播组”**中所述外，不可能知道哪些终端节点正在多播组中参与，以及多播组中的所有参与端节点是否驻留在本地或远程子网中。因此，所有的IBA多播数据包应包含一个GRH，其目的地多播GID根据IBA寻址规则定义。

11）GRH内的SGID应设置为最初将包注入网络的源端口。

12）消息应限于单包消息。最大消息大小是在创建多播组期间设置的。组创建者为多播组设置路径MTU（PMTU）。CA/路由器将在多播组加入操作期间向SM查询PMTU。

<span>◼ </span>如果一个终端节点试图加入一个多播组，并且不能接受当前的PMTU，则加入操作必须失败。

13） 对于终端端口参与的每个多播组，端口应至少关联一个本地管理的QP。

<span>◼ </span>如果源端口也是目的多播组内的目的端口，则源应在内部将信道接口内的包复制到相关的本地QP，包括源QP（如果它是该多播组的接收器）。

<span>◼ </span>如果目的地端节点包含参与多播组的多个本地管理的QP，则目的地端节点负责在信道接口内部复制分组并向每个QP传送一个副本。

14） 不可靠组播应使用不可靠数据报传输服务。有关操作规则、约束、验证和错误处理，请参阅不可靠数据报传输服务部分。

15） 源端节点应将包头内的目的地QP设置为0xFFFFFF。

## 7.10.3 原始数据包多播/Raw Packet Multicast

原始分组(数据包)可以使用与不可靠多播IBA分组相同的基本原理进行多播。

### 7.10.3.1 原始多播操作规则

**o7-14**：原始数据包不可靠多播是可选功能。实施时，应根据**第7.10.3节“原始数据包多播”**中的操作规则运行。

1） 原始分组多播是IBA中定义的可选功能。

2） 原始多播能力发现、路由表修改、状态和控制应由IBA管理实体管理。

3） 在网络中，数据包在IBA交换机中被复制并转发到相应的输出端口。

<span>◼ </span>交换机从LRH提取多播DLID以确定相应的输出端口。

4） 路由元素可以在其支持多播包的能力上有所不同，因此可以具有特定于实现的调度、资源管理和拥塞/丢弃策略，这些策略超出了该体系结构的范围。

5） 原始多播数据包可以在除VL15之外的任何VL上传输。

6） 原始多播数据包可以使用任何有效的SL来传输。

7） IPv6应用程序以使用IPv6多播地址的多播组为目标地址。所有其他协议都使用特定于协议的寻址和解析。

8） 每个支持多播的端节点可以参与零个、一个或多个多播组。

9） 原始多播组可能跨越多个子网—需要一个支持多播功能的路由器将数据包转发到下一跳来到达目的地。

10） 原始多播数据包可以由终端节点生成。

11） 消息应限于单包消息。最大消息大小是源和目标端节点之间的PMTU的功能。原始协议管理将与IBA管理实体交互，以确定允许的最大PMTU。如果PMTU太小，则不要求原始多播操作失败—错误恢复是原始多播组管理协议的责任。

12） 原始数据包支持（Raw packet support）至少需要一个本地管理的QP。实现可以基于特定于实现的策略来提供额外的QP。因此，实现负责本地原始数据包的复制和传递。

<span>◼ </span>如果源端口也是目标多播组中的目的端口，则源端口应将信道接口内的数据包内部复制到相关的本地应用程序目标。

<span>◼ </span>如果目的端节点在一个原始多播组中包含多个参与的应用程序目标，则目的端节点负责在信道接口内内部复制分组，并向每个目标发送一个副本。

13） 原始分组多播应使用IBA原始分组报头格式和语义。

## 7.10.4 多播组管理/Group Mangement

管理部分章节包含管理接口和相关的MAD，以实现多播组协议。多播组管理在**第15.2.5.17 节“MCMemberRecord””**中介绍。

# 7.11 子网多路径/Subnet Multipathing

## 7.11.1 端节点多路径要求

每个CA和路由器端口由子网管理器用LID和LMC（LID掩码控制， LID Mask Control）初始化。**LMC的值表示在对照端口的DLID检查接收到的DLID时要屏蔽的LID的低位位数**。LMC可以取0到7之间的值。因此，端口可以由1到128个单播LID来标识。

**C7-66**：当CA或路由器端口的链路层检查接收包中的单播DLID是否为对应该端口的有效DLID时，在将DLID与其分配的LID进行比较之前，应屏蔽LMC指示的低阶位数。

子网管理器可以为这些不同的LID编码为通过子网的备用路径。传输一章介绍了在传输包的SLID和DLID中使用哪个LID的选择。

# 7.12 错误检测和处理

## 7.12.1 错误检测

链路层可检测到以下几类错误：

<span>◼ </span>单数据包接收错误

<span>   </span><span>✸ </span>本地物理错误—指示所连接物理链路上的比特错误(bit error)的错误。包检查状态机中的ICRC、LPCRC和VCRC检查失败，以及进入包接收方状态机的坏包或坏包丢弃状态的条目都属于此类。

<span>   </span><span>✸ </span>远程物理错误—指示连接的物理链路以外的链路上的比特错误(bit error)的错误。数据包接收器状态机的标记坏数据包状态的条目属于此类。

<span>   </span><span>✸ </span>错误的数据包错误—传输的数据包与指示错误的数据包不一致。数据包可能在源代码处出错。也可能是交换机插入了错误。SM对交换机或端口配置的编程错误也可能造成此类错误。LVer错误、长度错误、操作码错误、VL错误和GRH_VL15错误都属于此类。这些都是来自包检查状态机的错误。

<span>   </span><span>✸ </span>交换机路由错误—指示交换机路由错误的错误。DLID错误在此类中。

<span>   </span><span>✸ </span>缓冲区溢出—表示物理链路另一端链路层中流量控制机器状态错误的错误。如果缓冲区没有立即从坏数据包中回收，则导致这种错误的一个原因可能是先前的数据包中存在物理错误。

**C7-67**：接收包中的错误应按照**第7.12.1节“错误检测”**的规定进行分类。

**C7-68**：当实现单个数据包接收错误的错误计数器，并且在接收的数据包中检测到一个或多个错误时，与错误相关联的计数器具有最高优先级，如**第7.3节“分组接收器状态”**、**第7.4节“数据包检查”**和**第7.5节“链路数据包检查”**所定义的最高优先级应递增，其他任何单个数据包错误计数器都不应增加。

<span>◼ </span>接收错误

<span>   </span><span>✸ </span>本地链路完整性—过于频繁的本地物理错误。这个错误是由边缘连接引起的。基于频繁的代码冲突，将在物理层检测到更严重的物理问题。本地链路完整性错误的检测基于本地物理错误的计数。计数从零开始，并且对于接收到的每个带有本地物理错误的数据包，计数应递增。如果当前计数高于零，则应在没有本地物理错误的情况下，对接收到的每个数据包递减一次计数器。当超过本地物理错误阈值时，应检测本地链路完整性错误。

<span>   </span><span>✸ </span>过度的缓冲区溢出—缓冲区溢出错误在多个流控制更新时间内持续存在。当每个周期中至少有一个溢出错误的连续流控制更新周期数超过PortInfo属性中给定的溢出错误阈值时，应检测到该错误。流控制更新周期应与65536个符号时间间隔相对应。

**C7-69**：本合规声明已过时，已被C7-69.1.1取代。

**C7-69.1.1**：每个端口应按照**第7.12.1节“错误检测”**的规定检测本地链路完整性和过度缓冲区溢出错误。

<span>◼ </span>发送端错误/Transmitter errors

<span>   </span><span>✸ </span>流量控制更新—指示链路另一端流量控制机器故障的错误。对于当前端口配置中激活的每个VL，除了VL15，应有一个watch-dog定时器监控流量控制更新的到达。如果计时器过期而未收到更新，则发生流控制更新错误。watch-dog定时器的周期应为400000+3%/-51%符号时间。此计时器仅在PortState=Arm或Active时运行。当PortState=ActiveD时，该定时器应复位。当PortState=Initialize或收到流量控制包时，定时器应复位。

**C7-70**：每个端口应执行**第7.12.1节“错误检测”**中规定的流控制更新错误检测。

## 7.12.2 错误恢复过程

对任何单个数据包接收错误的响应都是丢弃该数据包。在链路层不需要进一步恢复。对于某些错误，数据包检查状态机（第7.4节“数据包检查”）允许交换机通过附加错误的VCRC值和EBP分隔符来转发带有错误标记的数据包，作为丢弃数据包的替代方法。

本地链路完整性、过度的缓冲区溢出和流控制更新错误都表明错误可以通过重新训练来修复，或者可能是由硬故障引起的。

**C7-71**：当检测到本地链路完整性、过度缓冲区溢出或流控制更新错误时，链路应通过断言(asserting) L_init_train启动再训练（retraining）（参考**第6.3.1.2节“L_init_train-link inite retraining”**）。

## 7.12.3 错误通知

单个数据包接收错误类增量错误计数器，如管理中所述（参见**第16.1.4节“可选属性”**）。请注意，每个数据包最多检测到一个链路层错误，因此每个数据包只增加其中一个计数器。

本地链路完整性、过度缓冲区溢出和流控制更新都会被计算在内，并且可能会产生管理中指定的陷阱(trap)。

> 参考资料：”IB Specification Vol 1-Release-1.3-2015-03-03.pdf”

> <span style="font-style: italic;">声明：本文禁止转载！素材来源于网络，仅供学习使用，如有侵权请联系网站删除(ngdcn_admin@163.com)。由于本人水平有限，如有纰漏，请以参考资料为准。</span>

Infiniband手册