花开花落花归尘——缅怀被PCIe 6.0拿掉的LN（Lightweight Notification）协议"/>
【PCIe 6.0】缘起缘灭缘终尽，花开花落花归尘——缅怀被PCIe 6.0拿掉的LN（Lightweight Notification）协议
🔥点击查看精选 PCIe 系列文章🔥
📢 声明：
- 🥭 作者主页：【MangoPapa的CSDN主页】。
- ⚠️ 本文首发于CSDN，转载或引用请注明出处【点击查看原文】。
- ⚠️ 本文为非盈利性质，目的为 个人学习记录 及 知识分享。因个人能力受限，存在协议解读不正确的可能。若您参考本文进行产品设计或进行其他事项并造成了不良后果，本人不承担相关法律责任。
- ⚠️ 若本文所采用图片或相关引用侵犯了您的合法权益，请联系我进行删除。
- 😄 欢迎大家指出文章错误，欢迎同行与我交流 ~
- 📧 邮箱：mangopapa@yeah
文章目录
- ✨ 1. 初识LN
- ✨ 2. 当初为啥要加入LN?
- ✨ 3. LN协议深度剖析
- 3.1 支持LN协议的PCIe系统结构
- 3.2 LN协议基本操作
- 3.2.1 LN Read
- 3.2.2 LN Write
- 3.3 LN协议规则
- 3.3.1 LN基本规则
- 3.3.2 LN登记管理
- 3.3.3 LN 事务排序
- 3.4 LN协议总结
- ✨ 4. LN Message
- 4.1 什么时候发送LN Message?
- 4.2 LN Message格式
- 4.3 正确使用Broadcast LN Message
- ✨ 5. LN配置
- 5.1 LNR扩展能力结构
- 5.2 LN软件配置
- ✨ 6. PCIe 6.0后时代下的LN
- 6.1 为何又要移除LN？
- 6.2 移除之后，还兼容既有的支持LN的设备吗？
- 📚 参考
| |
✨ 1. 初识LN
Lightweight Notification（LN），顾名思义，轻量级通知。PCIe 4.0时正式引入，并在PCIe 6.0中被移除。LN协议允许EP登记主存中的Cacheline，利用EP端的Cache来降低系统带宽需求并降低时延。所谓登记Cacheline是指 ① EP把主存指定位置的Cacheline的内容copy一份放到EP本地，② 主机记录其主存某Cacheline被某EP关注了。若主机或其他设备更新了主存中被登记的Cacheline，硬件会通知该EP其关注的这条Cacheline已被更新，EP请停止使用你本地的Cacheline备份，再用的话麻烦再次申请登记。
| |
✨ 2. 当初为啥要加入LN?
LN是一种能够满足几类关键应用模型的简单协议，其复杂度最小，成本最低。LN有其优点，所以PCI-SIG才考虑把LN写入到PCIe规范中。
PCIe系统中采用LN协议有以下潜在优点：
- 减小I/O带宽及时延。对于一些EP经常访问的主机内存地址，EP可以把对应地址的Cacheline缓存到EP本地，这样每次直接到本地Cacheline去取即可，而不用每次都同PCIe链路去读取主机内存，从而减小PCIe系统的带宽需求，也能够降低访问时延。
- 轻量级信令。采用LN协议的主机软件只在Cacheline发生变动时才给EP发送Cacheline更新的消息，而非发送可编程IO(PIO)操作，减少了软件开销，也避免了复杂的同步及流控问题。
- 动态设备相关。虚拟机驱动通过主内存结构与设备间的通信（无PIO）使客户迁移及虚拟机主机在VIO-Direct IO间动态切换更为简便。
| |
✨ 3. LN协议深度剖析
3.1 支持LN协议的PCIe系统结构
LN协议中有两个较为关键的组件：LN Requester (LNR) 及 LN Completer (LNC)。LNR是EP中发送LN读写请求及接收LN Message的客户子系统，LNC是主机端接收LN读写请求及发送LN Message的服务子系统。
典型的支持LN协议的系统包括以下几部分：主处理器、主存、主机Fabric、RP、Switch及EP。下图是一个LN系统示意图（图1），其中EP X、EP Z及RCIEP 0各有一个LNR，RC为LNC。
3.2 LN协议基本操作
LN协议包括两种基本操作：LN Read 和 LN Write。LN Read和LN Write可以理解为EP读写主存，同时把主存该Cacheline对应的数据在EP端留个备份。LN Read是一种存储器读请求，LN Write是一种存储器写请求，LN Completion是一种Completion消息，跟其常规TLP的唯一不同是其TLP头标中的LN位为1。
LN协议允许多个LNR同时登记同一条Cacheline，单个LNR的LN协议操作示意图如下图所示（图2），左侧为LN Read，右侧为LN Write。
3.2.1 LN Read
LN Read基本操作步骤如下：
1️⃣ LNR发送LN Read给LNC，请求登记一条主存Cacheline。
2️⃣ LNC回复该Cacheline的LN Completion给该LNR，并记录该LNR登记了该Cacheline。LNR所在的EP会把LN Completion所携带的Cacheline数据存储在本地Cache。
3️⃣ 若该Cacheline有更新或Cacheline注销，LNC发送LN Message给LNR。
3.2.2 LN Write
LN Write基本操作步骤如下：
1️⃣ LNR发送LN Write给LNC，请求写主存的Cacheline。
2️⃣ LNC记录该LNR登记了该Cacheline（LNC收到LN Write不回LN Completion）。
3️⃣ 若该Cacheline有更新或Cacheline注销，则发送LN Message给LNR。
⚠️注意：带有LNR的EP任何时候都可以发生LN Write，而不用关心其他LNR有没有登记该Cacheline。
3.3 LN协议规则
3.3.1 LN基本规则
LN协议遵循以下规则：
- LN协议允许多个LNR同时登记相同的Cacheline。当该Cacheline发生变化时，LNC可以选择给各个受影响的LNR单独发送LN Message，也可以选择给受到影响的LNR所在的PCIe Hierarchy Domain发送广播LN Message。
- 若LNR在登记了某Cacheline之后再次发送针对该Cacheline的LN读写请求，当LNC回复LN Message时，LNR并不知道该LN Message是针对当前LN请求还是针对早前的LN读写请求。
- LNC在发送完LN Message之后，除非LNR再次发送了LN读写请求，否则LNC不会再次发送LN Message。也就是说，一次LN请求仅对应一次通知。
- 单条LN Message可用于指示某LNR所有已登记Cacheline全被注销，用LN Message种的Notification Reason（NR）字段来指示。这种Message可以采用Directed或Broadcast的路由方式进行发送。
- LNC可以设置一个上限，规定某条Cacheline最多可以被多少LNR登记。若登记该Cacheline的LNR数目在上限范围内，由于数量不多，LNC通常发送Directed LN Message；一旦超出上限，LNC发送Broadcast LN Message。当然把这个上限设置为0是允许的，这样每次回复LN Message都采用广播的形式。
- LNC可以规定其可以登记的Cacheline数目上限，若LNC收到了Cacheline的登记申请，但该LNC没有精力同时跟踪这么多Cacheline，那么该LNC可以注销一些比较老的Cacheline登记信息来释放资源。
3.3.2 LN登记管理
鉴于LNC可以规定其登记Cacheline的最大数目，每个LNR的LNR能力结构内都应提供一种机制来约束该LNR最大登记Cacheline数目，以供软件取用。如有必要，该字段应该是软件可配置的。
LNC登记资源上限可以是高度可定制化的，比如根据集合相关性、最大集合数目、主存资源的不同集合等因素来设定。
LNC可以通过LN Message来告知LNR其关注的Cacheline已被注销，LNR同样可以告知LNC注销其Cacheline登记。为了管理LNR Outstanding登记的数量，LNR可以通过发送length为0的LN Write来注销LNC中相关Cacheline登记。
LNC接收到LNR的Cachelind登记请求后，可以对请求不予响应。但一旦响应，就必须确保登记的Cacheline地址是4KB对齐的，且登记的Cacheline粒度不能小于4KB。LNR在发送主存某区域的Cacheline登记请求前是不知道这段地址是否支持Cache登记的，为获取该信息，LNR可以发送LN Read请求到该区域内的任意Cacheline，看是否会收到LN Comletion，如果正确收到了LN Completion，表示可登记。若LNR仅仅是想确认这块区域是否可登记，而非真正登记，那么LNR可以发送长度为0的LN Read。
3.3.3 LN 事务排序
LN事务排序遵循以下规则：
- LN Read的排序要求跟存储器读请求的排序要求相同。
- LN Write的排序要求跟存储区写请求的排序要求相同。
- LN Completion的排序要求跟存储器读请求Completion的排序要求相同。
- LN Message的排序要求跟转发请求PR的排序要求相同。
- 对于给定的Cacheline，若LNC在更新该Cacheline之后才收到LN Read请求，LNC发送LN Completion和LN Message的顺序未作规定。
- 对于给定的Cacheline，若LNC收到的LN Read触发了注销LN Message，LNC发送LN Completion和LN Message的顺序未作规定。
- 对于跟单的Cacheline，若LNC在更新该Cacheline之后才收到LN Write并触发了注销LN Message，LNC发送这两笔LN Message的顺序未作规定。
- 对于不同的Cacheline，LNC可以以任意顺序发送LN Message。
3.4 LN协议总结
LN协议总结如下：
- 除非另有说明，所有存储器读请求的要求均适用于LN Read。
- LN Read一次锁定不能访问超过一条Cacheline的范围，如果超出，该请求会被LNC当成CA处理（除非Completer去干其他高优先级的事去了）。长度为0的LN Read是允许的。
- 若LNC把LN Read处理为不可纠正错误或非致命错误，LNC不能登记该Cacheline。
- LNC应把长度为0的LN Read当作对于存储区域的探针进行处理，如果该区域支持登记，那么回复LN Completion的TLP头标中LN位为1，但LNC不能真的登记该Cacheline。LNC需支持4KB对齐且粒度大于4KB的Cacheline登记能力。
- LN Read的排序及流控规则与存储器读请求相同。
- 除非另有说明，所有存储器读请求完成消息的要求均适用于LN Completion。
- 若完成者为LNC，且目标存储区域接收了登记，LNC应给LN Read回复一笔LN Completion，即TLP头标中LN位为1；否则返回的Completion LN位应为0。注意：Poisoned Completion完成状态也为Successful Completion。
- LN Completion的排序及流控规则同常规Completion相同。
- 除非另有说明，所有存储器写请求的要求均适用于LN Write。
- LN Write一次锁定不能访问超过一条Cacheline的范围，如果超出，该请求会被LNC当成CA处理（除非completer去干其他高优先级的事去了）。长度为0的LN Write是允许的。
- 若LNC把LN Read处理为不可纠正错误，LNC不能登记该Cacheline的通知服务。根据具体配置，LNC可能会把被污染的LN Write当作不可纠正错误、非致命错误或可屏蔽错误处理。
- LNC应把长度为0的LN Write当作对于既有登记服务的注销进行处理，若LN Write对于地址的Cacheline本就未登记，则继续保持未登记状态。
- LN Write的排序、流控及数据污染规则与存储器写请求相同。
- 不论LN Read还是LN Write，其地址类型必须是AT字段所指定的地址类型（转换或未转换）。AT域具体采用啥值，跟系统是否采用了TA有关。（详情参考ATS服务详解）
- 若采用了TA，地址应为转换后的地址。LNR应支持ATS以采用转换后的地址。
- 若系统未采用TA，地址因为给默认地址或为转换的地址。
- 若检测到违例，LNC应把对应请求到最CA处理。
| |
✨ 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所示。
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下的设备进行广播。
| NR (b) | Description |
|---|---|
| 00 | Cacheline发生更新 |
| 01 | 单条Cacheline被注销 |
| 10 | 该Function的所有已登记Cacheline被注销 |
| 11 | 预留 |
⚠️注意：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部分。
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.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状态。
| |
✨ 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
| |
🔥 精选往期 PCIe 协议系列文章🔥
- 【最新技术早知道】PCIe Gen5 还没用上，Gen6 就来了？PCIe 6.0 系列文章之：《PCIe 6.0，到底 6 在哪？》
- 【PCIe 6.0】颠覆性技术！你NRZ相守20年又怎样？看我PAM4如何上位PCIe 6.0 ！
- 【PCIe 协议】听说你做 PCIe 很多年，还不知道 PCIe Hierarchy ID 是什么 ???
- PCIe原子操作（Atomic Operation）
- PCIe事务排序（Transaction Ordering）
- PCIe地址转换服务（ATS）详解
- PCIe访问控制服务（ACS）
- PCIe锁定事务（Locked Transactions）介绍
- PCIe组播介绍（Multicast Operations）
- PCIe TLP Prefix & PASID TLP Prefix介绍
- PCIe ARI (Alternative Routing-ID Interpretation)介绍
- PCIe TPH (TLP Processing Hints) 介绍
- PCIe RN (Readiness Notification)介绍
- PCIe EA (Enhanced Allocation) 介绍
⬆️ 返回顶部 ⬆️
更多推荐
【PCIe 6.0】缘起缘灭缘终尽,花开花落花归尘——缅怀被PCIe 6.0拿掉的LN（Lightweight Notification）协议
发布评论