✨ 4. LN Message

4.1 什么时候发送LN Message?

 LNC在以下两种情况时必须发送LN Message给LNR：

•        CPU或Device更新了主存中已登记的Cacheline；

•        LNC不打算继续追踪该Cacheline的状态了。这种情况称为注销，通过LN Message中的Notification Reason（NR）字段指示该情况。

4.2 LN Message格式

 LN协议采用PCI-SIG定义的VDM（Vender-Defined-Mechanism）机制，LN Message是一种带有2DW数据载荷的Type 1类型的VDM消息，其帧格式如图3所示。

图3 LN Message

 LN Message的数据载荷为64bit的Cacheline地址，该地址为已更新或注销的Cacheline地址，该64bit地址适用于32bit地址及64bit地址。

 LN Message的TLP Type为MsgD，Fmt为011b，Type为10***b（010->Directed，011->Broadcast），TC[2:0]为000b，Length为2，Attr[2:0]为**0b，LN为0（是0，只有LN Read、LN Write及LN Completion的LN才为1，LN Message中该字段不用特别标记，LNR照单收下并更新本地Cache就是了），Message Code为01111111b，Vender ID为0001h，Subtype字段为00h。NR字段用以指示发出该通知消息的原因，NR字段描述如表1所示。地址位[5:0]忽略，若CLS为128B，地址的第6bit应置零，LNR收到LN Message后也应忽略该位。

 LN Message的Destination ID由方式决定，LN Message可以采用特定的ID进行基于ID的定向路由，也可以针对某一RP下的设备进行广播。

表1 NR字段描述

⚠️注意：LN Message 的接收者可有选择性地对消息各字段有效性进行检查确认，若检查不通过则当作畸形包处理。

4.3 正确使用Broadcast LN Message

 每一次Broadcast LN Message都会消耗链路带宽，且部分EP处理广播LN Message的速率很低。鉴于以上情况，为避免影响系统性能，LNC在广播LN Message的时候应该把要广播的Hierarchy Domain数目精确到最小，并把广播频率控制在允许的范围之内。

 对于不支持LNR能力的EP而言，其收到LN Message后会将其视为异常情况并采用性能比较低的机制来处理。比如，利用设备Firmware来处理该Message，而非采用硬件处理，每次都要消耗ms级的处理时间。可想而知，若过度使用广播LN Message，势必会使成该Fabric上的转发请求形成反压，从而影响系统性能。

 对于不支持LNR能力的EP，如果采用Directed LN Message，该Message之后被送到某个指定EP，虽然该EP也会消耗数ms来处理该异常情况，但并不会对系统整体性能由特别大的影响。当然，LNC理应只把Directed LN Message发送支持LN协议的EP，发送频率也应维持在合理的范围内，以避免影响性能。

✨ 5. LN配置

5.1 LNR扩展能力结构

 具备LN能力的LNR需实现LNR扩展能力结构（图4），该能力结构只能在EP中实现。LNR能力结构如图所示，主要包括LNR扩展能力头标、LNR控制寄存器及LNR能力寄存器3部分。

图4 LN Requester Extended Capability

 LN Requester Extended Capability（图5），LNR扩展能力头标，用以指示当前EP具备LNR能力、LNR能力版本，并指向下一扩展能力的偏移。

 LNR Capability Register（图6），LNR能力寄存器。LNR-64/128 Supported字段用以指示该LNR支持的Cacheline size（CLS）；LNR registration max字段用以指示该LNR支持的最多可以请求登记的Cacheline数目，值n表示该LNR最多可以登记25条Cacheline。

 LNR Control Register（图7），LNR控制寄存器。LNR enable字段用开启或关闭该EP的LNR能力；LNR CLS字段用以选择LNR采用的CLS，0->64B，1->128B；LNR registration limit字段用以指示该LNR允许的最多登记的Cacheline数目（可能未达能力上限，但软件配置只允许这么多），值n表示该LNR最多允许登记25条Cacheline。

图5 LNR Extended Capability Header  

图6 LNR Capability Register

图7 LNR Control Register  

5.2 LN软件配置

 LN协议支持两种CLS：64B和128B，这两种CLS对RC和EP都是可选的。系统CLS由主机LN系统RP和RCRB的CLS字段决定。所有支持LNC的RP和RCRB中CLS字段值必须相同，否则大家各执一词，软件听谁的？系统允许过程中软件不能更改CLS的值，否则结果难以预计。

 支持LN协议的EP必须支持一种或两种CLS，并通过LNR-64 Supported及LNR-128 Supported字段来指示其支持的CLS。LN系统中所有LNR被启用之后，软件必须确保相关LNR的CLS控制位跟系统CLS相匹配，否则结果难料。如果LNR只支持一种CLS，其CLS控制位可以硬链接，当值被软件篡改。

 LNR使能期间软件不能改变LNR CLS控制位即LNR登记上限的值，否则结果难料。若LNR未使能，LNR的CLS控制位及LNR登记上限可以跟LNR使能位同时进行配置，即通过一次配置写完成。

 软件可以随时关闭LNR，关闭LNR之后应及时清除其内部相关Cache状态。

图8 Device Capabilities 2 Register

✨ 6. PCIe 6.0后时代下的LN

6.1 为何又要移除LN？

 至于为何要删除LN，咱不知道官方理由是啥。作为事后诸葛亮的我，个人感觉LN存在的意义不大，主要有以下几点原因：

   时延大，难以保证Cache一致性。LNC发送LN Message给LNR告知Cacheline有更新，对于Directed Routing的方式时延已经够大，Broadcast Routing的ms级别时延更是骇人，在LN Message到达LNR之前这段时间EP仍然在采用其本地陈旧的Cacheline数据。再等LNR重新走PCIe链路访问去主存读Cacheline、LNC返回读请求完成，中间又要消耗很多时间。这样一来，很难做到Cache一致性。

   CXL有替代方案。PCIe 5.0之前TLP、DLLP、ACK/NAK机制等，使得PCIe天然不适合访问Cache。加之CXL在PCIe之上做到了主机Mem和Cache访问，LN的处境更为尴尬。

   用不好会影响性能。想要利用好LN，需要软件和硬件多做不少工作，一旦控制不好还会有一堆性能问题。

   PCIe 6.0 FLIT机制或许允许直接Cache访问。在PCIe 6.0中，引入了FLIT编码，改进了原有的TLP、DLLP、ACK/NAK机制，使得PCIe EP访问主机的时延大大减小。或许（没仔细研究过，仅是猜测），在一定程度上能够实现PCIe的直接Cache访问。

6.2 移除之后，还兼容既有的支持LN的设备吗？

 PCIe 4.0和PCIe 5.0软硬件系统是支持LN的，但PCIe 6.0把LN协议移除了。至于PCIe 6.0的系统是否兼容老旧的支持LN的软硬件，现在还不敢说，毕竟PCIe 6.0正式版还没出来。不过从PCIe 6.0的0.9版本看，已经把LN相关内容全删掉了，相关控制位也reserved了。看样子是不支持了哦。上文也提到了，LN想要用起来用得好，也是比较难。

 据我了解啊，市面上真正把LN用起来的，少之又少。如果这LN协议没有想象中的好，那么让其消失在PCIe历史发展的滚滚长河中又何妨？

📚 参考

   PCI Express Base Specification Revision 5.0 Version 1.0 (22 May 2019)

   新版PCIe 4.0规范新特性简介

   Lightweight Notification