一致性协议理解：保序与order

1. Order使用背景

1）除非特别要求，对Normal memory、Device RE的访问，同地址保序即可；

2）对Device nRE\Device nRnE的访问，需要对空间访问保序；

3）CHI中，互联不保证顺序，从相同channel发布的命令不一定按照相同顺序到达HN。

问题：那么CHI如何解决transaction顺序问题？

CHI中提供Comp、CompAck、Order这3种mechanism解决顺序问题，下文分别描述。

1. Comp mechanism
   1. Comp如何传递？

为了解决顺序问题，CHI协议要求Comp满足：“A completion guarantees that the request has reached a PoS or a PoC, where it will be ordered with respect to requests to the same address from any Requester in the system.-P146”。即Completer发布Comp意味着transaction到达下一保序节点，将按照接收transaction的顺序进行处理。接下来，只要保证Completer接收顺序与Requester发布顺序一致即可。

1）在Requester侧，仅当收到Comp之后，再发布同地址/同地址范围的访问；

2）在Completer侧，当transaction到达保序节点（PoS）后，回Comp。（具体见2.4节）

1. 1. Transaction与Comp

不同transaction的Comp根据访问地址类型，具有不同的含义，具体如下：

    1）读访问Noncacheable/Device地址空间时，CompData确保transaction对后续同一地址段（endpoint address range，impdef，from any agent)的transaction可见

    2）读访问Cacheable地址空间时，CompData确保transaction对后续同一地址（location，from any agent）的transaction可见

    3）Dataless transaction（仅可访问Cacheable地址空间），Comp确保transaction对后续同一地址（location，from any agent）的transaction可见

    4）写、Atomic访问Noncacheable/Device nRnE/Device nRE 地址空间时，Comp/CompData确保transaction后续对后续同一地址段（endpoint address range，impdef，from any agent)的transaction可见

5）写、Atomic访问Cacheable/Device RE 地址空间时,Comp/CompData确保transaction对后续同一地址（location，from any agent）的transaction可见

总结规律：若是memory attribute为Device nR*，来自同一agent的去往相同address range的transaction将按照接收顺序进行处理。否则，来自同一agent的相同地址将按照接收顺序进行处理；（备注，读访问不受nR控制？）

1. 1. Comp什么时候发布？

对于Write：Comp表示该笔传输对其他RN是observable的（收到Comp之后，假如其他RN发布相同地址的读传输，那么读到的一定是该笔传输的数据），因此：

1）对于WriteNoSnp，不需要snoop其他RN，HN收到transaction即可返回Comp (This flow example shows Comp is sent after CompDBIDResp is received from SN-F. However, HN-F is permitted to send Comp anytime after it receives the WriteNoSnp request from RN-F0.-P192)

 

备注：思考Write的Comp：EWA： Early Write Acknowledgement，表示Write Completion Response是否可以从中间节点提前返回。如果EWA=0，则Write Completion Response必须从Endpoint节点返回后中间节点才能返回。因此上图中如果EWA=0，则HN向RN发送Comp时必须等待收到SN返回的CompDBIDResp. 除*NoSnp、Atomic外的所有传输EWA必须为1.

2）对于WriteUnique，HN必须收到所有snoop resp之后才能返回Comp（因为Comp必须保证别的RN中的cache已经被invalid，之后读到的是新数据）；

 

3）对于CopyBack，因为Comp与DBIDResp必须合并为CompDBIDResp发送，因此必须等到DataBuffer可用后返回；（由于ICN并不保证前后到达的顺序，因此HN在发送CompDBIDResp之前必须保证接收到所有向该RN发送的相同地址的snoop请求对应的响应？）

 

4）对于Atomic store，需分Snoopable和NonSnoopable分类，Comp与DBIDResp分开或者合并；而其他Atomic由CompData返回，必须分开。

 

 

对于Read：Comp通过CompData返回，因此如果有Snoop，一定是在snoop resp之后。

对于Dataless：

1）MakeUnique、CleanUnique必须等snoop resp返回才可汇Comp

 

2）Evict直接返回：

 

3）StashOnce*直接返回：

"HN-F can immediately send Comp to RN to acknowledge the Stash request.";-P277:"Permitted to send Comp after receiving the StashOnce request, and before sending any SnpStash or receiving the Snoop response."

 

4)CMO：本身cache state不改变，别的RN的cache state可能会改变，因此猜测需要Snoop结束再返回，没有找到图片。

1. 1. Comp mechanism的局限

1）对于读访问，Comp通过DATA通道返回，必须是在获得数据后再返回的，相当于有保序要求的transaction的outstanding深度是1，尤其是需要SN侧取数据的时候，效率很低。

2）对于写访问，WriteUnique需要等待监听结束

1. CompAck mechanism
   1. CompAck如何传递？

若没有CompAck，会怎么样？如下图所示：若无ACK机制。RN1正在进行对某个地址的读取操作（不带Snoop或者snoop已完成），而RN2也在对该地址进行读取操作。对于ICN而言，虽然先收到RN 1的Read，再收到RN 2的Read，但由于CHI不要求总线保序，所以可能Snoop先于Compdata到。这样就会出现对于同一个事情而言，RN1和RN2看到的不同。RN1因为先前已经进行了Snoop，所以认为自己是UC。RN2因为在Snoop的时候看到RN1还是没有该地址的cache，也认为自己是UC。从而产生了不一致。可以归类为，边界条件下，某个状态被全局中各个agent看到的不一致。

而增加CompAck机制后，ICN在收到CompAck之后才能发布对同一地址/地址范围的Snoop访问，从而保证来自一个Requester的transactions与不同Requester的transactions导致的snoop transaction的相对顺序。("The relative ordering of transactions issued by a Requester, and Snoop transactions caused by transactions from different Requesters, is controlled by the use of a Completion Acknowledgment response. This ensures that a Snoop transaction that is ordered after the transaction from the Requester is guaranteed to be received after the transaction response.")

总结CompAck传输规则：

1）在RN侧：收到Comp、CompData之后再回CompAck；

2）在HN侧：在收到CompAck之前，不能发起对同一地址的snoop（对CopyBack transaction，WriteData充当CompAck角色）（HN是从收到transaction还是从返回Comp还是从发snoop到CompAck之间不能发对同一地址的snoop呢？答：HN应当是从发本笔snoop到发CompAck之间不会发对同一地址的snoop；确保RN从收到Comp到回CompAck之间不会收到snoop）。

上述2点确保RN收到Comp和对同一地址snoop的顺序与HN发布Comp和snoop的顺序一致，从而确保对同一地址的transaction通过正确的顺序观察到

1. 1. CompAck与transaction

仅当ExpCompAck被assert时，Requester才会发送CompAck给HN。使用规则：

1）在RN-F中，除ReadNoSnp/ReadOnce*之外的Read transaction必须assert ExpCompAck；ReadNoSnp/ReadOnce*可按需置位ExpCompAck；MakeUnique/ CleanUnique必须assert；WriteUnique可按需置位；其 他transaction禁止置位ExpCompAck；

2）在RN-I/RN-D中，Read transaction、Write Unique可按需置位ExpCompAck；其他禁止置位ExpCompAck

总结：涉及cache state transition的transaction必须assert ExpCompAck。（疑问：CopyBack传输过程中也涉及cache state transition，为何不需要ExpCompAck？因为CopyBackWdata相当于CompAck。）（CompAck一般用于指示RN内的Cacheline状态已经被改变，并且可以接受后续传输的Snoop请求。）其他ReadNoSnp/ ReadOnce*和WriteUnique不涉及cache state transition转换，但为了配合order使用可以assert？

1. Order Mechanism

Comp保序导致效率较低，有无更高效的办法？CHI提供Order 机制，不必等到Comp即可发布同地址/地址范围，只要与下一保序节点（HN）协商好即可。

1）Request Order：保证来自同一agent，去往相同address location的多个transactions的顺序；对于WriteNoSnp，将进一步保证从任意agent发送向同一地址的传输顺序？

 

2）Endpoint Order：保证来自同一agent，去往相同endpoint address range的多个transaction的顺序；

3）Ordered Write Observation：来自同一agent的，一连串write transactions被别的agents观察到顺序与发布顺序一致（？）

4）Request Accepted：receiver已收到Request，并且不会返回RetryAck

 

Ordering Requirements：仅ReadNoSnp、ReadOnce*、WriteNoSnp、WriteUnique、Atomic这几类transaction的order必须设为non-zero。为何是这几类支持order呢？上述传输的特点在于从发布transaction的agent没有cache或者不allocate这笔transaction，因此从发布到收到Comp过程中，cacheline状态一直是Invalid态（不变），因此支持通过order域指定order requirement，而不需要Comp。

当相邻传输具有不同的order requirement时，选择较低的order requirement：

 

1. 1. Order与transaction

不使用Comp保序之后，HN使用ReadReceipt提前告知RN该读笔操作已经到达下一保序节点；使用DBIDResp告知RN该笔写操作已经到达下一个保序节点。

1）若ReadNoSnp、ReadOnce*中使用Request Order、Endpoint Order，则：

   1-1）在Requester侧，收到ReadReceipt后再发布下一个ordered request；

   1-2）在Completer侧，发布ReadReceipt意味着：request已经到达下一保序节点，并将按照接收到的顺序进行保序。

 

2）若WriteNoSnp、Non-snoopable Atomic中使用Request Order、Endpoint Order，则：

   2-1）在Requester侧，收到DBIDResp之后才能发布下一个ordered request；

   2-2）在Completer侧，发布DBIDResp意味着：request已经到达PoS，并将按照接收到的顺序进行保序。数据buffer已经获得，写请求已经进入PoC并且会保持他被接收的顺序。）

3）若WriteUnique（ExpCompAck=0）、Snoopable Atomic中使用Request Order，则：

   3-1）在Requester侧，收到DBIDResp之后才能发布下一个ordered request；

   3-2）在Completer侧，发布DBIDResp意味着：Completer将维持来自同一agent，去往同一地址的requests的顺序。（

4）若WriteUnique中使用Ordered Write Observation，则：

   4-1）在Requester侧，必须置位ExpCompAck，再收到DBIDResp之后才能发布下一个ordered Request；

   4-2）在Completer侧，Completer是一个PoS，发布DBIDResp意味着：本笔request的coherence action的完成不依赖与后续write request（require Odered Write Observation)的coherence action的完成。

   4-3）在Completer侧，收到CompAck之后，才能使本笔request被其他Requesters可见

疑问：不同order stream间的ordering dependency如何解除的呢？不同的stream间不需要保序，如何识别不同的stream呢？2.4-P69，详见3.1.1。

（   RN需要DBIDResp来决定是否发送下一个需要保序的传输。Completer的一个DBIDResp表明，数据buffer已经获得，PoS将保证此次传输结束的一系列相关性操作，将不依赖于下一个写传输的相关的相关性操作。直到CompAck后写才是可见的。

）

5）CopyBack Request Oder：（for an outstanding CopyBack transaction)

   5-1）在Requester侧，收到CompDBIDResp之后才能发布一下个对同一cacheline的request；

   5-2）在Requester侧，在收到CompDBIDResp之前，允许发布一笔Atomic transaction（SnoopMe=1）。

1. 1. 1. Streaming Ordered

如果Requester发出一连串的WriteUnique transaction，并且希望transactions被观察到的顺序与发布顺序一致，有如下方法：

1）Ordered Write Observation:Comp表征该transaction被观察到，因此Requester可以等收到Comp之后再发送下一个WriteUnique

2）CHI还提供另外更高效的方法：

2-1）Streaming Ordered:（使CompAck与transaction issue顺序一致来保序）

     在Requester侧：

        a）设置order=Ordered Write Observation（告知HN，本笔transaction的Comp不依赖与后续WriteUnique）；

        b）设置ExpCompAck=1（在收到本笔Comp以及所有先发ordered WriteUnique的Comp之后，返回CompAck（用以确保先发WriteUnique已完成HN处的操作，其他观察到本笔CompAck的RN肯定已经观察到先发的WriteUnique））；

        c）收到DBIDResp之后，再发布下一个WriteUnique

     在HN侧：

        a）HN必须等到CompAck之后，才能Deallocate这笔WriteUnique，才能使这笔transaction对其他observers可见（？）

2-2）Optimized Streaming Ordered：

     在上述Straming ordered的基础上，若是上一笔WriteUnique的Target不同，则Requester在发送下一笔ordered WriteUnique之前，不需要等DBIDResp（因此，若是ICN可以remap TgtID，则不可使用本方法）

实现上述两种优化方法时，必须注意避免deadlock和livelock：

1）一种避免技术：

   1-1)系统中限制一个Requester使用Optimiazed Streaming Ordered WriteUnique,其他RN可以使用Streaming Ordered WriteUnique

   1-2)使用Optimized Streaming Ordered WriteUnique的Requester最好是一个RN-I（比如PCIe）

   1-3)若在多个Requester中使用Optimized Streaming Ordered WriteUnique，可以使用WriteDataCancel避免资源相关的deadlock或者livelock

若是EWA使能的、访问Noncacheable\Device的Write transaction，Comp没有确保transaction后续对后续同一地址段（endpoint address range，impdef，from any agent)的transaction可见,还可采取如下技术确保同一地址段transaction保序：

    1）order=Endpoint Order，那么后续同样具有order=Endpoint Order的transaction，且在同一endpoint address range的transaction将被保序

    2）后续对同一地址Read transaction的CompData可以确保Write transaction对后续同一地址段（endpoint address range，impdef，from any agent)的Write transaction可见

解决不同RN间处理相同地址的一致性问题：

利用CompAck：（前提：互联不保证顺序，从RSP/DATA通道与SREQ通道发布的命令不一定按照发布顺序到达RN，乱序导致一致性出错）

1）在RN侧，仅当完成cache state transition之后再回CompAck；

2）在HN侧，在Comp------CompAck之间，不允许发送相同地址的snoop；

1. 1. Order与Direct transfer的关系

如下表所示，DCT传输对order字段不做要求，而DMT在有order要求时，必须将ExpCompAck置位，因为：

1）DCT可以使用SnpRespFwd or SnpRespDataFwd确保transaction完成，保证顺序；

2）而使用DMT的transaction：（HN需要知道什么时候释放该笔transaction）

   2-1）在no ordering的情况下，若ExpCompAck=0，则可以使用Request Accepted确保SN不会回RetryAck，从而释放资源；

   2-2）在no ordering的情况下，若ExpCompAck=1，则即可使用Request Accepted，又可以使用CompAck提前释放资源；

   2-3）在ordering的情况下，因为Request Accepted不保证在SN侧的顺序，因此除非ExpCompAck=1，不能发送ordering的DMT transaction

 

1. AXI ordering
   1. Transaction ordering

Master使用AXID表征ordering requirements:

1）源自不同Master的Transactions间没有order约束，可以任意顺序完成；

2）源自同一Master，AXID不同的transactions间没有order约束，可以任意顺序完成；

3）源自同一Master，一串具有相同ARID的Read transaction必须以Master发布的顺序完成；

4）源自同一Master，一串具有相同AWID的Write transaction必须以Master发布的顺序完成；

5）源自同一Master，具有相同AXID的Read与Write transaction间没有order约束，可以任意顺序完成；若Master对Read与Write有顺序要求，必须等前者返回后再返回后者；

1. 1. Ordering model定义

对于具有相同AXID的transactions：

1）若target为single peripheral device，必须以发布顺序到达target，不论任何地址；

2）若target为memory，对相同地址、有overlap的地址，必须以发布顺序到达target；

总结下表：同地址一定保序；非同地址时，如果memory type为Device，则同ID保序；如果memory type为Normal，则同ID也可不保序