-
OpenSM-QoS管理
目录
缩写 全拼 中文 SM Subnet Manager 子网管理器（实体） SA Subnet Administrator 子网管理（接口） QoS Quality of Service 服务质量 PR PathRecord 路由记录 MPR MultiPathRecord 多播路由记录 ULP Upper Layer Protocol 上层协议 SL Service Level 服务级别 VL Virtual Lanes 虚通道 PKey Partition Key 分区键 一、概述
QoS的诉求来源于IB网络需要实现IB网络I/O的访问。由于多个应用程序和ULP共享同一组网，因此需要一种方法来控制它们对网络资源的使用。
基本诉求是给不同业务流提供的不同服务级别，以便可以执行策略，以此来控制组网资源的每个流利用率。
InfiniBand体系结构规范定义了几个支持QoS的硬件功能和管理接口：
多达15条虚通道（VL）以非阻塞方式承载流量：
- 不同VL之间的流量仲裁由一个双优先级加权循环仲裁器执行。仲裁器可编程：1、具有一系列（VL，权重）对；2、在提供低优先级服务之前要处理的最大数量的高优先级信用证。
- 数据包在其标头SL字段中携带范围为0到15的服务类别标记。
- 每个交换机都可以根据可编程表VL=SL-to-VL-MAP（入端口、出端口、SL）将传入数据包的SL映射到特定的输出VL。
- 子网管理员通过提供参数作为对PR/MPR查询的响应来控制每个通信流的参数。
OpenSM使能的时候，会去寻找QoS策略文件。默认路径为/usr/local/etc/opensm/qos-policy.conf。
当组网部署过程中，每一次扫描发现新的设备时，OpenSM都会解析QoS策略文件并把它部署上去，然后每一个客户端请求都会强制执行这个提供的QoS策略。此类请求的总体流程是：
- 当这个请求与定义的规则相匹配时，QoS级别的定义就找到了。
- 给定QoS级别，就在该级别施加的给定限制下执行路径搜索。
有两种方法去定义QoS策略。
- 全量策略，这个策略文件语法给管理者多种方式去匹配PR/MPR请求，然后强制对其实现QoS限制。
- 简单QoS策略，管理员可以在ULP以及ULP之上的应用来匹配各种 PR/MPR 请求。
虽然完整的策略语法非常灵活，但在许多情况下简化的 策略定义就足够了。
二、完整QoS策略文件
QoS策略文件包含以下部分：
1.端口组。
本节定义了零个或多个端口组，这些端口组可以通过以下匹配规则描述：
- 端口GUID。
- 端口名称，它是节点描述和IB端口号的组合。
- PKey，这意味着子网中具有给定PKey的分区的所有端口都属于该端口组。
- 分区名称，这意味着子网中具有特定分区名称的所有端口都属于此端口组。
- 节点类型，可能的节点类型有：CA、SWITCH、ROUTER、ALL和SELF（SM的端口）
2.QoS设置
本节介绍如何在组网的各个节点上设置SL2VL和VL仲裁表。
但是，OpenSM目前不支持此功能。
SL2VL和VLArb表应在OpenSM选项文件中配置。（默认位置-/usr/local/etc/opensm/opensm.conf）
3.QoS级别
每个QoS级别定义SL和一些可选字段：
- MTU限制
- 速率限制
- PKey公司
- 数据包生存周期
当执行路径搜索时，必须按照QoS级别参数施加的限制进行搜索。必须定义一个DEFAULT QoS级别，PR/MPR查询匹配不上任何策略时应用。类似于任何其他QoS级别，它也可以由任何匹配规则显式引用。
4.QoS匹配规则（由QoS匹配规则表示）。
OpenSM接收到的每个PR/MPR查询都根据一组匹配规则进行匹配。按照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级别。
- 策略文件的节/小节都是可选的。
五、完整策略文件示例
如前所述，策略文件的任何部分都是可选的，并且策略文件的唯一强制部分是默认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 OpenSM currently - the section is
- # parsed and ignored. SL2VL and VLArb tables should be configured in the
- # OpenSM options file (by default - /usr/local/etc/opensm/opensm.conf).
- 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。
匹配规则包括：
- 默认匹配规则
- SDP
- SDP应用，有特定的目标TCP/IP端口号范围。
- SRP有特定的目的IB端口GUID
- RDS
- iSER
- iSER应用，有特定的目标TCP/IP端口号范围。
- IPoIB，默认PKey
- IPoIB，有特定的PKey
- 任何ULP/应用有特定Service ID
- 任何ULP/应用有特定PKey
- 任何ULP/应用有特定目的IB端口GUID
- 任何ULP/应用有特定源IB端口GUID
- 任何ULP/应用有特定源和目的IB端口GUID
由于策略文件的任何部分都是可选的，只要保留文件的基本规则（例如不引用不存在的端口组、具有默认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
- iser, port-num 900 : 0 # SL for iSER with a specific target
- # port
- iser : 3 # default SL for iSER
- 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
- any, source-port-guid 0x5678 : 7 # match any PR/MPR query with
- # a specific source port
- # GUID
- any, source-target-port-guid 0x9abcd : 8 # match any PR/MPR query with
- # a specific source or target port
- # GUID
- end-qos-ulps
与完整的策略定义类似，PR/MPR查询的匹配是按照QoS策略文件中出现的顺序进行的，例如第一个匹配优先，但“默认”规则除外，该规则仅在查询与任何其他规则不匹配时应用。
QoS策略文件的所有其他部分优先于qos-ulps部分。也就是说，如果策略文件同时具有qos-match-rules和qos-ulps部分，则任何查询都将首先与qos-match-rules相匹配，并且只有在没有匹配的情况下，才与qos-ulps中的规则进行匹配。
请注意，这些匹配规则中的一些可能重叠，因此为了有效地使用简化的QoS定义，了解每个ULP是如何匹配的很重要：
6.1 IPoIB
IPoIB查询由PKey匹配。IPoIB分区的默认PKey为0x7fff，因此以下三个匹配规则是等效的：
- ipoib : <SL>
- ipoib, pkey 0x7fff : <SL>
- any, pkey 0x7fff : <SL>
6.2 SDP
SDP PR 查询是匹配Service ID. SDP的Service-ID是
0x000000000001PPPP, 其中PPPP是4个十六进制数字，用于保存要连接的远程TCP/IP端口号. 以下两个匹配规则是等效的：
- sdp : <SL>
- any, service-id 0x0000000000010000-0x000000000001ffff : <SL>
6.3 RDS
与SDP类似，RDS PR查询由Service ID匹配。RDS的Service ID是0x000000000106PPP，其中PPPP是4个十六进制数字，用于保存远程TCP/IP要连接的端口号。RDS的默认端口号为0x48CA，这使得默认服务ID 0x00000000010648CA。以下两条匹配规则是等效：
- rds : <SL>
- any, service-id 0x00000000010648CA : <SL>
6.4 iSER
与RDS类似，iSER查询由服务ID匹配，其中服务ID也是0x000000000106PPP。iSER的默认端口号为0x0CBC，这使得默认服务ID为0x0000000001060CBC。以下两个匹配规则是等效的：
- iser : <SL>
- any, service-id 0x0000000001060CBC : <SL>
6.5 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匹配规则的末尾。
6.6 MPI
MPI的SL由MPI管理员手动配置。OpenSM没有在MPI流量上强制使用任何SL，这就是为什么它是唯一一个没有出现在qos-ulps部分中的ULP。
七、SL2VL映射和VL仲裁
OpenSM缓存选项文件有一组与QoS相关的配置参数，用于配置IB端口上的SL2VL映射和VL仲裁。
这些参数是：
- Max VLs: 子网上的最大VL数。
- High limit: VL仲裁表的高优先级组件的限制(IBA 7.6.9).
- VLArb low table: 低优先级VL仲裁表（IBA 7.6.9）模板.
- VLArb high table: 高优先级VL仲裁表（IBA 7.6.9）模板.
- SL2VL: SL2VL映射表（IBA 7.6.6）模板。它是对应于SL 0-15的VL的列表（注意，这里使用的VL15意味着丢弃该SL）。
对于各种目标类型，有单独的QoS配置参数集：
CA、路由器、交换机外部端口和交换机的增强端口0。这些参数的名称以“qos_
_”字符串为前缀。以下是当前支持的集合的完整列表： 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在仲裁中发生时可以从该VL发送的64字节单元（信用）的数量。权重为0表示应跳过此条目。如果为VL15或端口不支持或当前未配置的VL编程了列表条目，则端口可以跳过该条目或从任何支持的VL发送该条目。
注意，相同的VL可以在高优先级仲裁表或低优先级仲裁表中多次列出，而且，它可以在两个表中都列出。
高优先级VLArb表的限制（qos_
_high_limit）指示可以在没有机会发送低优先级分组的情况下发送的高优先级分组的数量。具体而言，可以发送的字节数是4K字节的high_limit倍。 high_limit值为255表示字节限制是无限制的。
注意：如果使用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被有效地关闭。
参考资料：
1.OpenSM源码
2.QoS - Quality of Service - MLNX_OFED v5.6-1.0.3.3 - NVIDIA Networking Docs
-
相关阅读:
【“在路上”疫情信息检测】——项目页面搭建
【踩坑实录】datax从pg同步数据到hive数据全为null问题
IDEA2023创建SpringMVC项目
面试官：字节流可以处理一切文件为什么还需要字符流呢？
好用的在线客服系统PHP源码(开源代码+终身使用+安装教程)
【接口测试】Postman（二）-Postman Echo
HTML5文旅文化旅游网站模板源码
CouchDB简单入门
flutter版本dart版本对应关系
Deno 的配置文件、框架，标准库
- 原文地址：https://blog.csdn.net/smartvxworks/article/details/133807588