当前位置：首页 > news >正文

CHI协议——retry

news 来源：原创 2025/5/8 22:11:56

防止请求阻塞：当Completer暂时无法处理请求(比如tracker不够被占满)时，通过retry机制避免请求在 REQ Channel堆积，确保系统流畅运行。

retry机制只存在于REQ Channel，在DAT/RSP/SNP Channel不存在

二、Retry Flow

a.允许重试的字段 AllowRetry 在第一次发送时必须置位，PCrdType必须为0(意味请求允许retry)。

b.完成者在资源不足时返回 RetryAck，并记录请求srcID和PCrdType(HN自己定即可 0-15)。

c.当资源可用时，完成者发送 PCrdGrant(包含PCrdTye)。

d.请求者收到后可以重试请求，此时 AllowRetry 必须置零(因为completer既然给Requester发了PcrdGrant就代表它有资源处理该请求了，那就不允许再retry了，所以置0)，确保第二次尝试被接受。PCrdTye设置为之前分配的值。

完成者可能在发送 RetryAck 之前发送 PCrdGrant，但请求者必须等待两者都收到后才能重试。这涉及到协议中的顺序问题，虽然允许乱序到达，但请求者必须等待两者都到达才能继续。

-----------------------------------------------------------------------------------------------------------------------

举个通俗易懂的例子：以餐厅点餐为例

顾客（请求者）点餐：
- 发送订单（请求）到厨房（完成者）
- AllowRetry=1：允许厨房拒绝订单
厨房资源不足：
- 厨房返回 RetryAck（“现在太忙，请等会儿再来”）
- 记录顾客 ID（SrcID）和所需资源类型（PCrdType，如 “煎锅资源”）
厨房资源恢复：
- 发送 PCrdGrant（“煎锅可用了”）给顾客
- 顾客收到后重新提交订单
- AllowRetry=0：这次必须成功
订单完成：
- 厨房处理订单并返回结果（响应）
- 顾客释放事务 ID（TxnID），可重复使用

-----------------------------------------------------------------------------------------------------------------------

三、PCredit Return

超额分配场景：

假设请求者发起两次相同的高 QoS 请求（QoS1 和 QoS2），但仅需一次成功：

-----------------------------------------------------------------------------------------------------------------------

请求者需要保留请求的所有详细信息，直到收到一个响应，该响应表明请求已被接受，或者必须在稍后的某个时间点再次发送。
从发送请求开始，到以下情况结束：
- 取消请求并返回信用（PCrdReturn）
- 收到 RetryAck+PCrdGrant 并成功重试
- 收到所有预期响应（如 ReadReceipt）

重新发送的事务必须具有与原始请求相同的字段值，除非该字段不适用，或者属于以下字段之一：

服务质量（QoS）
目标 ID（TgtID），请参阅 B3.3.1 中关于请求消息的目标 ID 确定规则。
事务 ID（TxnID）
返回事务 ID（ReturnTxnID），适用于以下情况：
- 从主节点（Home Node）到从节点（Subordinate Node）的无窥探读取（ReadNoSnp）和无窥探分离读取（ReadNoSnpSep），且未使用数据移动事务（DMT）流。
- 从主节点到从节点的无窥探写入（WriteNoSnp）或组合写入（Combined Write），且未使用数据写入事务（DWT）流。
数据目标（DataTarget）
允许重试（AllowRetry），该字段必须取消置位
协议信用类型（PCrdType），该字段必须设置为原始事务的重试响应中所指定的值。
跟踪标签（TraceTag）
保留位（RSVDC）
缓存属性提示（CAH）
预取目标提示（PrefetchTgtHint）

6. CopyBack Write retry

当请求者收到针对回写（CopyBack Write）请求的重试确认（RetryAck）响应，且该请求的数据已被窥探操作无效化时，请求者可以选择以下两种操作之一：

信用与特定事务之间没有固定的关系。如果请求者针对不同事务收到了多个重试确认响应，然后又收到了一个信用，则不存在固定的信用分配方式。请求者可以从收到具有该特定协议信用类型的重试确认响应的事务列表中，自由选择最合适的事务。

重试机制最多支持 16 种不同的信用类型。这使得完成者可以针对不同的资源使用不同的信用类型。例如，完成者可以对与读取事务相关的资源使用一种信用类型，对写入事务使用另一种信用类型。通过使用不同的信用类型，完成者能够通过控制哪些重试请求可以再次发送，来高效地管理其资源。

完成者必须能够记录所有的重试确认响应，以确保信用得到正确分配。如果完成者使用了多种信用类型，则必须记录针对每种信用类型给出的重试确认响应。

请求者必须限制已发出事务的数量，以确保完成者无需跟踪超过 1024 个需要授予协议信用响应的事务。这可以通过将每个请求者的未完成事务的最大数量限制为 1024 来实现。

一个事务从首次发出请求的周期开始，一直处于未完成状态，直到出现以下两种情况之一：

事务完全完成，即收到了该事务预期的所有以下响应：
- 读取回执（ReadReceipt）
- 完成数据（CompData）
- 响应分离数据（RespSepData）
- 数据分离响应（DataSepResp）
- 设备标识符响应（DBIDResp*）
- 完成（Comp）、完成一致性修改操作（CompCMO）、完成持久化操作（CompPersist）和完成缓存隐藏操作（CompStashDone）
- 完成设备标识符响应（CompDBIDResp）
收到重试确认和授予协议信用响应，并且请求满足以下情况之一：
- 使用适当协议信用类型的信用进行重试，随后根据所有响应的返回情况确定事务已完全完成。
- 取消事务，并使用信用返回（PCrdReturn）消息返回已收到的信用。

请求者可以在以下两种情况下重用请求所使用的事务 ID 值：