清晰展示一个简易CPU内部的处理流程

PCIe设备与CPU交互的流量有2种：控制流量，访存流量。其中控制流量又分为多种：配置信息读写，电源管理，中断传送等等。访存流量则是PCIe设备与Host交互的主要通道，Host通过访问PCIe设备内部的存储器来获取或者更改信息，或者传送数据，PCIe设备也会通过访问Host端的主存来获取或者更改信息。

通常来讲，如果有数据要被传送给PCIe设备，Host端程序预先将数据准备在主存中，PCIe设备主动通过PCIe通道读取主存；PCIe如果有数据要传送给Host，也需要Host端程序预先在主存中准备好缓冲区，PCIe设备主动将数据写入到该缓冲区。PCIe设备处于主动，Host端处于被动。为什么不让Host主动把数据推送到设备呢？原因有2个，一个是会增加Host端的管理压力，需要维护状态机，而是由于设备内部状态对外界不可知，Host主动推送数据，一旦设备内部并没有做好接收准备，各种阻塞就会出现，Host可没空再去管这些底层的破事儿的。

一般来讲，Host端程序（通常为PCIe设备的驱动程序）会预先在Host端主存中准备好收/发两个队列，并将队列的指针（队列位于主存中的地址）写入到PCIe设备内部某存储器/寄存器中，这个写入指针的过程也是访存操作，访问PCIe设备上的存储器。然后双方通过向队列中写入信息的方式来通告各自需要完成的任务，比如向队列中插入一条任务：”PCIe设备，请到主存中xx地址取数据和I/O指令“，或者”Host，我已完成xx号任务，处理完的数据已经写入xx地址“。

如果上面这段你看的云里雾里，那么证明你应该赶紧先去当当买一套《大话计算机》了，第8章详细讲解了PCIe原理以及设备与Host交互步骤分步详解。扫码直接购买：

仔细的读者可能已经注意到，除了将一些控制信息比如队列指针等写入PCIe存储器之外，好像Host很少主动写PCIe设备存储器？是的。主要原因就是：  Host主动把大量数据移动到设备的存储器，太慢。Host端程序可以使用Load/Stor指令直接访问PCIe设备端的存储器，向其中写入或者从中读出数据。这个过程会耗费CPU周期，如果需要移动的数据量非常庞大，CPU核心会被耗死。所以，需要采用DMA（Direct Memory Access）的方式后台异步进行，也就是采用独立于Host CPU之外的执行单元来负责，这个执行单元叫做DMA Controller，几乎所有的主流PCIe设备都会在自己的主控芯片内继承DMA Controller。Host CPU为何不集成？两个原因，之前说了，PCIe设备处于主动角色，所以DMA控制器放在自己这里是最佳方案。再就是CPU内部集成DMA控制器，选用什么样的规格不好界定，有些需要高并发DMA，有些则完全不需要太高的性能，所以还是设备自主集成比较好。所以，移动数据的任务就交给设备自身了。

既然数据可以放到Host端主存中，那么为何PCIe设备非要把数据拿到自己存储器里再处理呢？这得看是什么类型的设备，比如SAS HBA，它原本就是要把主存中的数据写入到硬盘，它的作用并不是数据处理，而是把数据在不同总线/协议通道上传送，同样的还有网卡。

而对于一些数据处理类设备，比如GPU/FPGA等等，又分为两种情况，第一种情况是需要处理的数据量较大，迭代次数较高，频繁访存，典型的比如AI训练，图形渲染。此时如果让设备每次访存都访问主存，就会非常慢，因为访问本地存储器可以走DDR4/5接口甚至本地缓存，访问Host端主存则走PCIe通道，前者带宽50GB/s，延迟大概50ns，而后者则只有16GB/s（PCIe 3.0），延迟200ns+，这势必会大大降低性能，所以将数据批量拷贝到设备内部存储器，本地处理，才是正路。而另一种情况是，需要处理的数据量并不是很大，而且访存频率较低，此时每次访问先拷贝回来再处理就本末倒置了，此时，最好是直接访问主存。明白了上述过程，背景，原理，我们再往下走。

此时问题来了，对于这些可以直接访问主存的场景，是否可以加把劲在加速一下？访存加速，最好的办法就是使用缓存。如果能够在设备端设置一个缓存来存储经常访问的Host端主存的数据，就可以了，由于缓存一般使用SRAM介质，比SDRAM介质快十倍甚至几十倍，所以加速效果非常明显。

那么问题又来了。缓存会产生缓存一致性问题（详见《大话计算机》第6章），比如CPU和GPU如果缓存了同样的数据，CPU对数据的更改，GPU是不知道的，会产生错乱的计算结果。所以，必须在设备与Host之间，实现缓存一致性管理协议，比如MESIF/MESI/MOESI等模型（详见《大话计算机》第6章）。所以，势必要在设备端加入缓存一致性管理模块，按照Intel CPU平台为准，也即是ccAgent，由于设备端也有大容量存储，所以需要一个Home Agent。（这些Agent详细机制详见《大话计算机》第6章）。

出自《大话计算机》第6章

那么问题又来了，这些Agent势必会增加设备端的复杂度和开发量。没办法。但是可以把管理设备内部存储器缓存一致性的Home Agent移动到Host端，也就是移动到CPU里，这样外设只需要实现一个ccAgent即可。

现在，设备可以不用把数据先从Host主存拷贝到本地，就可以直接访问主存处理数据了，现用现访问。那么，礼尚往来，设备端是不是也可以把自己更广阔的内部存储器空间开放给Host端直接处理？当然可以，但是由于Home Agent在Host端，那么此时设备即便是访问自己内部的存储器，也需要发送一些控制消息到Home Agent用来实现缓存一致性，此时有点本末倒置了。解决办法，可以对这块存储器中的区域（按照Page位单位）左标记，“xx Page在主存中不被缓存，设备可以肆无忌惮的本地读写而不用发送控制信息到Home Agent”，或者 “xx page在主存中有缓存，设备要么先别访问，要么就发送控制信息通告给Home Agent”。

那么，CXL是什么？CXL就是你把上述过程通透的理解之后，基于现有体系产生的方案，协议。记住，CXL仅对 “直接访问Host主存处理数据，或者Host直接访问设备存储器处理数据” 模式的场景有提速作用，对于原本就必须进行数据拷贝之后本地处理的场景，基本无效。篇幅所限，就不具体介绍CXL的各种概念了，比如：Type1/2/3 Device，Bais，CXL.io，CXL.mem，CLX.cache，等等，只要上面的你懂了，这些概念并不是问题。

CXL2.0版本协议引入了CXL Switch，能够将CXL协议网络化实现。与此同时，格局更宏大的Gen-Z协议也在同时发展，目前看来Gen-Z更注重大规模组网，而CXL注重小规模局部组网，二者目前业界认为是相辅相成的关系。但是后续就不知道了。

其实，早在5年前，本公众号第一篇文章，介绍的就是CXL的老前辈，由IBM定义的CAPI加速协议，CXL实际上是CAPI的跟随者，毕竟x86生态吊打Power平台。CAPI目前已经过渡到了OpenCAPI，大家有兴趣可以自行了解。不得不说，IBM还是瘦死骆驼比马大，IBM对硬件基本上差不多玩够了，现在除了大型机等镇界之宝，开放的平台都卖了，或者深度合作，离着彻底脱手也不远了，就看业界小喽啰们能否继承好IBM的衣钵并将其发扬光大。

这篇文章的写法与《大话计算机》一样，都是从源头讲起，遇到问题，思考问题，解决问题，引出结论，最终再介绍抽象概念。而并非网络上千篇一律的 “CXL是Intel定义的一套外设与Host之间的加速访问协议，xxxxx”，保你看完了等于没看，而且还浪费了时间，文中不仅一点其他线索也没有，你根本没法深究下去，而且前因后果，场景，一概不跟你说，懂的原本就懂，不懂的还是不懂。《大话计算机》打破了这一恶性循环，让你的学习时间数倍的降低。当然， 本文如果你看不懂，也是意料之中，原因很简单，因为你没看《大话计算机》，没有吃第一个第二个面包，又怎么可能直接吃第三个面包？哈哈。要在一篇小文中通俗易懂的讲清楚PCIe，CXL的详细机制，不太可能，所以还是推荐大家阅读《大话计算机》，你想要的，里面不说100%，90%都是有的。

年龄最小的《大话计算机》读者（15岁）

扫码入当当直购《大话计算机》

展阅读展

扩展阅读

连书都得看国外写的才能做好芯片？这儿有人不服！

《大话计算机》同款T恤，我要了！！

《大话计算机》动图一则展示

《大话计算机》序言① by廖恒

《大话计算机》序言② by 包云岗老师

《大话计算机》序言③ by 何万青

《大话计算机》序言④ by 雷迎春

《大话计算机》序言⑤ by 汪利文

《大话计算机》序言⑥ by 张勇

《大话计算机》序言⑦ by @去流浪

博主简介：冬瓜哥，《大话计算机》与《大话存储 终极版》、《大话存储 后传》图书作者。多项专利发明人。

现任某半导体公司高级资深架构师。

大话计算机   大话存储

长按扫码可关注