CHI协议保序之trans order保序

newyork major

已于 2023-08-22 12:32:39 修改

阅读量866

点赞数 1

分类专栏： chi协议相关文章标签： arm开发

于 2023-07-23 21:48:43 首次发布

本文链接：https://blog.csdn.net/zhangshangjie1/article/details/131884640

版权

chi协议相关专栏收录该内容

27 篇文章 18 订阅

订阅专栏

一致性系统中，使用三种保序方式；

================Transaction ordering===================

□ 除了 comp response 来规定 RN 发出的 requeset 的执行顺序之外，还有一种 order 机制来定义RN<->HN,HN<->SN 之间，命令执行的顺序：
□ 该机制通过在 trans 中增加一个order 域段，该order域段定义了如下4中行为：
        ■ Request Order.
        此种保序方式，可以保证同一个RN，去往同一个地址的多笔传输的顺序：
        ■ Endpoint Order.
        此种保序方式，保证同一个RN,发往同一个endpoint addr range 的多笔传输的顺序，从描述上看，可以看出，这种方式是包含了 request order 的：
        ■ Ordered Write Observation, OWO.
        对于同一个agent 的一连串写操作（没有地址要求），其他 agent 会以相同的顺序观察到：，
        ■ RequestAccepted.
        这个保证了当completer 收到了读请求，会返回正向的 acknowledgement（不会发生retry）；

使用上：
The Order field must only be set to a non-zero value：
• ReadNoSnp
• ReadNoSnpSep
• ReadOnce*
• WriteNoSnp
• WriteNoSnp*CMO
• WriteNoSnpZero
• WriteUnique
• WriteUnique*CMO
• WriteUniqueZero
• Atomic

■ 当readnosnp/readonce*的order域为Request Order or Endpoint Order：
        □ 此时RN需要接收端返回ReadReceipt，来决定什么时候可以发送下一个请求；
        □ 在completer看来，返回ReadReceipt表明，当前的命令已经到达了保序点，并且会按照接收到的命令的顺序进行；
                对于Request Order， completer会将来自相同来源的，访问相同地址的trans进行保序；
                对于Endpoint Order，completer会将来自相同来源的，访问相同endpoint address range的trans进行保序
        □ 对于可以发送独立data resp/ non data resp的completer, 可以通过发送RespSepData
来代替readreceipt, 可以达到相同的目的；

■ 当WriteNoSnp, WriteNoSnpZero or a Non-snoopable Atomic transaction requires Request Order or Endpoint Order:
        □ Requester需要在得到DBIDResp之后，才能发送下一个需要保序的请求；
        □ 对于completer而言，发送DBIDResp意味着，data buffer已经准备好了，此笔写请求已经到达了保序点，并且会按照接收的命令顺序来执行这些命令；
                对于Request Order， completer会将来自相同来源的，访问相同地址的trans进行保序；
                对于Endpoint Order，completer会将来自相同来源的，访问相同endpoint address range的trans进行保序；

■ 当WriteUnique transaction without ExpCompAck， WriteUniqueZero， Snoopable Atomic transaction的order需求是request order:
□ requester需要在得到DBIDResp之后，才能发送下一个需要保序的请求；
□ 对于completer而言，发送DBIDResp意味着，对于同一个source，访问同一个地址的请求，将会保序处理；

当某个命令没有order需求，completer发送DBIDRespOrd之后，那么HNF将对之后收到的,来自同一个source的命令（no order or request order），（不仅是写），全部按照接收的顺序处理；

WriteUnique or WriteNoSnp transaction requires Ordered Write Observation：
□ RN必须将expcompack置1；
□ RN也必须收到DBIDResp or DBIDRespOrd；
□ Completer是一个保序点，其发送DBIDResp or DBIDRespOrd意味着：
        --data buffer准备好了；
        --POS点保证了，这个写的一致性操作，不依赖于下一笔OWO的写操作；
        --直到收到compack之后，该笔写操作才可以被observed;

读操作

When a ReadNoSnp or ReadNoSnpSep has the Order field set to 0b01, a ReadReceipt response from the Completer guarantees that the Completer has accepted the request and will not send a RetryAck response.

保序原则

当一个Requester发出多个不同order需求的transactions组合时，最后能得到保障的order方式遵循如下原则：
1、如果有No ordering命令，那么Order Guarantee将是No ordering；
2、如果没有No ordering，有Request Order，那么Order Guarantee将是Request Order；
3、如果没有No ordering和Request Order，那么Order Guarantee将是Endpoint Order。
总结以上就是遵循最弱保序原则；

注意点：

□ 如果ReadNoSnp3, 和ReadNoSnp2之间有保序要求，那么3就必须等到2的readreceip回来之后才能发送；

CopyBack Request order

□ RNF在发送另外一个相同cacheline的copyback命令之前，必须等到之前已经发送的copyback命令的CompDBIDResp返回；
□ 但有一个例外，如果是SnoopMe置位的Atomic transaction操作就允许RN-F还未收到CopyBack的CompDBID响应就发送出去；

Streaming Ordered Write transactions
□ Writeunique/writenosnp trans适用于OWO;
□ 如果RN想要让其他RN观察到其发送的trasn的顺序，和其发送的顺序相同，那么它就要在发送下一个写之前，等待上一个写的comp响应，这种观察顺序称之为OWO;

提出一种更加高效的方式，Streaming Ordered Writes；
■ Streaming Ordered Writes 机制依赖于使用OWO和compack; 此时，RN和HNF需要做如下事情；
□ RN必须将order field设置成0b10(OWO),并且expcompack要开启；
□ 写请求的OWO需求需要HN-F完成该笔一致性写操作不依赖于下一笔一致性写操作的完成；
□ 在发送下一个写操作之前，RN必须要等到DBIDResp, DBIDRespOrd, CompDBIDResp, or Comp其中一个返回；
=>也就是不需要必须等待Comp之后才能发送了，这样减少等待时间了；
□ Requester在收到相应WriteUnique的Comp响应后，且之前WriteUnique transactions的Comp响应也都全部收到了，就必须要返回CompAck响应了；如果此时有写数据也要发送，那么RN可以将CompAck和Data组合起来为NCBWrDataCompACK后一块发送；
□ HN-F在释放一笔WriteUnique transaction资源且对其它RN-Fs可见之前，必须需要收到RN-F发送的CompAck响应；
□ RN收到DBIDResp*之后，不能等待comp再发送compack;

Optimized Streaming Ordered WriteUniques
□ Streaming Ordered WriteUnique机制可以进一步简化。如果之前WriteUnique是访问不同的目的节点，那么RN不需要等待DBIDResp就可以发送下一笔ordered WriteUnique。然而，如果ICN可以对TgtID remap，那Requester必须预知所有WriteUniques指向同一个HN-F并且不使用optimized Streaming Ordered WriteUnique流程。
□ 使用Optimized Streaming Ordered WriteUnique必须注意死锁或活锁场景；OSOW的最大受益者通常是RN-I；通过使用WriteDataCancel messages可以避免资源相关的活锁和死锁，因此OSOW可以用于多于一个RN。