NVIDIA SM
NVIDIA SM 是一款符合 InfiniBand 标准的子网管理器 (SM)。它以名为“opensm”的固定流可执行文件形式提供，并附带一个名为 osmtest 的测试应用程序。NVIDIA SM 根据 InfiniBand 架构规范的以下章节实现符合 InfiniBand 标准的 SM：管理模型、子网管理和子网管理。
OpenSM 是一款符合 InfiniBand 标准的子网管理器和子网管理员，它运行在 NVIDIA OFED 堆栈之上。OpenSM 执行 InfiniBand 规范要求的任务，以初始化 InfiniBand 硬件。每个 InfiniBand 子网必须运行一个 SM。
OpenSM 的默认设置旨在满足节点数量不超过数百个的集群上的常见用例。因此，在这种默认模式下，OpenSM 将扫描 IB 结构，对其进行初始化，并偶尔扫描更改。
OpenSM 连接到本地计算机上的特定 IB 端口，并且仅配置连接到它的结构。（如果本地计算机有其他 IB 端口，OpenSM 将忽略连接到这些其他端口的结构）。如果未指定端口，opensm 将选择第一个“最佳”可用端口。opensm 还可以显示可用端口并提示输入要连接的端口号。
默认情况下，OpenSM 运行日志记录到 /var/log/opensm.log。此日志文件中报告的所有错误都应视为 IB 结构运行状况问题的指示。（请注意，当发生致命且不可恢复的错误时，OpenSM 将退出）。如果 OpenSM 能够正确设置子网，则 opensm.log 应包含消息“SUBNET UP”。
语法
opensm [OPTIONS]
有关 OpenSM 选项的完整列表，请运行
opensm --help / -h / -?
环境变量
以下环境变量控制 OpenSM 行为
OSM_TMP_DIR - 控制 OpenSM 生成的临时文件创建所在的目录。这些文件是：opensm-subnet.lst、opensm.fdbs 和 opensm.mcfdbs。默认情况下，此目录为 /var/log。
OSM_CACHE_DIR - opensm 将某些数据存储到磁盘，以便后续运行保持一致。使用的默认目录是 /var/cache/opensm。其中包含以下文件
guid2lid– 存储分配给每个 GUID 的 LID 范围
信令
当 OpenSM 接收到 HUP 信号时，它会启动新的重负载扫描，就像接收到陷阱或发现拓扑更改一样。
此外，SIGUSR1 可用于触发重新打开 /var/log/opensm.log 以进行日志轮换。
以守护进程方式运行 OpenSM
OpenSM 也可以作为守护进程运行。要在此模式下运行 OpenSM，请输入
host1# service opensmd start
osmtest 是一个用于验证 InfiniBand 子网管理器和子网管理员的测试程序。osmtest 为 opensm 提供了一个测试套件。它可以创建所有可用节点、端口和 PathRecord 的清单文件，包括它们的所有字段。它还可以使用所有对象字段验证现有清单，并将其与预先保存的清单进行匹配。
osmtest 具有以下测试流程
多播合规性测试
事件转发测试
服务记录注册测试
RMPP 压力测试
小型 SA 查询压力测试
有关更多信息，请参阅该工具的 man 手册。
OpenSM 允许在 InfiniBand 结构中配置分区 (PKey)。默认情况下，OpenSM 在 /etc/opensm/partitions.conf 名称下搜索分区配置文件。要更改此文件名，您可以将 opensm 与“--Pconfig”或“-P”标志一起使用。
即使分区配置文件不存在或无法访问，OpenSM 也会无条件地创建默认分区。
默认分区的 P_Key 值为 0x7fff。运行 OpenSM 的端口被分配默认分区的完全成员资格。所有其他终端端口都被分配部分成员资格。
向 partition.conf 文件添加新分区不需要重启 SM，但需要通过 HUP 信号向 SM 进程发送信号（例如 pkill -HUP opensm）。
默认分区无法删除。
对端口 GUID 的调整，包括添加、删除或成员资格更改（在“分区定义”中表示为“<PortGUID>=[full|limited|both]”），可以通过 HUP 信号应用于子网管理器进程（例如 pkill -HUP opensm）。
对现有分区的 ipoib_bc_flags (ipoib/sl/scope/rate/mtu) 和 mgroup 标志执行更改需要重启子网管理器才能生效。
文件格式
在“#”字符之后跟随的行内容是注释，解析器会忽略它。
通用文件格式
<Partition Definition>:\[<newline>\]<Partition Properties>
<分区定义>
[PartitionName][=PKey][,indx0][,ipoib_bc_flags][,defmember=full|limited]
其中
PartitionName字符串，
将用于日志记录。如果省略，将使用空字符串。PKey此分区的 P_Key 值。仅使用低 15 位。如果省略，将自动生成。indx0指示应将此 pkey 插入块 0 索引 0 中。ipoib_bc_flags用于指示/指定此分区的 IPoIB 功能。defmember=full|limited|both指定端口 GUID 列表的默认成员资格。默认为 limited。ipoib_bc_flags 为
ipoib指示此分区可能用于 IPoIB，因此将使用给定的标志（如果有）创建 IPoIB 广播组。rate=<val>指定此 IPoIB MC 组的速率（默认值为 3 (10GBps)）mtu=<val>指定此 IPoIB MC 组的 MTU（默认值为 4 (2048)）sl=<val>指定此 IPoIB MC 组的 SL（默认值为 0）scope=<val>指定此 IPoIB MC 组的范围（默认值为 2（链路本地））<分区属性>
\[<Port list>|<MCast Group>\]* | <Port list>
<端口列表>
<Port Specifier>[,<Port Specifier>]
<端口指定符>
<PortGUID>[=[full|limited|both]]
其中
PortGUID分区成员终端端口的 GUID。十六进制数应以 0x 开头，也接受十进制数。full, limited指示此端口的完全和/或有限成员资格。如果省略（或无法识别），则假定为有限成员资格。“Both”表示此端口的完全和有限成员资格。
<MCast 组>
mgid=gid[,mgroup_flag]*<newline>
其中
mgid=gid指定的 gid 经过验证为多播地址，IP 组经过验证以匹配广播组的速率和 mtu。IP 组的 mgid 的 P_Key 位经过验证，要么与“分区定义”中指定的 P_Key 匹配，要么如果它们是 0x0000，则 P_Key 将被复制到这些位中。mgroup_flagrate=<val>指定此 MC 组的速率（默认值为 3 (10GBps)）mtu=<val>指定此 MC 组的 MTU（默认值为 4 (2048)）sl=<val>指定此 MC 组的 SL（默认值为 0）scope=<val>指定此 MC 组的范围（默认值为 2（链路本地））。允许为一个分区设置多个范围。注意：这会覆盖指定 mgid 的范围半字节。此外，指定多个范围设置将导致创建多个 MC 组。qkey=<val>指定此 MC 组的 Q_Key（默认值：IP 组为 0x0b1b，其他组为 0）tclass=<val>指定此 MC 组的 tclass（默认值为 0）FlowLabel=<val>指定此 MC 组的 FlowLabel（默认值为 0）
请注意，速率、MTU 和范围的值应按照 IBTA 规范中的定义进行指定（例如，mtu=4 表示 2048）。要使用 4K MTU，请将该条目编辑为“mtu=5”（5 表示该特定分区的 4K MTU）。
PortGUID 列表
PortGUID GUID of partition member EndPort. Hexadecimal numbers should start from 0x, decimal numbers are accepted too.
full or limited indicates full or limited membership for this port. When omitted (or unrecognized) limited membership is assumed.
PortGUID 定义有一些有用的关键字
“ALL_CAS”表示此子网中的所有通道适配器终端端口
“ALL_VCAS”表示子网中的所有虚拟终端端口
“ALL_SWITCHES”表示此子网中的所有交换机终端端口
“ALL_ROUTERS”表示此子网中的所有路由器终端端口
“SELF”表示子网管理器的端口。空列表表示此分区中没有端口
注释
分隔符（“=”、“,”、“:”、“;”）之间允许有空格。
PartitionName 不需要唯一，PKey 需要唯一。如果 PKey 重复，则这些分区配置将被合并，并且将使用第一个 PartitionName（请参阅下一个注释）。
可以将分区配置拆分为多个定义，但随后应显式指定 PKey（否则将为这些定义生成不同的 PKey 值）。
示例
Default=0x7fff : ALL, SELF=full ;
Default=0x7fff : ALL, ALL_SWITCHES=full, SELF=full ;
NewPartition , ipoib : 0x123456=full, 0x3456789034=limi, 0x2134af2306 ;
YetAnotherOne = 0x300 : SELF=full ;
YetAnotherOne = 0x300 : ALL=limited ;
ShareIO = 0x80 , defmember=full : 0x123451, 0x123452;
# 0x123453, 0x123454 will be limited
ShareIO = 0x80 : 0x123453, 0x123454, 0x123455=full;
# 0x123456, 0x123457 will be limited
ShareIO = 0x80 : defmember=limited : 0x123456, 0x123457, 0x123458=full;
ShareIO = 0x80 , defmember=full : 0x123459, 0x12345a;
ShareIO = 0x80 , defmember=full : 0x12345b, 0x12345c=limited, 0x12345d;
# multicast groups added to default
Default=0x7fff,ipoib:
mgid=ff12:401b::0707,sl=1 # random IPv4 group
mgid=ff12:601b::16 # MLDv2-capable routers
mgid=ff12:401b::16 # IGMP
mgid=ff12:601b::2 # All routers
mgid=ff12::1,sl=1,Q_Key=0xDEADBEEF,rate=3,mtu=2 # random group
ALL=full;
以下规则等效于 OpenSM 在分区管理器之前运行的方式
Default=0x7fff,ipoib:ALL=full;
如果添加或删除了链路，OpenSM 可能不会重新计算不必更改的路由。如果端口不再处于 UP 状态或不再是 MinHop，则必须更改路由。当执行路由更改时，将调用相同的路由平衡算法。
在使用基于文件的路由的情况下，当前会忽略任何拓扑更改。“file”路由引擎仅从指定的文件加载 LFT，而不对实际拓扑做出反应。显然，这将无法为断开连接的节点重新检查 LID（通过 GUID），并且将跳过不存在的交换机的 LFT。多播不受“file”路由引擎的影响（这使用最小跳表）。
OpenSM 提供以下路由引擎
基于到每个节点的最小跳数，其中路径长度已优化。
基于到每个节点的最小跳数，但它受排名规则的约束。如果子网不是纯 Fat Tree，并且由于子网中的环路可能发生死锁，则应选择此算法。
此算法针对无拥塞的“移位”通信模式优化路由。如果子网是各种类型的对称 Fat Tree，而不仅仅是 K-ary-N-Tree：非恒定 K，未完全填充，以及任何 CBB 比率，则应选择此算法。与 UPDN 类似，Fat Tree 路由也受排名规则的约束。
基于最小跳算法，但避免端口均衡，除非同一两个交换机之间存在冗余链路。当结构布线为超立方体时，这为超立方体提供无死锁路由，当布线为网格时，为网格提供无死锁路由。
基于专用于 2D/3D 环形拓扑的 DOR 单播路由算法。Torus-2QoS 提供无死锁路由，同时支持两个服务质量 (QoS) 级别。此外，它可以在不引入死锁的情况下绕过多个结构链路故障或单个结构交换机故障，并且不会更改故障前授予的路径 SL 值。
允许通过不同的路由引擎配置单个 InfiniBand 子网的不同部分。在当前版本中，可以组合 minhop/updn/ftree/dor/torus-2QoS/pqft。
请注意，不支持 LASH 路由算法。
MINHOP/UPDN/DOR 路由算法由两个阶段组成
MinHop 矩阵计算。从每个端口到达每个 LID 需要多少跳。如果您运行标准（最小跳数）或 Up/Down，则填充这些表的算法是不同的。对于标准路由，使用“松弛”算法从每个目标 LID 通过邻居交换机传播最小跳数。对于 Up/Down 路由，使用来自每个目标的 BFS。BFS 跟踪链路方向（向上或向下）并避免在使用向下步骤后执行向上步骤。
一旦 MinHop 矩阵存在，就会访问每个交换机，并且对于每个目标 LID，都会决定应使用哪个端口来到达该 LID。此步骤对于标准路由和 Up/Down 路由是通用的。每个端口都有一个计数器，用于计算通过它的目标 LID 的数量。当有多个具有相同 MinHop 到 LID 的备用端口时，将选择之前分配的端口较少的端口。
如果 LMC > 0，则会添加更多检查。在分配给同一目标端口的每组 LID 中
仅使用具有相同 MinHop 的端口
首先首选去往不同 systemImageGuid 的端口（然后是同一 LMC 组的前一个 LID）
如果没有，则首选通过另一个 NodeGuid 的端口
回退到路径数方法（如果所有路径都去往同一节点）。
最小跳算法
如果未指定路由算法，则默认情况下会调用最小跳算法。也可以通过指定“-R minhop”来调用它。
最小跳算法分为两个阶段：每个交换机上最小跳表的计算和 LFT 输出端口分配。链路订阅也已均衡，并能够基于端口 GUID 进行覆盖。后者由以下内容提供
-i <equalize-ignore-guids-file>
-ignore-guids <equalize-ignore-guids-file>
此选项提供了定义一组将被链路负载均衡算法忽略的端口（通过 GUID）的方法。
LMC 感知路由基于（远程）系统或交换机。
UPDN 算法
UPDN 算法旨在防止在子网环路中发生死锁。环路死锁是指通过环路连接的任何两个主机之间不再可能发送数据的情况。因此，如果子网不是纯 Fat Tree，并且其环路之一可能发生死锁（例如，由于高压力），则应发送 UPDN 路由算法。
UPDN 算法基于以下主要阶段
自动检测根节点 - 基于子网中任何交换机的 CA 跳数长度，为每个交换机构建统计直方图（跳数与出现次数）。如果直方图反映了特定节点的特定列（高于其他列），则将其标记为根节点。由于该算法是统计的，因此可能找不到任何根节点。此自动检测阶段找到的根节点列表由排名过程阶段使用。
注意用户可以手动覆盖节点列表。
注意如果此阶段找不到任何根节点，并且用户未指定 GUID 列表文件，则 OpenSM 将默认回退到最小跳路由算法。
排名过程 - 所有根交换机节点（在阶段 1 中找到）都分配了等级 0。使用 BFS 算法，子网中的其余交换机节点按递增顺序排名。此排名有助于强制执行规则，以确保无环路路径。
最小跳表设置 - 完成排名后，从子网中的每个（CA 或交换机）节点运行 BFS 算法。在 BFS 过程中，根据排名规则和 GUID 值，更新 BFS 遍历的每个交换机节点的 FDB 表，以参考起始节点。
在该过程结束时，更新后的 FDB 表确保通过子网的无环路路径。
UPDN 算法用法
通过 OpenSM 激活
使用“-R updn”选项（而不是旧的“-u”）来激活 UPDN 算法。
使用“-a <root_guid_file>”添加 UPDN GUID 文件，其中包含用于排名的根节点。如果未使用“-a”选项，则 OpenSM 使用其自动检测根节点算法。
有关 GUID 列表文件的注释
有效的 GUID 文件在每行中指定一个 GUID。格式无效的行将被丢弃
用户应指定根交换机 GUID
Fat-tree 路由算法
fat-tree 算法针对“移位”通信模式优化路由。如果子网是各种类型的对称或几乎对称的 fat-tree，则应选择此算法。它不仅支持 K-ary-N-Tree，还支持处理非恒定 K、并非所有叶节点 (CA) 都存在的情况、任何恒定剖分带宽比率 (CBB) 比率。与 UPDN 一样，fat-tree 也可防止信用环路死锁。
如果未提供根 GUID 文件（“”或“-root_guid_file”选项），则拓扑必须是纯 fat-tree，并符合以下规则
树等级应介于 2 到 8 之间（含 2 和 8）
除非同一等级的交换机是根交换机，否则它们应具有相同数量的向上端口组，在这种情况下，它们不应具有任何向上端口。
注意：连接到同一远程交换机的端口称为“端口组”。
除非同一等级的交换机是叶节点交换机，否则它们应具有相同数量的向下端口组。
同一等级的交换机应在每个向上端口组中具有相同数量的端口。
同一等级的交换机应在每个向下端口组中具有相同数量的端口。
所有 CA 都必须位于同一树级别（等级）。
如果提供了根 GUID 文件，则拓扑不必是纯 fat-tree，并且仅应符合以下规则
树等级应介于 2 到 8 之间（含 2 和 8）
所有计算节点都必须位于同一树级别（等级）。请注意，此处允许非计算节点 CA 位于不同的树等级。
注意：可以使用“-u”或“--cn_guid_file”OpenSM 选项指定计算节点 (CN) 列表。
不符合的拓扑会导致回退到最小跳路由。请注意，这也可能发生在链路故障导致拓扑不再是“纯”fat-tree 时。
请注意，虽然 fat-tree 算法支持具有非整数 CBB 比率的树，但在整数 CBB 比率的情况下，路由将不会像那样平衡。除了这一点外，虽然该算法允许叶节点交换机具有任意数量的 CA，但树越接近完全填充，则“移位”通信模式将越有效。一般来说，即使提供了根列表，拓扑越接近纯粹对称的 fat-tree，路由将越最佳。
该算法还在 OpenSM 日志所在的同一目录中转储计算节点排序文件 (opensm-ftree-ca-order.dump)。此排序文件提供了可用于创建与路由表匹配的高效通信模式的 CN 顺序。
非 CN 节点之间的路由
使用 io_guid_file 选项允许非 CN 节点位于 fat tree 中的不同级别。在这种情况下，不保证 Fat Tree 算法会在两个非 CN 节点之间路由。在下面的方案中，N1、N2 和 N3 是非 CN 节点。虽然所有 CN 都有往返它们的路由，但 N1、N2 和 N3 之间不一定存在路由。此类路由将需要至少以错误的方式使用其中一个交换机。
要解决此问题，可以通过“-G”或“--io_guid_file”选项指定非 CN 节点列表。这些节点将被允许以错误的方式使用交换机特定次数（由“-H”或“--max_reverse_hops”指定）。使用正确的 max_reverse_hops 和 io_guid_file 值，您可以确保 Fat Tree 中的完全连接。在上面的方案中，当 max_reverse_hop 为 1 时，将在 N1<->N2 和 N2<->N3 之间实例化路由。当 max_reverse_hops 值为 2 时，N1、N2 和 N3 都将在它们之间具有路由。
使用 max_reverse_hops 会创建以反向流方式使用交换机的路由。此选项绝不应用于连接它们之间具有高带宽流量的节点！它应仅用于允许 HA 目的或类似的连接。此外，反向路由可能会导致信用环路。
通过 OpenSM 激活
使用“-R ftree”选项激活 fat-tree 算法。
fat-tree 路由不支持 LMC > 0。如果指定了此值，则会改为调用默认路由算法。
DOR 路由算法
维度顺序路由算法基于最小跳算法，因此使用最短路径。它不是在具有相同最短距离的不同路径上分散流量，而是基于维度顺序在可用最短路径中进行选择。每个端口必须一致地布线以表示超立方体维度或网格维度。路径从目标向源增长，在每个步骤中使用可用路径的最低维度（端口）。这提供了避免死锁所需的排序。当任意两个交换机之间存在多个链路时，它们仍然仅表示一个维度，并且除非关闭端口均衡，否则流量会在它们之间进行平衡。在超立方体的情况下，必须在整个结构中使用相同的端口来表示超立方体维度，并在电缆的两端匹配。在网格的情况下，维度应始终如一地使用同一对端口，一端电缆上的一个端口，另一端电缆上的另一个端口，沿着网格维度继续。
使用“-R dor”选项激活 DOR 算法。
Torus-2QoS 路由算法
Torus-2QoS 是一种为大型 2D/3D 环形结构设计的路由算法。torus-2QoS 路由引擎可以在 2D/3D 环形结构上提供以下功能
无信用环路路由
两个 QoS 级别，假设交换机支持 8 个数据 VL
能够绕过单个故障交换机和/或多个故障链路进行路由，而无需
引入信用环路
更改路径 SL 值
运行时间非常短，并且随着结构尺寸的增加具有良好的扩展属性
单播路由
Torus-2 QoS 是一种基于 DOR 的算法，它使用每个环形维度的分界线的概念来避免环形结构中可能发生的死锁。它将路径 SL 编码为路径跨越的分界线，如下所示
sl = 0;
for (d = 0; d < torus_dimensions; d++)
/* path_crosses_dateline(d) returns 0 or 1 */
sl |= path_crosses_dateline(d) << d;
对于 3D 环形结构，这留下了一个空闲的 SL 位，torus-2 QoS 使用该位来实现两个 QoS 级别。Torus-2 QoS 还利用交换机 SL2VL 映射的输出端口依赖性，将编码在三个 SL 位中的信息编码到一个 VL 位中。它计算每个交换机间链路“指向”哪个环形坐标方向，并为这些端口编写 SL2VL 映射，如下所示
for (sl = 0; sl < 16; sl ++)
/* cdir(port) reports which torus coordinate direction a switch port
* "points" in, and returns 0, 1, or 2 */
sl2vl(iport,oport,sl) = 0x1 & (sl >> cdir(oport));
因此，在原始 3D 环形结构上，即在没有故障结构交换机的情况下，torus-2 QoS 每个 QoS 级别消耗 8 个 SL 值（SL 位 0-2）和 2 个 VL 值（VL 位 0）以在 3D 环形结构上提供无死锁路由。Torus-2 QoS 通过“绕远路”绕过任何被链路故障中断的 1D 环来绕过链路故障。例如，考虑下面的 2D 6x5 环形结构，其中交换机用 [+a-zA-Z] 表示
对于原始结构，从 S 到 D 的路径将是 S-n-T-r-D。如果链路 S-n 或 n-T 发生故障，torus-2QoS 将使用路径 S-m-p-o-T-r-D。
请注意，它可以这样做而无需更改路径 SL 值；一旦 1D 环 m-S-n-T-o-p-m 因故障而中断，使用它的路径段就无法导致死锁，并且对于该环上的路径段，可以忽略 x 方向分界线（例如，在 x=5 和 x=0 之间）。这样做的一个结果是，torus-2QoS 可以绕过许多同时发生的链路故障进行路由，只要没有 1D 环被分成不相交的段即可。例如，如果链路 n-T 和 T-o 都已发生故障，则该环已被分成两个不相交的段，T 和 o-p-m-S-n。Torus-2QoS 检查此类问题，如果发现它们，则会报告并拒绝路由此类结构。
请注意，在交换机对之间存在多个并行链路的情况下，torus-2QoS 将以轮询方式跨此类链路分配路由，基于路径目标交换机上处于活动状态且未用于交换机间链路的端口。如果此类并行链路集中的一个链路发生故障，则路由将在其余链路之间重新分配。当此类并行链路集中的最后一个链路发生故障时，流量将如上所述重新路由。
在 DOR 下处理故障交换机需要在路径中引入至少一个在其他情况下“非法”的转弯，即 DOR 规则不允许的转弯。Torus-2QoS 将尽可能靠近故障交换机引入此类转弯，以便绕过它。在上面的示例中，假设交换机 T 发生故障，并考虑从 S 到 D 的路径。Torus-2QoS 将生成路径 S-n-I-r-D，而不是原始环形结构的 S-n-T-r-D 路径，方法是在 n 处引入早期转弯。正常的 DOR 规则将导致到达交换机 I 的流量转发到交换机 r；对于由于 n 处的“早期”转弯而从 I 到达的流量，这将在 I 处生成“非法”转弯。
Torus-2QoS 还将使用 SL2VL 映射的输入端口依赖性为 y-x、z-x 和 z-y 转弯设置 VL 位 1（否则将未使用），即 DOR 下非法的那些转弯。这会导致任何此类转弯后的第一跳使用一组单独的 VL 值，并防止在存在单个故障交换机时发生死锁。对于任何给定路径，只有非法 DOR 下的转弯后的跳才能导致导致死锁的信用环路。因此，在上面的交换机 T 发生故障的示例中，从 S 到 D 的路径中非法转弯 I 的位置要求由该转弯引起的任何信用环路都必须围绕 T 处的故障交换机。因此，非法转弯 I 之后的第二跳及后续跳（即跳 r-D）不能导致信用环路，因为它们不能用于构建围绕 T 的环路。跳 I-r 使用单独的 VL，因此它不能导致围绕 T 的信用环路。扩展此论证表明，除了能够绕过单个交换机故障进行路由而不引入死锁外，torus-2QoS 还可以在多个故障交换机周围路由，条件是它们在 DOR 路由的最后一个维度中相邻。例如，考虑以下 6x6 2D 环形结构中的情况
假设交换机 T 和 R 发生故障，并考虑从 S 到 D 的路径。Torus-2QoS 将生成路径 S-n-q-I-u-D，在交换机 I 处具有非法转弯，并且跳 I-u 使用设置了位 1 的 VL。作为另一个示例，考虑 torus-2QoS 无法在没有死锁的情况下路由的情况：在不是 DOR 路由的最后一个维度中相邻的两个故障交换机；这里的故障交换机是 O 和 T
在原始结构中，torus-2QoS 会将从 S 到 D 的路径生成为 S-n-O-T-r-D。如果交换机 O 和 T 发生故障，torus-2QoS 将生成路径 S-n-I-q-r-D，在交换机 I 处具有非法转弯，并且跳 I-q 使用设置了位 1 的 VL。与之前的示例相反，非法转弯后的第二跳 q-r 可用于构建围绕故障交换机的信用环路。
多播路由
由于 torus-2QoS 使用所有四个可用的 SL 位，以及当前交换机中通常可用的三个数据 VL 位，因此无法使用 SL/VL 值将多播流量与单播流量分离。因此，torus-2QoS 必须生成多播路由，以便信用环路不会因多播和单播路径段的组合而产生。事实证明，可以为多播路由构建具有该属性的生成树。对于 2D 6x5 环形结构
在上面的示例中，这是 torus-2QoS 将构建的全结构生成树，其中“x”是根交换机，每个“+”是非根交换机
对于从根到尖端路由的多播流量，上述生成树中的每个转弯都是合法的 DOR 转弯。对于从尖端到根路由的流量，以及一些通过根路由的流量，转弯不是合法的 DOR 转弯。但是，要构建信用环路，在此生成树上进行多播路由与 DOR 单播路由的并集只能提供环路所需的 4 个转弯中的 3 个。此外，如果上述生成树分支中没有一个跨越用于环形结构上的单播信用环路避免的分界线，并且如果多播流量被限制为 SL 0 或 SL 8（回想一下 torus-2QoS 使用 SL 位 3 来区分 QoS 级别），则多播流量也不能导致环形结构中可能存在的“环形”信用环路。Torus-2QoS 使用这些想法来创建主生成树。每个多播组生成树都将构建为主树的子集，并且与主树具有相同的根。此类多播组生成树通常对于作为全结构子集的组不是最佳的。但是，必须做出这种妥协才能在环形结构上支持两个 QoS 级别，同时防止信用环路。在链路或交换机故障导致 torus-2QoS 可以生成无信用环路单播路由的结构的情况下，也可以生成保留所需属性的多播主生成树。例如，考虑相同的 2D 6x5 环形结构，其中从 (2,2) 到 (3,2) 的链路发生故障。Torus-2QoS 将生成以下主生成树
关于此主生成树，有两件事值得注意。首先，假设 x 分界线在 x=5 和 x=0 之间，则此生成树有一个分支跨越分界线。但是，就像单播一样，在被故障中断的 1D 环（此处为 y=2 的环）上跨越分界线不会导致环形结构信用环路。其次，即使对于包含整个结构的多播组，此生成树也不再是最佳的。不幸的是，为了保留 torus-2QoS 路由的其他理想属性，必须做出这种妥协。在单个交换机发生故障的情况下，torus-2QoS 将通过适当选择根交换机来生成没有“额外”转弯的主生成树。在 2D 6x5 环形结构示例中，现在假设 (3,2) 处的交换机（即，原始结构的根）发生故障。Torus-2QoS 将为该情况生成以下主生成树
假设分界线在 y=4 和 y=0 之间，则此生成树有一个分支跨越分界线。但是，这不会导致信用环路，因为它发生在被故障中断的 1D 环（x=3 的环）上，如上面的示例所示。
环形拓扑发现
torus-2QoS 使用的算法需要通过 torus-2QoS.conf 配置每个维度的基数，才能从表示结构的无向图中构建环形拓扑。它还需要“播种”环形拓扑；对于 3D 环形拓扑，这需要配置四个交换机，以定义环形拓扑的三个坐标方向。给定此起始信息，该算法将检查由八个交换机位置形成的立方体，这些位置由角点 (x,y,z) 和 (x+1,y+1,z+1) 界定。根据已放置到环形拓扑中的某些位置的交换机，该算法检查交换机间链路的 4 环路，以找到与交换机位置立方体的一个面一致的环路，并将其交换机添加到已发现的拓扑中的正确位置。
由于该算法基于检查链路 4 环路的拓扑，因此基数为 4 或更大的环形拓扑需要额外的初始种子配置。有关详细信息，请参阅 torus-2QoS.conf(5)。当环形拓扑的配置不足时，Torus-2QoS 将检测并报告。
如果环形拓扑显著退化，即存在许多缺失的交换机或链路，则可能会发生 torus-2QoS 无法将结构中发现的某些交换机和/或链路放置到环形拓扑中的情况，并且在这种情况下会生成警告。如果 torus-2QoS 配置错误，也会发生类似的情况，即配置的环形拓扑维度的基数与布线的环形拓扑维度的基数不匹配，并且结构中的许多交换机/链路将不会放置到环形拓扑中。
服务质量配置
除非使用 -Q 调用 OpenSM，否则 OpenSM 不会为交换机和通道适配器编程 SL2VL 映射或 VL 仲裁配置。由于 torus-2QoS 依赖于此类功能才能正确运行，因此当 torus-2QoS 在路由引擎列表中时，始终使用 -Q 调用 OpenSM。OpenSM 支持的任何服务质量配置方法都适用于 torus-2QoS，但受以下限制和注意事项的约束。对于 OpenSM 支持的所有路由引擎（torus-2QoS 除外），服务质量级别和 SL 之间存在一对一的对应关系。Torus-2QoS 只能支持两个服务质量级别，因此只有用于单播 QoS 配置的任何 SL 值的高位将被 torus-2QoS 接受。对于多播 QoS 配置，只有 SL 值 0 和 8 应与 torus-2QoS 一起使用。
由于 SL 到 VL 映射配置必须完全由 torus-2QoS 控制，因此任何通过 qos_sl2vl、qos_swe_sl2vl 等进行的配置都必须且将被忽略，并且将生成警告。Torus-2QoS 使用 VL 值 0-3 来实现其支持的 QoS 级别之一，并使用 VL 值 4-7 来实现另一个级别。如果流量未在每个 VL 范围（0-3 和 4-7）内公平地交付，则可能会出现难以诊断的应用程序问题。如果 VL 仲裁在 0-3 范围和 4-7 范围内配置不公平，Torus-2QoS 将检测并发出警告。请注意，默认的 OpenSM VL 仲裁配置不满足此约束，因此所有 torus-2QoS 用户都应通过 qos_vlarb_high、qos_vlarb_low 等配置 VL 仲裁。
操作注意事项
环形 IB 结构的任何路由算法都必须使用路径 SL 值以避免信用循环。因此，在此类结构上运行的所有应用程序都必须执行路径记录查询以获取连接设置的正确路径 SL。使用 rdma_cm 进行连接设置的应用程序将自动满足此要求。
如果结构拓扑的变化导致路由所需的路径 SL 值发生变化以避免信用循环，一般来说，所有应用程序都需要重新寻址路径以避免消息死锁。由于 torus-2QoS 能够在单个交换机故障后重新路由而无需更改路径 SL 值，因此当结构使用 torus-2QoS 路由时，运行应用程序无需重新寻址路径。
在子网管理器故障转移的情况下，Torus-2QoS 可以提供不变的路径 SL 值，前提是所有 OpenSM 实例对数据线位置具有相同的概念。有关详细信息，请参阅 torus-2QoS.conf(5)。Torus-2QoS 将检测阻止无信用循环路由的故障交换机和链路配置，并将记录警告并拒绝路由。如果在 OpenSM 路由引擎列表中配置了“no_fall- back”，则没有其他路由引擎会尝试路由结构。在这种情况下，所有不经过故障组件的路径将继续工作，并且仍然可操作的路径子集将继续保持无信用循环。OpenSM 将在每个扫描间隔之后以及结构拓扑的任何更改（例如链路启动）之后继续尝试路由结构。当结构组件修复后，将恢复全部功能。如果 OpenSM 配置为允许其他引擎在 torus-2QoS 失败时路由结构，则如果 torus-2QoS 先前已成功路由结构，则可能会发生信用循环和消息死锁。即使其他引擎能够路由无信用循环的环形拓扑，使用在 torus-2QoS 下授予的路径 SL 值建立连接的应用程序也可能在由不同引擎生成的路由下遇到消息死锁，除非它们重新寻址路径。要验证环形拓扑结构是否以无信用循环的方式路由，请使用 ibdmchk 分析通过 ibdiagnet-vlr 收集的数据。
Torus-2QoS 配置文件语法
文件 torus-2QoS.conf 包含特定于 OpenSM 路由引擎 torus-2QoS 的配置信息。空白行和第一个非空白字符为“#”的行将被忽略。令牌是任何连续的非空白字符组。行中识别的配置令牌之后的任何令牌都将被忽略。
[torus|mesh] x_radix[m|M|t|T] y_radix[m|M|t|T] z_radix[m|M|t|T]
torus 或 mesh 必须是配置中的第一个关键字，并设置 torus-2QoS 将尝试构建的拓扑。可以通过将 x_radix、y_radix 或 z_radix 之一指定为 1 来配置 2D 拓扑。可以通过在其基数规范后附加 m、M、t 或 T 之一，将单个维度配置为 mesh（开放）或 torus（环形）。因此，“mesh 3T 4 5”和“torus 3 4M 5M”都指定相同的拓扑。
请注意，尽管 torus-2QoS 可以路由网格结构，但其在网格结构上绕过故障组件的能力会受到严重损害。故障的结构组件很可能导致不相交的环；请参阅 torus-2QoS(8) 中的 UNICAST ROUTING。
xp_link sw0_GUID sw1_GUID
yp_link sw0_GUID sw1_GUID
zp_link sw0_GUID sw1_GUID
xm_link sw0_GUID sw1_GUID
ym_link sw0_GUID sw1_GUID
zm_link sw0_GUID sw1_GUID
这些关键字用于播种环形/网格拓扑。例如，“xp_link 0x2000 0x2001”指定从节点 GUID 为 0x2000 的交换机到节点 GUID 为 0x2001 的交换机的链路将指向正 x 方向，而“xm_link 0x2000 0x2001”指定从节点 GUID 为 0x2000 的交换机到节点 GUID 为 0x2001 的交换机的链路将指向负 x 方向。给定种子的所有链路关键字都必须指定相同的“from”交换机。
通常，不必配置给定坐标的正方向和负方向；任一方向都足够。但是，用于拓扑发现的算法对于基数为 4 的环形维度需要额外的信息（请参阅 torus-2QoS(8) 中的 TOPOLOGY DISCOVERY）。对于这种情况，必须同时指定正坐标方向和负坐标方向。
根据通过 torus/mesh 关键字指定的拓扑，Torus-2QoS 将检测并在种子配置不足时记录。
GUIDx_dateline position
y_dateline position
z_dateline position
为了使 torus-2QoS 保证路径 SL 值在任何其仍可路由结构的条件下都不会更改，其对数据线位置的概念必须相对于物理交换机位置保持不变。数据线关键字提供了配置此类行为的方法。
环形维度的数据线始终位于该维度的坐标 0 的交换机和坐标 radix-1 的交换机之间。默认情况下，环形种子中的公共交换机被视为用于描述交换机位置的坐标系的原点。数据线关键字的位置参数将原点（以及数据线）相对于环形种子中的公共交换机移动指定的量。
next_seed
如果用于指定种子的任何交换机发生故障，则 torus-2QoS 将无法成功完成拓扑发现。next_seed 关键字指定以下链路和数据线关键字应用于新的种子规范。
为了获得最大的弹性，任何种子规范都不应与任何其他种子规范共享交换机。多个种子规范应使用数据线配置来确保 torus-2QoS 可以授予恒定的路径 SL 值，而与用于启动拓扑发现的种子无关。
portgroup_max_ports max_ports - 此关键字指定 torus-2QoS 可以容纳的最大并行交换机间链路数，以及每个交换机的最大主机端口数。默认值为 16。如果需要增加此参数，Torus-2QoS 将在拓扑发现期间记录错误消息。如果此关键字多次出现，则最后一次出现的实例优先。
port_order p1 p2 p3 ... - 此关键字指定在计算路由时访问目标交换机上的 CA 端口的顺序。当结构包含通过多个并行链路连接的交换机时，路由以循环方式分布在这些链路之间，因此更改访问 CA 端口的顺序会更改路由在这些链路之间的分布。这可能对某些特定的流量模式有利。
默认是在目标交换机上以递增的端口顺序访问 CA 端口。列表中重复的值将被忽略。
示例
# Look for a 2D (since x radix is one) 4x5 torus.
torus 1 4 5
# y is radix-4 torus dimension, need both
# ym_link and yp_link configuration.
yp_link 0x200000 0x200005 # sw @ y=0,z=0 -> sw @ y=1,z=0
ym_link 0x200000 0x20000f # sw @ y=0,z=0 -> sw @ y=3,z=0
# z is not radix-4 torus dimension, only need one of
# zm_link or zp_link configuration.
zp_link 0x200000 0x200001 # sw @ y=0,z=0 -> sw @ y=0,z=1
next_seed
yp_link 0x20000b 0x200010 # sw @ y=2,z=1 -> sw @ y=3,z=1
ym_link 0x20000b 0x200006 # sw @ y=2,z=1 -> sw @ y=1,z=1
zp_link 0x20000b 0x20000c # sw @ y=2,z=1 -> sw @ y=2,z=2
y_dateline -2 # Move the dateline for this seed
z_dateline -1 # back to its original position.
# If OpenSM failover is configured, for maximum resiliency
# one instance should run on a host attached to a switch
# from the first seed, and another instance should run
# on a host attached to a switch from the second seed.
# Both instances should use this torus-2QoS.conf to ensure
# path SL values do not change in the event of SM failover.
# port_order defines the order on which the ports would be
# chosen for routing.
port_order 7 10 8 11 9 12 25 28 26 29 27 30
路由链
路由链功能提供了一种解决方案，该解决方案允许用户配置结构的不同部分，并为每个部分定义不同的路由引擎进行路由。路由按顺序完成（因此得名“链”），并且结构中配置在多个部分中的任何节点都将保留由其所属的最后一个路由引擎更新的路由。
配置路由链
要配置路由链
定义端口组。
基于先前定义的端口组定义拓扑。
为每个路由引擎定义配置文件。
在先前定义的拓扑和配置文件上定义路由引擎链。
定义端口组
端口组背后的基本思想是将结构划分为子组，并为每个组提供一个标识符，该标识符可用于关联该组中的所有节点。端口组是独立于路由链的功能，但它是路由链的强制性先决条件。此外，它还用于定义每个路由算法的参与者。
定义端口组策略文件
为了定义端口组策略文件，请在 OpenSM 配置文件中设置参数“pgrp_policy_file”。
pgrp_policy_file /etc/opensm/conf/port_groups_policy_file
配置端口组策略
端口组策略文件详细说明了结构中的端口组。策略文件应由一个或多个定义组的段落组成。每个段落应以“port-group”行开头，以“end-port-group”行结尾。
例如
port-group
…port group qualifiers…
end-port-group
端口组限定符
与不需要冒号的端口组的开头和结尾不同，所有限定符都必须以冒号（“:”）结尾。此外 - 冒号是预定义的标记，不得在限定符值内使用。在名称中包含冒号或使用端口组将导致策略失败。
规则限定符
参数 | 描述 | 示例 |
| 每个组都必须有一个名称。如果没有名称限定符，策略将失败。 |
|
| “use”是一个可选的限定符，可以定义它以描述此端口组的用途（如果未定义，则使用空字符串作为默认值）。 |
|
有几个限定符用于描述确定哪些端口将添加到组的规则。每个端口组可以包含下表描述的规则中的一个或多个规则（每个端口组必须至少定义一个规则）。
参数 | 描述 | 示例 |
| 要包含在组中的 GUID 的逗号分隔列表。 如果未配置特定的物理端口，则选择 guid 的所有物理端口。但是，对于每个 guid，可以详细说明要包含在组中的特定物理端口。这可以使用以下语法完成
|
|
| 可以配置要选择到组的 guid 范围。但是，在使用范围限定符时，无法详细说明特定的物理端口。 注意：不能指定范围列表。以下示例无效，将导致策略失败 port-guid-range: 0x283-0x289, 0x290- 0x295 |
|
| 可以将主机名列表配置为规则。将选择节点描述由这些主机名构建的主机。由于节点描述还包含网卡索引，因此还可以指定网卡索引和要选择的物理端口。例如，给定的配置将导致仅选择节点描述为“kuku HCA-1”的主机的物理端口 2。port 和 hca_idx 参数是可选的。如果未指定端口，则选择所有物理端口。如果未指定 hca_idx，则选择所有卡号。指定主机名是强制性的。 可以在同一限定符中配置主机名/端口/hca_idx 集的列表，如下所示 port-name: hostname=kuku; port=2; hca_idx=1 , hostname=host1; port=3, hostname=host2 注意：port-name 限定符不适用于交换机，仅适用于 HCA。 |
|
| 可以定义正则表达式，以便仅将节点描述与正则表达式匹配的节点选择到组中。 注意：此示例显示了如何选择节点描述以“SW”开头的节点。 |
|
可以指定要为匹配节点选择的一个物理端口（没有选项定义端口列表或端口范围）。给定的示例将导致仅将与物理端口 3 匹配的节点添加到组中。 |
| |
| 可以定义一个规则，该规则联合两个不同的端口组。这意味着两个组中的所有端口都将包含在联合组中。 |
|
| 可以定义一个规则，该规则从另一个端口组中减去一个端口组。例如，给定的规则将导致选择 grp1 的所有端口，但不包括在 grp2 中的端口。 在减法中（与联合不同），顺序很重要，因为目的是从第一个组中减去第二个组。 没有选项为联合/减法定义两个以上的组。但是，可以联合/减去本身是联合或减法的组，如端口组策略文件示例中所示。 |
|
预定义端口组
有 3 个预定义的、自动创建的端口组可供使用，但不能在策略文件中定义（如果在策略中配置的组的名称与这些预定义组之一的名称相同，则策略将失败） -
ALL - 包含结构中所有节点的组
ALL_SWITCHES - 包含结构中所有交换机的组
ALL_CAS - 包含结构中所有 HCA 的组
ALL_ROUTERS - 包含结构中所有路由器的组（OpenSM v4.9.0 及更高版本中支持）
端口组策略示例
port-group
name: grp3
use: Subtract of groups grp1 and grp2
subtract-rule: grp1, grp2
end-port-group
port-group
name: grp1
port-guid: 0x281, 0x282, 0x283
end-port-group
port-group
name: grp2
port-guid-range: 0x282-0x286
port-name: hostname=server1 port=1
end-port-group
port-group
name: grp4
port-name: hostname=kika port=1 hca_idx=1
end-port-group
port-group
name: grp3
union-rule: grp3, grp4
end-port-group
定义拓扑策略文件
为了定义拓扑策略文件，请在 OpenSM 配置文件中设置参数“topo_policy_file”。
topo_policy_file /etc/opensm/conf/topo_policy_file.cfg
配置拓扑策略
拓扑策略文件详细说明了拓扑列表。策略文件应由一个或多个定义拓扑的段落组成。每个段落应以“topol- ogy”行开头，以“end-topology”行结尾。
例如
topology
…topology qualifiers…
end-topology
拓扑限定符
与不需要冒号的 topology 和 end-topology 不同，所有限定符都必须以冒号（“:”）结尾。此外 - 冒号是预定义的标记，不得在限定符值内使用。在限定符值中包含冒号将导致策略失败。
所有拓扑限定符都是强制性的。缺少以下任何限定符都将导致策略解析失败。
拓扑限定符
参数 | 描述 | 示例 |
| 拓扑 ID。 合法值 – 任何正值。必须是唯一的。 |
|
| 包含要在此拓扑中使用的所有交换机和交换机端口的端口组的名称。 |
|
| 包含要在此拓扑中使用的所有 HCA 的端口组的名称。 |
|
每个路由引擎的配置文件
路由链中的每个引擎都可以由其自己的配置文件提供。路由引擎配置文件是在主 OpenSM 配置文件中定义的参数的一部分。
在为路由引擎定义特定配置文件时，应应用一些规则
未在特定路由引擎配置文件中指定的参数将从主 OpenSM 配置文件继承。
以下配置参数仅在主 OpenSM 配置文件中生效
qos 和 qos_* 设置，例如（vl_arb、sl2vl 等）
lmc
routing_engine
定义路由链策略文件
为了定义端口组策略文件，请在 OpenSM 配置文件中设置参数“rch_policy_file”。
rch_policy_file /etc/opensm/conf/chains_policy_file
链中的第一个路由引擎
路由链中的第一个单播引擎必须包含结构中的所有交换机和 HCA（拓扑 ID 必须为 0）。path-bit 参数值为 path-bit 0，并且无法更改。
配置路由链策略
路由链策略文件详细说明了用于结构路由的路由引擎（及其回退引擎）。策略文件应由一个或多个定义
引擎（或回退引擎）的段落组成。每个段落应以“unicast-step”行开头，以“end-unicast-step”行结尾。
例如
unicast-step
…routing engine qualifiers…
end-unicast-step
路由引擎限定符
与不需要冒号的 unicast-step 和 end-unicast-step 不同，所有限定符都必须以冒号（“:”）结尾。此外 - 冒号是预定义的标记，不得在限定符值内使用。在限定符值中包含冒号将导致策略失败。
参数 | 描述 | 示例 |
| “id”是强制性的。如果没有每个引擎的 ID 限定符，策略将失败。
|
|
| 这是一个强制性限定符，描述了在此单播步骤中使用的路由算法。 目前，在路由链的第一阶段，合法值为 minhop/ftree/updn。 |
|
| 这是一个可选的限定符，使用户能够描述此单播步骤的用途。如果未定义，则使用空字符串作为默认值。 |
|
| 这是一个可选的限定符，使用户能够为特定的单播步骤定义单独的 OpenSM 配置文件。如果未定义，则所有参数都取自主 OpenSM 配置文件。 |
|
| 定义此引擎使用的拓扑。
|
|
| 这是一个可选的限定符，使用户能够将当前的单播步骤定义为另一个单播步骤的回退。这可以通过定义此步骤是其回退的单播步骤的 ID 来完成。
|
|
| 这是一个可选的限定符，使用户能够定义当前单播步骤要使用的特定 lid 偏移量。在主 OpenSM 配置文件中设置 lmc > 0 是为路由引擎分配特定路径位的先决条件。 默认值是 0（如果未指定 path-bit） |
|
每个路由引擎的转储文件
如果设置了适当的 log_flags（例如 0x43），则链上的每个路由引擎都将转储其自己的数据文件。
每个引擎转储的文件是
opensm-lid-matrix.dump
opensm-lfts.dump
opensm.fdbs
opensm-subnet.lst
这些文件应包含每个引擎拓扑的相关数据。
sl2vl 和 mcfdbs 文件仅为整个结构转储一次，而不是由每个路由引擎转储。
每个引擎在其转储文件名中连接其 ID 和路由算法名称，如下所示
opensm-lid-matrix.2.minhop.dump
opensm.fdbs.3.ftree
opensm-subnet.4.updn.lst
如果使用回退路由引擎，则失败的路由引擎和替换它的回退引擎都会转储其数据。
例如，如果引擎 2 运行 ftree，并且它有一个 id 为 3 的回退引擎运行 minhop，则应该找到 2 组转储文件，每组文件对应一个引擎
opensm-lid-matrix.2.ftree.dump
opensm-lid-matrix.3.minhop.dump
opensm.fdbs.2.ftree
opensm.fdbs.3.munhop
当在重度扫描期间未检测到拓扑更改时，或者当拓扑更改不需要新的路由计算时（例如，当一个或多个 CA/RTR/叶交换机关闭时，或者当一个或多个这些节点在关闭后恢复时），单播路由缓存可防止路由重新计算（这在大型集群中是一项繁重的任务）。
当在 OpenSM 中启用服务质量 (QoS) 时（使用“-Q”或“--qos”标志），OpenSM 将查找 QoS 策略文件。在结构初始化期间以及每次重度扫描时，OpenSM 都会解析 QoS 策略文件，将其设置应用于已发现的结构元素，并在客户端请求上强制执行提供的策略。此类请求的总体流程如下
请求与定义的匹配规则匹配，以便找到 QoS 级别定义
给定 QoS 级别，将执行路径搜索，并施加该级别给定的限制
定义 QoS 策略有两种方法
高级 – 高级策略文件语法为管理员提供了各种方法来匹配 PathRecord/MultiPathRecord (PR/MPR) 请求，并在请求的 PR/MPR 上强制执行各种 QoS 约束
简单 – 简单策略文件语法使管理员能够通过各种 ULP 以及在这些 ULP 之上运行的应用程序来匹配 PR/MPR 请求
高级 QoS 策略文件
QoS 策略文件具有以下部分
端口组（用 port-groups 表示）- 此部分定义零个或多个端口组，这些端口组稍后可以被匹配规则引用（见下文）。端口组按以下方式列出端口
- 端口 GUID
- 端口名称，它是 NodeDescription 和 IB 端口号的组合
- PKey，这意味着子网中属于具有给定 PKey 的分区的端口都属于此端口组
- 分区名称，这意味着子网中属于具有给定名称的分区的端口都属于此端口组
- 节点类型，可能的节点类型为：CA、SWITCH、ROUTER、ALL 和 SELF（SM 的端口）。
QoS 设置（用 qos-setup 表示）- 此部分描述如何在结构中的各种节点上设置 SL2VL 和 VL 仲裁表。但是，OFED 中不支持此功能。SL2VL 和 VLArb 表应在 OpenSM 选项文件中配置（默认位置 - /var/cache/opensm/opensm.opts）。
QoS 级别（用 qos-levels 表示）- 每个 QoS 级别定义服务级别 (SL) 和一些可选字段
- MTU 限制
- 速率限制
- PKey
- 数据包生存时间
执行路径搜索时，将考虑到这些 QoS 级别参数施加的限制。必须定义的一个 QoS 级别是 DEFAULT QoS 级别。它应用于与任何现有匹配规则都不匹配的 PR/MPR 查询。与任何其他 QoS 级别类似，它也可以被任何匹配规则显式引用。
QoS 匹配规则（用 qos-match-rules 表示）- OpenSM 收到的每个 PathRecord/MultiPathRecord 查询都与一组匹配规则进行匹配。规则按照 QoS 策略文件中出现的顺序进行扫描，例如第一个匹配项优先。
每个规则都有一个将应用于匹配查询的 QoS 级别的名称。默认 QoS 级别应用于与任何规则都不匹配的查询。
查询可以通过以下方式匹配
- 源端口组（源端口是否是指定组的成员）
- 目标端口组（与上面相同，仅适用于目标端口）
- PKey
- QoS 类
- 服务 ID
为了匹配某个匹配规则，PR/MPR 查询必须匹配规则的所有标准。但是，并非 PR/MPR 查询的所有字段都必须出现在匹配规则中。
例如，如果规则只有一个标准 - 服务 ID，它将匹配具有此服务 ID 的任何查询，而忽略查询字段的其余部分。但是，如果某个查询只有服务 ID（这意味着这是 PR/MPR 组件掩码中唯一打开的位），则它将不匹配任何除了服务 ID 之外还有其他匹配标准的规则。
简单 QoS 策略定义
简单 QoS 策略定义包含一个用 qos-ulps 表示的单个部分。与高级 QoS 策略类似，它具有匹配规则列表及其 QoS 级别，但在这种情况下，匹配规则只有一个标准 - 其目标是匹配某个 ULP（或此 ULP 之上的某个应用程序）PR/MPR 请求，并且 QoS 级别只有一个约束 - 服务级别 (SL)。
简单策略部分可以与高级策略一起出现在策略文件中，也可以作为独立的策略定义出现。请参阅下面的更多详细信息和匹配规则标准列表。
策略文件语法指南
前导和尾随空格以及空行将被忽略，因此示例中的缩进只是为了提高可读性。
注释以磅符号 (#) 开头，以 EOL 结尾。
任何关键字都应该是行中的第一个非空白字符，除非它是注释。
表示节/子节开始的关键字具有匹配的结束关键字。
必须有一个名为“DEFAULT”的 QoS 级别 - 它应用于与任何匹配规则都不匹配的 PR/MPR 请求。
策略文件的任何节/子节都是可选的。
高级策略文件示例
如前所述，策略文件的任何部分都是可选的，策略文件中唯一强制性的部分是默认 QoS 级别。
这是最短策略文件的示例
qos-levels
qos-level
name: DEFAULT
sl: 0
end-qos-level
end-qos-levels
端口组部分缺失，因为没有匹配规则，这意味着端口组在任何地方都没有被引用，因此无需定义它们。并且由于此策略文件没有任何匹配规则，因此 PR/MPR 查询将不匹配任何规则，并且 OpenSM 将强制执行默认 QoS 级别。从本质上讲，上面的示例等效于根本没有 QoS 策略文件。
以下示例显示了策略文件中所有可能的选项和关键字及其语法
#
# See the comments in the following example.
# They explain different keywords and their meaning.
#
port-groups
port-group # using port GUIDs
name: Storage
# "use" is just a description that is used for logging
# Other than that, it is just a comment
use: SRP Targets
port-guid: 0x10000000000001, 0x10000000000005-0x1000000000FFFA
port-guid: 0x1000000000FFFF
end-port-group
port-group
name: Virtual Servers
# The syntax of the port name is as follows:
# "node_description/Pnum".
# node_description is compared to the NodeDescription of the node,
# and "Pnum" is a port number on that node.
port-name: “vs1 HCA-1/P1, vs2 HCA-1/P1”
end-port-group
# using partitions defined in the partition policy
port-group
name: Partitions
partition: Part1
pkey: 0x1234
end-port-group
# using node types: CA, ROUTER, SWITCH, SELF (for node that runs SM)
# or ALL (for all the nodes in the subnet)
port-group
name: CAs and SM
node-type: CA, SELF
end-port-group
end-port-groups
qos-setup
# This section of the policy file describes how to set up SL2VL and VL
# Arbitration tables on various nodes in the fabric.
# However, this is not supported in OFED - the section is parsed
# and ignored. SL2VL and VLArb tables should be configured in the
# OpenSM options file (by default - /var/cache/opensm/opensm.opts).
end-qos-setup
qos-levels
# Having a QoS Level named "DEFAULT" is a must - it is applied to
# PR/MPR requests that didn't match any of the matching rules.
qos-level
name: DEFAULT
use: default QoS Level
sl: 0
end-qos-level
# the whole set: SL, MTU-Limit, Rate-Limit, PKey, Packet Lifetime
qos-level
name: WholeSet
sl: 1
mtu-limit: 4
rate-limit: 5
pkey: 0x1234
packet-life: 8
end-qos-level
end-qos-levels
# Match rules are scanned in order of their appearance in the policy file.
# First matched rule takes precedence.
qos-match-rules
# matching by single criteria: QoS class
qos-match-rule
use: by QoS class
qos-class: 7-9,11
# Name of qos-level to apply to the matching PR/MPR
qos-level-name: WholeSet
end-qos-match-rule
# show matching by destination group and service id
qos-match-rule
use: Storage targets
destination: Storage
service-id: 0x10000000000001, 0x10000000000008-0x10000000000FFF
qos-level-name: WholeSet
end-qos-match-rule
qos-match-rule
source: Storage
use: match by source group only
qos-level-name: DEFAULT
end-qos-match-rule
qos-match-rule
use: match by all parameters
qos-class: 7-9,11
source: Virtual Servers
destination: Storage
service-id: 0x0000000000010000-0x000000000001FFFF
pkey: 0x0F00-0x0FFF
qos-level-name: WholeSet
end-qos-match-rule
end-qos-match-rules
简单 QoS 策略 - 详细信息和示例
简单 QoS 策略匹配规则是为匹配 ULP（或 ULP 之上的一些应用程序）PR/MPR 请求量身定制的。此部分具有每个 ULP（或每个应用程序）的匹配规则列表以及应在匹配的 PR/MPR 查询上强制执行的 SL。
匹配规则包括
应用于与任何其他匹配规则都不匹配的 PR/MPR 查询的默认匹配规则
具有默认 PKey 的 IPoIB
具有特定 PKey 的 IPoIB
PR/MPR 查询中具有特定服务 ID 的任何 ULP/应用程序
PR/MPR 查询中具有特定 PKey 的任何 ULP/应用程序
PR/MPR 查询中具有特定目标 IB 端口 GUID 的任何 ULP/应用程序
由于策略文件的任何部分都是可选的，只要保持文件的基本规则（例如，不引用不存在的端口组，具有默认 QoS 级别等），简单策略部分 (qos-ulps) 就可以充当完整的 QoS 策略文件。
在这种情况下，最短的策略文件将如下所示
qos-ulps
default : 0 #default SL
end-qos-ulps
它等效于先前最短策略文件的示例，并且也等效于根本没有策略文件。以下是包含所有可能的关键字的简单 QoS 策略示例
qos-ulps
default :0 # default SL
sdp, port-num 30000 :0 # SL for application running on
# top of SDP when a destination
# TCP/IPport is 30000
sdp, port-num 10000-20000 : 0
sdp :1 # default SL for any other
# application running on top of SDP
rds :2 # SL for RDS traffic
ipoib, pkey 0x0001 :0 # SL for IPoIB on partition with
# pkey 0x0001
ipoib :4 # default IPoIB partition,
# pkey=0x7FFF
any, service-id 0x6234:6 # match any PR/MPR query with a
# specific Service ID
any, pkey 0x0ABC :6 # match any PR/MPR query with a
# specific PKey
srp, target-port-guid 0x1234 : 5 # SRP when SRP Target is located
# on a specified IB port GUID
any, target-port-guid 0x0ABC-0xFFFFF : 6 # match any PR/MPR query
# with a specific target port GUID
end-qos-ulps
与高级策略定义类似，PR/MPR 查询的匹配按 QoS 策略文件中出现的顺序进行，例如，第一个匹配项优先，但“default”规则除外，该规则仅在查询与任何其他规则都不匹配时才应用。QoS 策略文件的所有其他部分都优先于 qos-ulps 部分。也就是说，如果策略文件同时具有 qos-match-rules 和 qos-ulps 部分，则任何查询首先与 qos-match-rules 部分中的规则匹配，并且仅当没有匹配项时，查询才与 qos-ulps 部分中的规则匹配。
请注意，其中一些匹配规则可能会重叠，因此为了有效地使用简单 QoS 定义，重要的是要了解每个 ULP 是如何匹配的。
IPoIB
IPoIB 查询通过 PKey 或目标 GID 匹配，在这种情况下，这是 OpenSM 为每个 IPoIB 分区创建的多播组的 GID。
IPoIB 分区默认 PKey 为 0x7fff，因此以下三个匹配规则是等效的
ipoib:<SL>ipoib, pkey 0x7fff : <SL>
any, pkey 0x7fff : <SL>
SRP
SRP 的服务 ID 因存储供应商而异，因此 SRP 查询通过目标 IB 端口 GUID 进行匹配。以下两个匹配规则是等效的
srp, target-port-guid 0x1234 : <SL>
any, target-port-guid 0x1234 : <SL>
请注意，以上任何 ULP 都可能在 PR 查询中包含目标端口 GUID，因此为了使 QoS 管理器不将这些查询识别为 SRP，SRP 匹配规则（或任何仅引用目标端口 GUID 的匹配规则）应放在 qos-ulps 匹配规则的末尾。
MPI
MPI 的 SL 由 MPI 管理员手动配置。OpenSM 没有强制 MPI 流量使用任何 SL，这解释了为什么它是唯一没有出现在 qos-ulps 部分的 ULP。
SL2VL 映射和 VL 仲裁
OpenSM 缓存的选项文件包含一组 QoS 相关配置参数，用于配置 IB 端口上的 SL2VL 映射和 VL 仲裁。这些参数是
最大 VL 数：子网上将存在的最大 VL 数
高优先级限制：VL 仲裁表的高优先级组件的限制 (IBA 7.6.9)
VLArb 低优先级表：低优先级 VL 仲裁表 (IBA 7.6.9) 模板
VLArb 高优先级表：高优先级 VL 仲裁表 (IBA 7.6.9) 模板
SL2VL：SL2VL 映射表 (IBA 7.6.6) 模板。它是对应于 SL 0-15 的 VL 列表（请注意，此处使用的 VL15 表示丢弃此 SL）。
各种目标类型都有单独的 QoS 配置参数集：CA、路由器、交换机外部端口和交换机的增强端口 0。此类参数的名称以 "qos_<type>_" 字符串为前缀。以下是当前支持的完整列表
qos_ca_ —CA 的 QoS 配置参数集。
qos_rtr_ —路由器的参数集。
qos_sw0_ —交换机端口 0 的参数集。
qos_swe_ —交换机外部端口的参数集。
以下是 CA 和交换机外部端口的典型默认值示例（硬编码在 OpenSM 初始化中）
qos_ca_max_vls 15
qos_ca_high_limit 0
qos_ca_vlarb_high 0:4,1:0,2:0,3:0,4:0,5:0,6:0,7:0,8:0,9:0,10:0,11:0,12:0,13:0,14:0
qos_ca_vlarb_low 0:0,1:4,2:4,3:4,4:4,5:4,6:4,7:4,8:4,9:4,10:4,11:4,12:4,13:4,14:4
qos_ca_sl2vl 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,7
qos_swe_max_vls 15
qos_swe_high_limit 0
qos_swe_vlarb_high 0:4,1:0,2:0,3:0,4:0,5:0,6:0,7:0,8:0,9:0,10:0,11:0,12:0,13:0,14:0
qos_swe_vlarb_low 0:0,1:4,2:4,3:4,4:4,5:4,6:4,7:4,8:4,9:4,10:4,11:4,12:4,13:4,14:4
qos_swe_sl2vl 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,7
VL 仲裁表（高优先级和低优先级）是 VL/权重对的列表。每个列表条目包含一个 VL 编号（值从 0-14）和一个权重值（值 0-255），指示当轮到仲裁时，可以从该 VL 传输的 64 字节单元（信用）的数量。权重为 0 表示应跳过此条目。如果为 VL15 或不支持或当前未由端口配置的 VL 编程列表条目，则端口可以跳过该条目或从该条目的任何受支持的 VL 发送。
请注意，相同的 VL 可以在高优先级或低优先级仲裁表中多次列出，并且还可以同时在两个表中列出。高优先级 VLArb 表的限制 (qos_如果使用 255 值，则低优先级 VL 可能会被饿死。
值为 0 表示在高优先级表中的单个数据包发送之前，会给低优先级表一个机会。
请记住，端口通常传输大小等于 MTU 的数据包。例如，对于 4KB MTU，单个数据包将需要 64 个信用，因此为了实现 4KB MTU 数据包的有效 VL 仲裁，每个 VL 的权重值应为 64 的倍数。以下是子网上 SL2VL 和 VL 仲裁配置的示例
qos_ca_max_vls 15
qos_ca_high_limit 6
qos_ca_vlarb_high 0:4
qos_ca_vlarb_low 0:0,1:64,2:128,3:192,4:0,5:64,6:64,7:64
qos_ca_sl2vl 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,7
qos_swe_max_vls 15
qos_swe_high_limit 6
qos_swe_vlarb_high 0:4
qos_swe_vlarb_low 0:0,1:64,2:128,3:192,4:0,5:64,6:64,7:64
qos_swe_sl2vl 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,7
在此示例中，子网上配置了 8 个 VL：VL0 到 VL7。VL0 定义为高优先级 VL，并且在单次传输突发中限制为 6 x 4KB = 24KB。这种配置适用于需要低延迟并在传输数据包时使用小 MTU 的 VL。其余 VL 定义为具有不同权重的低优先级 VL，而 VL4 被有效关闭。
部署示例
下图显示了 InfiniBand 子网的示例，该子网已由 QoS 管理器配置为为各种 ULP 提供不同的服务级别。
InfiniBand 子网上的 QoS 部署示例
QoS 配置示例
以下是不同集群部署的 QoS 配置示例。每个示例都提供了 QoS 级别分配以及通过 OpenSM 配置文件进行的管理。
典型 HPC 示例：MPI 和 Lustre
QoS 级别分配
MPI
与 I/O 负载分离
最小带宽 70%
存储控制 (Lustre MDS)
低延迟
存储数据 (Lustre OST)
最小带宽 30%
管理
MPI 通过命令行分配 SL
host1# mpirun –sl 0
OpenSM QoS 策略文件
qos-ulps
default:0#defaultSL (forMPI) any, target-port-guid OST1,OST2,OST3,OST4 :1# SLforLustre OST any, target-port-guid MDS1,MDS2 :2# SLforLustre MDS end-qos-ulps注意：在此策略文件示例中，将 OST* 和 MDS* 替换为真实的端口 GUID。
OpenSM 选项文件
qos_max_vls
8qos_high_limit0qos_vlarb_high2:1qos_vlarb_low0:96,1:224qos_sl2vl0,1,2,3,4,5,6,7,15,15,15,15,15,15,15,15
EDC SOA（两层）：IPoIB 和 SRP
以下是典型企业数据中心 (EDC) 的 QoS 配置示例，该数据中心具有面向服务的架构 (SOA)，其中 IPoIB 承载所有应用程序流量，SRP 用于存储。
QoS 级别
应用程序流量
IPoIB（UD 和 CM）和 SDP
与存储隔离
最小带宽 50%
SRP
最小带宽 50%
存储节点瓶颈
管理
OpenSM QoS 策略文件
qos-ulps
default:0ipoib :1sdp :1srp, target-port-guid SRPT1,SRPT2,SRPT3 :2end-qos-ulps注意：在此策略文件示例中，将 SRPT* 替换为真实的 SRP 目标端口 GUID。
OpenSM 选项文件
qos_max_vls
8qos_high_limit0qos_vlarb_high1:32,2:32qos_vlarb_low0:1, qos_sl2vl0,1,2,3,4,5,6,7,15,15,15,15,15,15,15,15
EDC（三层）：IPoIB、RDS、SRP
以下是企业数据中心 (EDC) 的 QoS 配置示例，其中 IPoIB 承载所有应用程序流量，RDS 用于数据库流量，SRP 用于存储。
QoS 级别
管理流量 (ssh)
IPoIB 管理 VLAN（分区 A）
最小带宽 10%
应用程序流量
IPoIB 应用程序 VLAN（分区 B）
与存储和数据库隔离
最小带宽 30%
数据库集群流量
RDS
最小带宽 30%
SRP
最小带宽 30%
存储节点瓶颈
管理
OpenSM QoS 策略文件
qos-ulps
default:0ipoib, pkey0x8001:1ipoib, pkey0x8002:2rds :3srp, target-port-guid SRPT1, SRPT2, SRPT3 :4end-qos-ulps注意：在以下策略文件示例中，将 SRPT* 替换为真实的 SRP 发起方端口 GUID。
OpenSM 选项文件
qos_max_vls
8qos_high_limit0qos_vlarb_high1:32,2:96,3:96,4:96qos_vlarb_low0:1qos_sl2vl0,1,2,3,4,5,6,7,15,15,15,15,15,15,15,15分区配置文件
Default=
0x7fff,ipoib : ALL=full;PartA=0x8001, sl=1, ipoib : ALL=full;
增强型 QoS
增强型 QoS 在服务级别 (SL) 提供更高的 QoS 分辨率。用户可以使用 enhanced_qos_policy_file 配置参数为物理端口、虚拟端口和端口组配置每 SL 的速率限制值。
此参数的有效值
通过其配置增强型 QoS 管理器的策略文件的完整路径
"null" - 禁用增强型 QoS 管理器（默认值）
要启用增强型 QoS 管理器，必须在 OpenSM 中启用 QoS。
增强型 QoS 策略文件
策略文件由三个部分组成
BW_NAMES：用于定义带宽设置和名称（目前，速率限制是唯一的设置）。带宽名称可以在 BW_RULES 和 VPORT_BW_RULES 部分中使用。
带宽名称使用以下语法定义
<name> = <速率限制，单位为 Mbps>示例：
My_bandwidth = 50BW_RULES：用于定义将带宽设置映射到特定 GUID 的特定 SL 的规则。
带宽规则使用以下语法定义
<guid>|<端口组名称> = <sl id>:<带宽名称>, <sl id>:<带宽名称>…示例
0x2c90000000025 = 5:My_bandwidth, 7:My_bandwidthPort_grp1 = 3:My_bandwidth, 9:My_bandwidthVPORT_BW_RULES：用于定义将带宽设置映射到特定虚拟端口 GUID 的特定 SL 的规则。
带宽规则使用以下语法定义
<guid>= <sl id>:<带宽名称>, <sl id>:<带宽名称>…示例0x2c90000000026= 5:My_bandwidth, 7:My_bandwidth
特殊关键字
关键字 “all” 允许将特定物理端口或虚拟端口的所有 SL 的速率限制设置为某个 BW。可以将 “all” 与特定的 SL 速率限制结合使用。
示例
0x2c90000000025 = all:BW1,SL3:BW2在这种情况下，SL3 将被分配 BW2 速率限制，而其余 SL 将获得 BW1 速率限制。“default” 是一个众所周知的名称，可用于定义没有定义规则的任何 GUID 的默认规则。
如果未定义默认规则，则任何没有特定规则的 GUID 将被配置为所有 SL 的无限速率限制。
关键字 “all” 也适用于默认规则。默认规则是每个部分的本地规则。
特殊子网管理器配置选项
新的 SM 配置选项 enhanced_qos_vport0_unlimit_default_rl 已添加到 opensm.conf。
此配置选项的可能值包括
TRUE：对于特定的虚拟端口 0 GUID，无论 VPORT_BW_RULES 部分的默认规则如何，带宽规则中未提及的 SL 都将被设置为无限带宽 (0)。
VPORT_BW_SECTION 中未提及的虚拟端口 0 GUID 将在所有 SL 上设置为无限 BW。
FALSE：虚拟端口 0 的 GUID 在 VPORT_BW_SECTION 中被视为任何其他虚拟端口。
一旦选项更改，应通过 HUP 向 SM 发出信号。
默认值：TRUE
注释
当速率限制设置为 0 时，表示带宽不受限制。
如果在未指定默认规则的情况下，规则中任何未指定的 SL 将自动设置为 0（无限）速率限制。
策略文件解析失败会导致未定义的行为。用户必须确认 SM 日志中没有相关错误消息，以确保增强型 QoS 管理器配置正确。
仅包含 'BW_NAMES' 和 'BW_RULES' 关键字的文件会将网络配置为无限速率限制。
HCA 物理端口 GUID 可以在 BW_RULES 和 VPORT_BW_RULES 部分中指定。
在 BW_RULES 部分中，分配给特定 SL 的速率限制将限制可以在给定 SL 上通过 PF 发送的总 BW。
在 VPORT_BW_RULES 部分中，分配给特定 SL 的速率限制将仅限制从与物理端口 GUID 对应的 IB 接口（虚拟端口 0 IB 接口）发送的流量。如果未定义特定规则，则从其他虚拟 IB 接口发送的流量将不受限制。
策略文件示例
Fabric 中的所有物理端口在 SL1 上的速率限制为 50Mbps，但 GUID 0x2c90000000025 除外，后者在 SL1 上配置的速率限制为 25Mbps。在此示例中，SL（SL1 除外）上的流量不受限制。
由于 VPORT_BW_RULES 部分的默认规则，Fabric 中的所有虚拟端口（所有物理端口的虚拟端口 0 除外）的所有 SL 的速率限制都将为 15Mbps。
虚拟端口 GUID 0x2c90000000026 在 SL3 上的速率限制配置为 10Mbps。由于 VPORT_BW_RULES 部分的默认规则，此虚拟端口上的其余 SL 将获得 15 Mbps 的速率限制。
-----------------------------------------------------------------------
BW_NAMES
bw1 = 50
bw2 = 25
bw3 = 15
bw4 = 10
BW_RULES
default= 1:bw1
0x2c90000000025= 1:bw2
VPORT_BW_RULES
default= all:bw3
0x2c90000000026= 3:bw4
------------------------------------------------------------------------
自适应路由管理器支持高级 InfiniBand 功能；自适应路由 (AR) 和自愈网络。
有关如何设置 AR 和自愈网络的信息，请参阅 如何配置自适应路由和自愈网络 社区帖子。
DOS MAD 防护
DOS MAD 防护是通过为每个代理的 RX 分配阈值来实现的。代理的 RX 阈值通过使用阈值限制代理的 RX 来提供针对主机内存的保护机制。超过阈值的传入 MAD 将被丢弃，并且不会排队到代理的 RX。
要启用 DOS MAD 防护
转到 /etc/modprobe.d/mlnx.conf。
将以下选项添加到文件中。
ib_umad enable_rx_threshold
1
阈值可以通过用户空间通过 libibumad 进行控制。
要更改值，请使用以下 API
int umad_update_threshold(int fd, int threshold);
@fd: file descriptor, agent's RX associated to this fd.
@threshold: new threshold value
为了在 OpenSM 中启用 IB 路由器，应配置以下参数
OpenSM 的 IB 路由器参数
参数 | 描述 | 默认值 |
| 定义 SM 是否应为每个端口创建路由器支持所需的别名 GUID。 定义在与路由器相关的路径记录的响应中使用的流标签值。 | 0（禁用） |
rtr_pr_tclass | 定义在与路由器相关的路径记录的响应中使用的 TClass 值 | 0 |
rtr_pr_sl | 定义在与路由器相关的路径记录的响应中使用的 sl 值。 | 0 |
rtr_p_mtu | 定义在与路由器相关的路径记录的响应中使用的 MTU 值。 | 4 (IB_MTU_LEN_2048) |
rtr_pr_rate | 定义在与路由器相关的路径记录的响应中使用的速率值。 | 16 (IB_PATH_RE- CORD_RATE_100_GBS) |
OpenSM 可以生成活动报告，报告形式为转储文件，其中详细说明了 SM 中完成的不同活动。活动分为主题。下面的 OpenSM 支持的活动表指定了 SM 活动报告中当前支持的不同活动。
可以使用配置参数 activity_report_subjects 单独启用每个主题的报告
有效值
要转储的主题的逗号分隔列表。当前支持的主题包括
“mc” - 活动 ID 1、2 和 8
“prtn” - 活动 ID 3、4 和 5
“virt” - 活动 ID 6 和 7
“routing” - 活动 ID 8-12
也可以配置两个预定义值
“all” - 转储所有主题
“none” - 通过不转储任何主题来禁用该功能
默认值：“none”
OpenSM 支持的活动
活动 ID | 活动名称 | 附加字段 | 注释 | 描述 |
1 | mcm_member |
| 加入状态 1 - 加入 -1 - 离开 | 成员加入/离开 MC 组 |
2 | mcg_change |
| 更改 0 - 创建 1 - 删除 | MC 组已创建/已删除 |
3 | prtn_guid_add |
| Guid 已添加到分区 | |
4 | prtn_create | -PKey
| 分区已创建 | |
5 | prtn_delete |
| 删除原因 0 - 空分区 1 - 重复分区 2 - sm 关闭 | 分区已删除 |
6 | port_virt_discover |
| 端口虚拟化已发现 | |
7 | vport_state_change |
| VPort 状态 1 - 关闭 2 - 初始化 3 - ARMED 4 - 活动 | Vport 状态已更改 |
8 | mcg_tree_calc | mlid | MCast 组树已计算 | |
9 | routing_succeed | 路由引擎名称 | 路由已成功完成 | |
10 | routing_failed | 路由引擎名称 | 路由失败 | |
11 | ucast_cache_invali- dated | ucast 缓存已失效 | ||
12 | ucast_cache_rout- ing_done | ucast 缓存路由已完成 |
当使用 minhop/dor/updn 时，子网管理器可以在空闲时间（扫描之间）重新平衡路由。
offsweep_balancing_enabled - 启用/禁用该功能。示例
offsweep_balancing_enabled = TRUE
offsweep_balancing_enabled = FALSE（默认）
offsweep_balancing_window - 定义在扫描后等待多少秒才开始重新平衡过程的窗口。仅当 offsweep_balancing_enabled=TRUE 时适用。示例
offsweep_balancing_window = 180（默认）