CXL QoS Telemetry 介绍

---

点击查看精选 CXL 系列文章
点击进入【芯片设计验证】社区，查看更多精彩内容

---

 声明：

• 作者主页：【MangoPapa的CSDN主页】。
• ⚠️ 本文首发于CSDN，转载或引用请注明出处【https://mangopapa.blog.csdn.net/article/details/131745195】。
• ⚠️ 本文目的为 个人学习记录 及 知识分享。因个人能力受限，存在协议解读不正确的可能。若您参考本文进行产品设计或进行其他事项并造成了不良后果，本人不承担相关法律责任。
• ⚠️ 若本文所采用图片或相关引用侵犯了您的合法权益，请联系我进行删除。
• 欢迎大家指出文章错误，欢迎同行与我交流 ~
• 邮箱：[email protected]
• 直达博主：loveic_lovelife 。（搜索或点击扫码）

---

---

1. QoS Telemetry 概念

---

  Memory 访问时延跟负载程度（已用带宽）的关系示意图如下图所示。从图中可见，负载越重访问时延越大。当负载超过最优负载时，访问延时急剧增长。为了获取最佳性能，Host 可以对发出访问请求的频率进行调整，以平衡访问带宽和延时。

  QoS Telemetry 最早在 CXL 2.0 版本中出现，是一种工作负载调控机制。常规的 QoS 蕴含在 Req 中，是 Host 发送给 Slave 的指示信息，Device 根据 QoS 的值对接收到的请求提供不同的服务质量。CXL QoS Telemetry 则蕴含在 S2M NDR/DRS 等 Rsp 中，是 Subordinate 反馈给 Master 的指示信息，指示 Subordinate 当前的负载情况，Master 根据该指示信息调整发出请求的速率。

  （注：为便于表述，Host/Switch 在下文中统一表述为 Host。）

---

2. QoS Telemetry 的能力需求

---

  CXL QoS Telemetry 是一种 Memory 服务质量控制机制，仅适用于含有 CXL.mem 的 Type 2/3 Device 中，对于 Type 1 类型的 Cache Only 设备则没有强制的要求。对于支持 CXL 的 Host，强烈建议实现 QoS Telemetry，但并不强制，此外 CXL Switch 也没有要求。

  对于包含多种 Memory 类型的 CXL Hierarchy 或多逻辑设备（Multi Logic Device，MLD）组件，CXL QoS Telemetry 机制是至关重要的，协议也要求在 CXL Memory 设备中必须实现该机制。

2.1 Multi-QoS

  在 Host 端，为了更好地支持多类型 Memory 混用，不同类型的 Memory 可采用多种不同的 QoS 分类，每一种 QoS 独立进行带宽等性能控制。通过这种差异化的服务质量来实现不同类型 Memory 之间的性能隔离。显然，要实现不同类型 Memory 之间的性能隔离，需要实现多个请求队列，耗费的软硬件资源较高。跟 Host 一样，在 Device 端同样可以支持多种 QoS 分类。支持多种 QoS 分类的 Memory Device 称为 Multi-QoS Device。典型的分类方法：每一种类型的 Memory 分配一类 QoS，比如 DRAM 一类，PMem 一类。

  在 Device 端，对于 MLD 而言，其可以针对各 LD 提供差异化的带宽资源分配，在 MLD 整体负载不重的情况下加大某负载较重的单 LD 的可用带宽。

---

3. QoS Telemetry 实现方式

---

  CXL Memory Device 通过在反馈给 Host 的 S2M Rsp 中添加 DevLoad 信息，来通知 Host 目前 Device 的工作负载情况。Host 通过该 DevLoad 信息来动态评判发往部分 Memory 区域、单个 Device 或一组 Memory Device 的 Req 的频率是否合适并作出优化调整，从而减少各请求在 Fabric 上的冲突，并最终实现整体性能的提升。

3.1 DevLoad

  在 S2M NDR 及 DRS 中有 2b 的 DevLoad 字段来指示 Device 当前的工作负载情况，M2S 方向的 BIRsp 中没有该字段。DevLoad 编码释义如下：

• 00b， Light Load ，负载较轻，Device Memory 目前相当清闲， Host 可以适当多发请求；
• 01b， Optimal Load ，最佳负载，不急不缓，Host 不用调整请求频率；
• 10b， Moderate Overload ，中度负载，Device 有点忙，Host 应立即减少请求频率；
• 11b， Severe Overload ，严重过载，Device 相当忙，Host 应立即大量减小请求频率。

  DevLoad 仅出现于 CXL 2.0 及之后的版本，CXL 1.1 的 S2M Rsp 中没有 DevLoad 字段，支持 QoS Telemetry 的 Host 会默认 Device 负载为 Light Load。对于 Multi-QoS 的情况，每一笔 Rsp 中携带有 LD-ID 信息，Host 根据 QoS 分类情况将其归类到不同的 QoS Throttling Group (GTP)。

3.2 Host 操作

  对于支持 CXL 的 Host，强烈建议实现 QoS Telemetry，但并不强制。

  （ 注意： CXL 协议目前未给出明确的 Host QoS Telemetry 方案，下文提到的方案，均为 CXL Spec 的建议方案。）

  Host 采用 Throttling 节流的方式对发送请求频率（或带宽）进行调控。Host 对设备负载进行监控时，并非针对每一个地址进行监控，而是在指定的 HDM 地址范围（HDM Range）进行监控。

  若 Host 支持多个 QoS 分类，不同 QoS 分类之间的 Throttling 可以依据 DevLoad 在一定范围内波动到不同的 Throttle Level，这个波动范围称为该 QoS 类型的 Host Throttling Range。Throttle 范围越大表明该区域可用的带宽上限越大。Throttle Range 并非一成不变的，Host 根据 NormalDelta、SevereDelta 参数 在一定 Limit 之内 定期进行调整 Host Throttle Range。在每一次 Throttle Range 调整期间，Host 记录该 HDM 范围内最高（而非最新）的 DevLoad，记为 LoadMax。若 LoadMax 为 Light Load，则适当减小 Throttle Range；若 LoadMax 为 Optimal Load，Throttle Range 保持不变；若 LoadMax 为 Moderate/Severe Overload，则根据 NormalDelta/SevereDelta 加大 Throttle Range。

  在调整范围上，Throttling Range 的收缩及扩大并非无限制调整，而是在一定 Limit 范围内调整。在调整时间上，Throttling Range 的定期调整间隔（tH）可以通过软件进行配置，且每一个 Throttling Range 可独立配置。协议建议把更新间隔时间 tH 稍大于发出请求到收到 Rsp 的 Round-trip 时间。为了避免 Device 过载，若 Host 收到了 Moderate/Severe Overload 类型的 DevLoad，Host 立即更新 Throttling Range 而不必等待计满 tH 时间。

3.3 Device 操作

3.3.1 QoS Telemetry 的管理

  Device 系统软件通过 SLD/MLD 中的 QoS 相关 Command 来管理 QoS Telemetry。

  对于 SLD 而言，若其支持 Command Set，必须实现 SLD QoS Telemetry 相关 SLD Commands，主要包括以下几种：

• Set SLD QoS Control，设置 QoS 控制信息。
• Get SLD QoS Control，获取 QoS 控制信息。
• Get SLD QoS Status，获取 QoS 状态。

  对于 MLD，为了便于 FM 通过 API 来访问 QoS Telemetry 相关的 Capability、控制、状态等寄存器，MLD 必须支持 QoS Telemetry 相关的命令集（Command Sets）。QoS Telemetry 相关的 Command 有以下几种：

• Get LD Info，通过该请求来获取该 LD 是否具备 QoS Telemetry Capability。
• Get QoS Control，获取 QoS 控制信息。
• Set QoS Control，设置 QoS 控制信息。
• Get QoS Status，可选，获取 QoS 状态。
• Set QoS Allocated BW，设置 QoS 分配的带宽。
• Get QoS Allocated BW，获取 QoS 分配的带宽。
• Set QoS BW Limit，设置 QoS 带宽上下限。
• Get QoS BW Limit，获取 QoS 带宽上下限。

3.3.2 Device 对其 Load 的跟踪

  对于支持 QoS Telemetry 的 Device，其需要对其内部的负载情况进行跟踪，Multi-QoS Device 不同 QoS 分类之间独立跟踪。具体跟踪方法取决于 CXL Device 的设计，协议不具体指定，常见的方法有以下三种：

• Memory Device Internal Loading （IntLoad），这种方法比较简单，通过监测请求队列（可理解为 Tx Buffer，存放待发出的 Req/Rsp/Data 等）的剩余可用深度来指示当前的工作负载情况，剩余可用深度越小表示负载越大。
• Egress Port Backpressure ，根据 Egress Port 反压情况进行 DevLoad 反馈。若 Host 无法介绍相关请求，Device Egress Port 会出现反压。
• Temporary Throughput Reduce ，特定情况下 Device 根据自身需要临时降低 Throughput。

  以上几种方法可同时启用。以 Type 3 Device 为例，上述方法中提到的相关队列在 Device 中的分布如下图所示。

  对于 SLD 而言，若 SLD 同时采用了以上三种方法且测得的 DevLoad 不同，则以测得的较大的 DevLoad 为准。

  对于 MLD，DevLoad 的评判除了要考量 SLD 中提到的三个要素，还要考量带宽等额外的因素以对不同 LD 提供差异化的 QoS。在 MLD 总体未过载的前提下，单个 LD 过载时其可使用的带宽可在一定 Limit 范围内超出预分配给该 LD 的带宽。

  MLD 总体负载及反馈的 DevLoad 如下表所示。

Additional Factors for Determining DevLoad in MLDs

TotalLoad	LD over Limit BW?	LD over Adjusted Allocated BW?	Returned DevLoad Indication
Light/Optimal Load	No	-	TotalLoad
Yes	-	Moderate Overload
Moderate Overload	No	No	Optimal Load
No	Yes	Moderate Overload
Yes	-	Moderate Overload
Severe Overload	-	No	Moderate Overload
-	Yes	Severe Overload

  更多 LD 带宽计算、带宽调整、Egress Port Congestion 测量、最近传输 Rsp 策略等相关技术细节可参考 CXL Spec。

---

4. 问题

---

• Back Invalidation Channel 中有 QoS Telemetry 吗？没有。
• M2S Rsp 中可以有 DevLoad 吗？没有，注意方向。
• 每一笔 Rsp 都有 DevLoad 吗？有必要这么密集地发吗？每笔都有，便于 Host 及时响应。
• 同一个 Flit 中多笔 Rsp 的 DevLoad 信息一致吗？不一致怎么办？可能不一致，取最严峻的情况。
• QoS 分类是怎么分的？体现在哪？取决于设计。
• MLD 各个 LD 之间的 DevLoad 是通过什么区分的？Rsp 中有 LD-ID。

---

5. 参考

---

1. CXL Base Spec, r3.0
2. CXL（计算高速链路）第 15 部分 - QoS 和 CXL.io 命令：SLD QoS 遥测 - Qiita
3. 介绍Telemetry 网络遥感技术

---

— END —

---

精选往期 CXL 协议系列文章，请查看【 CXL 专栏】

⬆️ 返回顶部 ⬆️