与 PCIe 相比,CXL为何低延迟高带宽?

2023-11-29 00:20
文章标签 延迟 pcie 相比 cxl 高带宽

本文主要是介绍与 PCIe 相比,CXL为何低延迟高带宽?,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

文章目录

  • 前言
  • 1. Latency
    • PCIE 生产者消费则模型
    • 结论
    • Flit 包
    • PCIE/CXL.io
    • CXL.cace & .mem
    • 总结
  • 2. BandWidth
    • 常见开销
    • CXL.IO Link efficiency
    • PCIe Link efficiency
    • CXL.IO bandwidth
    • CXL.mem/.cache bandwidth
  • 参考

前言

CXL 规范里没有具体描述与PCIe 相比低延时高带宽的原因,一开始我也很不理解,不过慢慢就有点轮廓了,做一个总结,尽量讲通俗一点,欢迎指正。

1. Latency

PCIE 生产者消费则模型

在开始之前,首先提一嘴 PCIE 的生产者消费者模型,因为在使用 PCIE 设备的时候,主机与设备通信,比如网卡收发数据、显卡接受数据等,进行具体的业务数据传输时,为了维护数据的准确性,必须是使用生产者消费者模型的。

请添加图片描述

如上图,右侧为主机,左侧为设备,如果主机想要获取设备某段内存的地址,除非特殊设计,将设备内存映射到BAR 空间,主机侧可直接地址访问,否则,必须是设备将要读取的内存区域的数据 copy 到 DMA 传输内存缓冲区中,然后启动 DMA 传输,通过PCIE 控制器传输数据到主机侧相应的 DMA 缓冲区,并通过中断或者 flag 通知主机,传输完成;主机收到完成信号后,会开始操作,将DMA 缓冲区的数据拷贝到应用程序缓冲区,进行下一步数据处理。

哪怕是主机读设备一个字节,也是上面这个流程,延迟的分布不仅在 PCIE 协议层,而且主要分布在最少两次的内存拷贝中。
所以,我要将延迟分两部分介绍,一部分是控制器到控制器的延迟,一部分是站在应用程序的角度,读写对端内存的延迟.

结论

后面内容太杂,所以先说结论,以免越看越乱。CXL 低延迟的实现根据上面两部分分类,一类是控制器到控制器的延迟,主要是因为采用 FLIT 模式的包,增加了少数据量的带宽,简化了硬件设计,取消了PCIE的ordering rule, access right check、DLLP等,换句话说,CXL 控制器与PCIe 控制器设计上就降低了很多 latency。第二类,站在应用层角度上看,延迟主要是因为 CXL 协议可以维护缓存一致性,所以减少了内存 copy 的操作,从而降低了整体延迟。

Flit 包

在讲 Flit 包之前,我们可以先看一下 PCIe 传输层协议包的格式,如下图

请添加图片描述

其中,红色部分为 TLP 包格式,分为 3 -4 DW 的头,0 - 1024 DW 变长的数据负载以及最后 1DW 的CRC. 其他字节为数据链路层以及物理层额外添加的开销。

不同于 TLP, CXL 采用 Flit 模式发送数据,CXL.cache / mem flie 大小固定 528bit, 有2字节的CRC以及 4 slots 的16字节块。

请添加图片描述

其中:
A “Header” Slot is defined as one that carries a “Header” of link-layer specific information
A “Generic” Slot can carry one or more request/response messages or a single 16B data chunk.
The flit can be composed of a Header Slot and 3 Generic Slots or four 16B Data Chunks.

请添加图片描述

总结一下,就是 CXL Flit 就是固定的 4块 16 字节的区域外加一个2字节CRC. 这 4 块区域每块都可以放请求响应包,也可以放数据块,头只能放在 slot0 中。

举个例子如下,设备到主机的 flit 包, 最上面 slot0 有头,也有响应包,其他的有请求包也有响应包,最后一个slot 放的16字节数据,然后最后2字节CRC.

请添加图片描述

使用 Flit 优点如下:

  1. 其携带的额外信息很多,优势就在于当你出现高速数据传输的时,携带数据的能力越强,速率越高,数据量越大,这种flit模式下的低延迟高速率的优势就会越明显;
  2. PCIe 6.0 引入了 FLIT 模式,其中数据包以固定大小的流量控制单元组织,而不是过去几代 PCIe 中的可变大小。引入 FLIT 模式的最初原因是纠错需要使用固定大小的数据包;
  3. FLIT 模式还简化了控制器级别的数据管理,从而提高了带宽效率、降低了延迟并缩小了控制器占用空间。对于固定大小的数据包,不再需要在物理层对数据包进行成帧,这为每个数据包节省了 4 字节;
  4. FLIT 编码还消除了以前 PCIe 规范中的 128B/130B 编码和 DLLP(数据链路层数据包)开销,从而显著提高了效率,尤其是对于较小的数据包。

PCIE/CXL.io

首先借鉴一下其他公司的 PPT , PCIe 设备访问主机内存的数据流如下:

请添加图片描述

PCIe 设备访问主机内存有两种情况,一种是直接内存访问,流向如上图;还有一种是站在应用程序的角度,需要内存拷贝至少两次,如前面的生产者消费者模型。他们都用不到缓存,但会都用到 IOMMU.

PCIe Latency Breakdown 如下:

请添加图片描述

PCIe 控制器到控制器为 50ns, IOMMU 根据不同的环境时间是变化的,内存控制器读写内存需要 100ns. 整体一路大概 500ns, 来回很难打破 1us. 这是站在应用层角度,有了第二次拷贝,这个 latency 算进去。实际延时应该会更长。

如下为 CXLIO 设备到主机内存的数据流向:
请添加图片描述

与 PCIe 基本相似,不同的是,CXL 控制器与 PCIe控制器还是有点差异的,多了一个 ARB/MUX 动态多路复用器件。软件层面,可以与 PCIe 复用。

CXL.io 的性能如下:

请添加图片描述

IO 的吞吐量比 PCIe 还要差 6%, 因为CXL.io 协议就是封装了PCIe 的TLP, 在前面加了2字节 Protocol ID 以及后面增加了 2字节的 reserved bytes。增加了的 ARB/MUX 器件也会消耗 2 - 4 ns。

如下图, CXL Flit 包的在 X8 的分布,每条 Lane 发送一个字节, 第一部分的橙色部分为封装的 PCIe 的包,黄色部分为添加的 2 字节 Protocol ID, 最后有 2字节的 reserved bytes:

请添加图片描述

CXL.cace & .mem

下图为 CXL.cache 设备访问主机内存的数据流向:

请添加图片描述

.cache 协议可以让设备像访问本地内存一样访问主机内存,设备CPU与主机 CPU 可以共同访问同一个地址的数据,缓存一致性由主机侧的 Cache Home Agent 来维护。根据 MESI 协议,看情况是否去访问实际内存。
.mem 则相反方向,让主机使用缓存访问设备内存,就像访问本地 DDR 内存一样。

下图为 .cache 与 .mem 的好处:

请添加图片描述

  1. 主机和设备相互访问对方内存,可以直接使用内存语义, load/store,不用再使用生产者消费者模型,使用中断或者 flag 通知对方,也不用多次拷贝了;
  2. 设备侧可以同样使用主机页表,那样,主机进程和设备就可以访问同一块虚拟地址空间了;

下图为 CXL microarchitecture with CXL.$Mem measured latency.
请添加图片描述

intel 控制器比标准PCIe PHY 做了如下延迟优化:

  1. bypassing the 128-/130-byte encoding
  2. bypassing the logic and serializing flops needed to support
  3. bypassing the deskew buffer if the lane to lane skew is less than half the internal PHY logical clock period
  4. adopting a predictive policy of processing entries from the elastic buffer (versus waiting for the clock domain synchronization handshake for every entry)

最终, PHY 到 PHY 之间有一个 15 - 19 ns 的延迟,其中4ns 的差异是由参考时钟决定的,depending on whether a common reference clock or independent reference clocks are deployed. 与前面 PCIe 的50 ns 对比,是有时间节省的,不过实际情况,根据不同的IP, 可能会有更大的差距。
这里需要注意的一点是,最底层的模拟 PHY,PCIe 与 CXL 使用的是同一个,这个意味着对于RC与EP的模拟phy 到模拟 phy,相同的数据量,时间是一样的。

More Latency Savings with CXL.mem /.cache
在这里插入图片描述
及其他:

  1. The link layer and transaction layer paths have a low latency since they are natively flit based.
    This eliminates the higher latency in the PCIe/ CXL.io path due to the support for variable packet size, ordering rules, access rights checks, etc. saving latency due to simplified controller design.
  2. Break out of the PCIe ordering model
    Latency saving through out-of-order transfers, write completions
  3. ARB/MUX:
    CXL.Cache/Mem protocol muxing at the PHY level (versus higher level of the stack) helps deliver a low latency path for CXL.$Mem traffic.
  4. Coherence Bias
    Latency savings with optimized snoop traffic in Device Bias mode

其他的介绍开销的地方,前两个由于使用 FLIT 模式传输,PCIe 协议包耗时的逻辑取消了;第 3 点是硬件期间 ARB/MUX 为协议选择低延迟路径,还是硬件控制器IP 加速了;最后一条是 CXL 协议的功能,设备偏置,有利于加速设备访问主机内存。

下图为 CXL.cache/mem 延迟分布

请添加图片描述

CPU 访问内存以及 Cache 一致性操作;CXL 协议层消耗 25 ns; 设备侧应用层延迟以及内存访问延迟;

下图是一个 Type2 设备读主机内存的时间估计:

请添加图片描述
请求响应包一个来回共 25 + 25 = 50ns, 主机访问内存消耗 100ns 左右,整体 150ns 左右,外加设备侧应用消耗;

下图为写:
请添加图片描述
请求与响应一个来回,写操作再携带数据发送一遍,25 + 25 + 25 = 75 ns, 主机侧写内存消耗 100ns 左右,总计 175ns左右。

其他影响延迟的因素:

请添加图片描述
多处理器环境,以及 snoop 的响应的缓存一致性管理增加延迟,IOMMU 中的虚拟地址到物理地址的转换等也会有影响,不过这是 PCIe 与 CXL 共同面临的问题。

如下是 RAMBUS 公司设计的 CXL Controller IP

请添加图片描述
控制器与上层接口也使用了 Intel 低延迟的 CPI 接口,控制器也使用了其他技术减少延迟。

总结

由上总结,CXL 比 PCIe 延迟低的原因如下:

  1. 与PCIe相比,CXL Flit 模式简化控制器设计,控制器其他硬件设计降低延迟, 最少 50 ns-> 25ns;
  2. Flit 模式增加了少数据量的带宽;
  3. CXL 协议包降低了数据处理逻辑,取消了排序规则以及DLLP等,节省开销;
  4. CXL 协议功能取消了内存拷贝,节省开销等;

2. BandWidth

这里的带宽是指每秒传输的有效数据,有效数据即读写的数据。前提,X16 Gen5 在速率 32 GT/s 下原始带宽每个方向 64 GB/s = 32 GT / s * 16 / 8bit。

常见开销

在 68-byte flit 模式下,三种常见开销:

  1. 128/130 = 0.9846 represents the sync HDR overhead (which can be reclaimed when sync HDR bypass is supported)
    这里不是 128/130 编码, 是 Flit 每条Lane上的 2bit的 Sync Header,01代表128bit前插入 Order set block, 10 表示该 block 为 data block
    支持 Sync HDR bypass 的时候此开销可以取消

  2. 374/375 = 0.9973 represents the bandwidth loss due to SKP ordered sets for common clock (higher for other mode)
    SKP : 最多 375 字符插入 SKP 方式,达到补偿时钟偏差的目的, PCIe 与 CXL 都有的开销

  3. 64/68 = 0.9412 representing the flit overhead (2 bytes each for protocol ID and flit CRC).
    CXL Flit 模式特有的,前面 2字节 Protocol ID, 后面 2 字节 CRC

FLit 包格式如下图,CRC 画错了,PROTID 与 CRC 之间应该是 4 个 slot 共 64字节:

请添加图片描述
下图也是 68B Flit 包:
在这里插入图片描述

由上知链路效率:
使用 HDR Flit 包: 0.9846 * 0.9973 * 0.9412 = 0.9242
关闭 HDR Flit 包: 0.9973 * 0.9412 = 0.9387

CXL.IO Link efficiency

68-byte flit 模式下, 假设DLLP 包损耗 2%, .IO 链路层效率为:
使用 Sync HDR : 0.9242 * (1 - 0.02) = 0.9055
关闭 Sync HDR : 0.9387 * (1 - 0.02) = 0.9199

PCIe Link efficiency

PCIe 不适用 flit 模式,所以第三个开销没有,另外两个开销: 0.9846 * 0.9973 = 0.9819,此外还有 2%的 DLLP 开销,所以总开销为:

0.982 * (1 - 0.02) = 0.9624.

与 CXL.io 相比,PCIe 链路层效率还上升了 6%,主要在 Protocol ID 与 CRC 上。

CXL.IO bandwidth

计算带宽一般是 100% 读,100%写,50%读50%写三种情况,这里就不一一分析了。只分析个简单的 100% 读。

设 D 为数据负载,单位 DW 双字, 1 DW = 4 字节。
IO 里面封装的 TLP 包, TLP 包头是 3-DW for completions and 4-DW for requests (read/write).
An additional overhead of 2-DWs for framing and CRC is incurred per TLP with 68-byte flit (FT_CRC = 2),这里可能是计算的 CXL3.0 256B Flit 的开销。

带宽计算方式如下:

请添加图片描述

所以 1R0W 的结果为: 0.9199 /6 * 64GB /s = 9.812GB /s, 其他同理。

CXL.IO Bandwidth 结果如下:

请添加图片描述

PCIe 与 CXL.IO 差不多,从结果看,少量数据效率低,大量数据效率高,所以,对于大数据量来说, CXL 与 PCIe 相比提高不大,不过对于小数据量的读写访问,比如 8个字节来说,优势则巨大。

CXL.mem/.cache bandwidth

主机读 Type 2 设备内存流程如下图:
请添加图片描述

主机读 Type 3 设备内存流程如下图:
请添加图片描述

主机读设备,都是发送一个读请求,只不过对于 Type2 设备,会附加缓存状态信息Snoop SnpData, Type2 设备会返回 S2M DRS + NDR, Type3 设备会只返回 S2M DRS,这是 Type2 与 Type3 的重要区别,此条信息值一万。
S2M DRS 是响应数据包,NDR 是无数据响应,用来指示主机缓存状态的,此外都要外加一个缓存行大小的数据 64 字节。

同样,以 1R0W 为例计算带宽,x reads, y writes, 以 slot 为单位,有效数据占 4 slot.

在看下图 S2M DRS + S2M NDR Flit 包

请添加图片描述

0 - 3 字节为头,4 - 8 字节为 S2M DRS, 9 - 12 字节为 S2M NDR.

所以对于 Type3 来说,S2M DRS 占半个 Slot.
由上可计算得到 S2M 使用的最大 slots 为 (x + y) / 2 + 4x, 有效数据占 4x
则最终 bandwidth 为 LinkEfficiency * 4x / ((x + y) / 2 + 4x) = 0.9387 * 4 / (1/2 + 4) = 0.8344, 0.8344 * 64GB/s = 53.4 GB / s

其他 cache 与 mem bandwidth 计算公式如下图:

请添加图片描述

结果如下:

请添加图片描述

因为PCIe 的有效数据负载是可变的,所以 1DW - 1024 DW 效率随着负载的增多在不断增大,CXL 读写操作的字节长度是 64 字节,读128字节的数据就是发送两个 S2M DRS 包,所以一个方向的带宽是不变的。

打完收工!

参考

  1. 《Compute Express Link (CXL) Specification Revision 3.0》
  2. 《An Introduction to the Compute Express LinkTM (CXLTM) Interconnect》
  3. 《Compute Express Link (CXL): Enabling Heterogeneous Data-Centric Computing With Heterogeneous Memory Hierarchy》
  4. RAMBUS Company PPT

这篇关于与 PCIe 相比,CXL为何低延迟高带宽?的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/430765

相关文章

如何编写Linux PCIe设备驱动器 之二

如何编写Linux PCIe设备驱动器 之二 功能(capability)集功能(capability)APIs通过pci_bus_read_config完成功能存取功能APIs参数pos常量值PCI功能结构 PCI功能IDMSI功能电源功率管理功能 功能(capability)集 功能(capability)APIs int pcie_capability_read_wo

ActiveMQ—消息特性(延迟和定时消息投递)

ActiveMQ消息特性:延迟和定时消息投递(Delay and Schedule Message Delivery) 转自:http://blog.csdn.net/kimmking/article/details/8443872 有时候我们不希望消息马上被broker投递出去,而是想要消息60秒以后发给消费者,或者我们想让消息没隔一定时间投递一次,一共投递指定的次数。。。 类似

MySQL主从同步延迟原理及解决方案

概述 MySQL的主从同步是一个很成熟的架构,优点为: ①在从服务器可以执行查询工作(即我们常说的读功能),降低主服务器压力; ②在从主服务器进行备份,避免备份期间影响主服务器服务; ③当主服务器出现问题时,可以切换到从服务器。 相信大家对于这些好处已经非常了解了,在项目的部署中也采用这种方案。但是MySQL的主从同步一直有从库延迟的问题,那么为什么会有这种问题。这种问题如何解决呢? MyS

全倒装COB超微小间距LED显示屏的工艺技术,相比SMD小间距有何优势

全倒装COB(Chip On Board)超微小间距LED显示屏,在工艺技术上的革新,相较于传统的SMD(Surface Mount Device)小间距LED显示屏,展现出了多方面的显著优势。 首先,全倒装技术极大地提升了LED芯片的散热性能。通过将芯片直接焊接在基板上,减少了热阻,使得热量能够更快速地传导至基板并散发出去,有效避免了因高温导致的光衰和色彩偏移问题,从而保证了显示屏的长期稳定性

软文发稿相比其他广告形式有哪些持续性优势?

软文发稿在品牌宣发中具有显著的持续性优势,特别是在与其他广告形式的比较中更能体现这些特点。凭借其潜移默化的影响力、增强品牌权威性和公信力、持续性的曝光优势、精准触达目标受众的能力、强互动性与引导性,以及较高的性价比,已经成为品牌推广不可或缺的手段 一 长期存在与持续曝光 长时间的内容可见性     软文发表后,通常会长时间存在于各种平台上,无论是官网、博客、行业网站还是社交媒体帖子。读

Flink全链路延迟的测量方式和实现原理

点击上方蓝色字体,选择“设为星标” 回复”面试“获取更多惊喜 本文已经加入「大数据成神之路PDF版」中提供下载。你可以关注公众号,后台回复:「PDF」 即可获取。 一、背景 Flink Job端到端延迟是一个重要的指标,用来衡量Flink任务的整体性能和响应延迟(大部分流式应用,要求低延迟特性)。 通过流处理引擎竞品对比,我们发现大部分流计算引擎产品,都在告警监控页面,集成了全链路时延指标

dispatch_after 的延迟执行分析

dispcth_after 是将block 中的任务延迟添加到它将要执行的队列中去,而并不一定添加到队列中就立即会去执行任务。 图中表示是在5秒中后将任务添加到主队列中,如果主队列中还有另外的任务假设A、B 要执行,那么这个任务会在任务A、B 执行完后才会开始执行。 验证的代码如下: dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int

SpringBoot教程(十五) | SpringBoot集成RabbitMq(死信队列、延迟队列)

SpringBoot教程(十五) | SpringBoot集成RabbitMq(死信队列、延迟队列) (一)死信队列使用场景具体用法前提示例: (二)延迟队列使用场景方法一:通过死亡队列实现方法二:通过延迟消息插件(rabbitmq_delayed_message_exchange)实现 (一)死信队列 死信队列是一个重要的概念,用于处理那些因各种原因无法被正常消费的消息。 它

学习记录-Qt按键单击后延迟一段时间触发下一个函数执行

<span style="font-family: Arial, Helvetica, sans-serif;">QTimer::singleShot(1000, this, SLOT(on_pushButton_pcba_readfilename_clicked()));</span>项目中,需要按键单击后发送一条指令,等待一段时间后在发另一条指令,看文档发现使用如上方式可以实现

JavaScript 实现网页菜单延迟加载效果》

目录 一、整体代码结构 二、代码注解 1. HTML 结构部分 2. CSS 样式部分 3. JavaScript 部分 一、整体代码结构 <!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><meta name="viewport" content="width=device-width, initial