一、TP 在协议栈中的定位

UB 协议栈自顶向下四层：

Transaction(TA)  →  Transport(TP/CTP)  →  Network(NL)  →  DataLink+Physical(DL_PHY)
                                                                    ↓
                                                               H112 SerDes

TP 是第二层，向下对接 NL，向上承接 TA/IMP/LSA 构造的 TPWQE 任务。核心职责：

• 维护通信节点间各类 context（TPC/TPGC/TPMM/TPWQE/DAM/EUM 等）
• 通过 mailbox 创建/修改/销毁 context
• 建立 TP 连接，检测网络丢包，多种重传机制提供端到端可靠传输
• 多种拥塞控制、流控算法
• 检测异常并返回完成信息

学习要点：TA 把"事务"交给 TP，TP 负责"搬运+可靠"。TP 之下 NL 负责路由/查表，DL_PHY 负责链路。
TP 一侧还承接 IMP（mailbox 配置）和 LSA（LSAR，Slave 方向 Load/Store 通路，放在 TP 层实现）。

---

二、TP vs CTP（两种传输服务）

项	TP（可靠传输）	CTP（简易传输）
端到端重传	支持	无（仅 Link 层重传）
TP 连接	有	无
消息速率	较低	较高
时延	较高	较低
适用	框间、需可靠	框内直连、低延时
承载报文	CFG3/4/7（IPv4/IPv6/CNA24）	CFG7（CNA24）

学习要点：CTP 牺牲端到端可靠性换取"高包率+低延时"，仅靠 Link 层重传兜底——适合框内直连小规模组网。URMA 两种都能跑，UNIC 基于 CTP 的 Unreliable Message 传输。

---

三、RC / RM 两种保序模式

模式	全称	协议 Model	保序方式	TAACK
RM	Reliable Messaging	Model-1	消息保序	Write/Send 需回 TAACK
RC	Reliable Connection	Model-3	连接保序	无 TAACK 步骤

TAACK 构造时机（关键差异）：

• RC 模式：TP 收到 write 请求即可写 payload，无需 RC Credit 申请；TP 发出后直接构造 TAACK 给 TA
• CTP 模式：由 TP 构造 TAACK
• TP 模式：需等对端 TPACK 回来后才构造 TAACK

学习要点：RC 比 RM 快的关键——RC 不用等对端 TPACK，TP 发出即可通知 TA 完成。这也解释了性能笔记里 RC Write 单向 vs RM 的 2 倍差距。
CTP RM 模式源端保序由 TA fence 完成（不在 TP 层做）。

---

四、多路径与保序（5 种 Ordering 模式）

4.1 源端保序 vs 目的端保序

• 源端保序：TP 和 CTP 都可通过多端口多路径传输
• 目的端保序：
  • TP：一个连接只通过一个端口发包，可走多网络路径，接收侧乱序接收由 TP 保序
  • CTP：一个 Jetty 可选是否走多路径
    • 单端口单路径 → 通道保序
    • 多路径 → 只保证包内序，不保证包间序

4.2 5 种 Ordering 模式（与 Operation 矩阵）

UB 系统中 Ordering 处理点有 11 个，其中 No.5 / No.10 / No.11 直接呈现给业务软件：

• No.5：Server Memory Global Observed（业务直接感知）
• No.10：Server 侧 Completion（异步 URMA 才有）
• No.11：Client 侧 Completion（异步 URMA 才有）

5 种模式的 Ordering 矩阵速记（Yes=保证 Server 侧执行序；Fence/SO 是 2nd op 的标记）：

模式	线路序传递	多路径	典型特征
CTP Path-Order	是（路径保序，非源保序）	单 Jetty 单路径	同一目的地多路径需用多 Jetty
CTP Source-Order	否（只在 Client 源头用）	单 Jetty 可多路径	用户 SQE.Order 不上线路
TP RC GBN	—	不支持 TPG；目的保序	Go-Back-N 重传
TP RC OOR	—	Out-of-Order 接收	接收侧乱序，由 TP 保序
TP RM	否（源保序）	—	消息保序，需 TAACK

通用规则（从矩阵归纳）：

• Write → Write：默认 No；2nd op 加 SO 才 Yes
• Read/Atomic → Write：默认 No；2nd op 加 Fence 才 Yes
• Write → Read/Atomic/Send：默认 Yes（write 后续读可见）
• Read → Read：CTP Source-Order / TP RM 是 Yes；CTP Path-Order / TP RC 是 No
• 若 2nd op 是 Read/Nop，加 Fence 不生效（按不添加处理）
• Nop 只在 Client 执行，Server 收不到，不参与 Server 侧 Ordering

4.3 Observation（可观测性）

A 向 B 写数据：

1. 对 A Observed：A 拿到 Completion 后，再发起对 B 的读能读到 / 写能覆盖
2. 对 B Observed：B 上请求源发起对 B 地址的读能读到 / 写能覆盖
3. Global Observed（对 C）：A 通告 C，C 发起对地址的读能读到 / 写能覆盖

学习要点：Ordering 矩阵是 TP 的核心难点。记忆口诀：

• “Write 后读可见，Read 间默认乱序；想让后续等前面，Fence 或 SO 来加冕”
• CTP Path-Order 走"路径保序"——同目的地多路径必须用多 Jetty；CTP Source-Order 走"源保序"——SQE.Order 不上线路。

---

五、CTP RC 多路径

• URMA 在无可靠传输层时支持一种多路径传输方式：线路乱序传输，但不需要回 TAACK
• 对应 TA Jetty 保序模式是 RC，通过 Jetty Ctx 指示开启
• 当前只支持上游下发 write with atomicStore ADD（上游保证 wqe 不超 MTU，TA 不切片发 TP）
• TA 和 TP 不具备多路径保序能力，需接收端定制逻辑实现（如 CCU 的 counter+flag 机制）

学习要点：利用 CTP 的高包率 + 多路径带宽，由 CCU 接收侧用 counter+flag 自己保序，绕开 TP 的保序瓶颈。

---

六、TP/TPG 负载均衡

6.1 TP/TPG 级负载均衡

• TPWQE 进入 TP 携带 vTP，根据 vTP 编号映射至不同的 TPG/TP
• 若映射至 TPG，TPG 根据 group 内不同 TP 负载情况，选择负载较轻的 TP 发送
• 不同优先级的 TPG 编号一定不同 → TA 层为不同优先级 JFS 分配不同 vTP，分别映射到不同 TPG

6.2 CTP 负载均衡

• CTP 流量用 DCNA 查路由表，在多个可达端口间负载均衡发送

6.3 VL Group 级负载均衡（三层水线）

为解决 TX/RX 的 ETS / VL QoS 抢占问题，三层水线涉及模块：

1. NL_OQ（维护对端 RX buffer 信用）
2. U_DIE OSS（维护本端主机侧 QoS）
3. N_DIE TP_TX（维护本端主机侧 QoS）

设计按 4 个 VL group 实现，对外承诺 3 个；默认每 port 支持 4 个 VL group，实际能跑满 2 个。

VL Group	默认覆盖
Group0	同一 URMA 通道的 2 个 VL
Group1	同一 URMA 通道的 2 个 VL
Group2	3 个 UBmem VL（N DIE）/ 2 个 VL（U DIE）
Others（share buffer）	其余 VL

学习要点：负载均衡有三级——TP/TPG 级（vTP 映射）、CTP 端口级（DCNA 查表）、VL Group 级（三层水线）。VL Group 是为解决 ETS/VL QoS 抢占而设计的，“设计 4 承诺 3 跑满 2”。

---

七、拥塞控制 SCC

SCC = Software Congestion Control。算法在 TPC 中通过 cng_alg_sel 字段选择：

cng_alg_sel	算法	说明
3’b000	不支持拥塞控制	—
3’b001	DCQCN（不支持拥塞程度）	—
3’b010	DCQCN（支持拥塞程度）	—
3’b011	LDCP	窗口拥塞控制
3’b100	CAQM	窗口拥塞控制
3’b101	ACC1.1	窗口拥塞控制

关键约束：

• 对接双方 TP 初始化时 cng_alg_sel 必须保持一致
• CAQM 与 TPACK 多路径同时开启会导致 CAQM 不准（用 tpack_spray_en 开关控制 TPACK 是否走多路径）
• CTP 拥塞控制只使用 DCNA 的低 16bit，用 {DCNA[15:0], VL} 索引拥塞控制上下文

窗口拥塞计算方式（cng_cwnd_ctrl）：

• 0：整报文长度（UN_LINK 至 ICRC），默认
• 1：报文 pld + cng_cwnd_hdr_len
• 2：tph + [ueid] + tah + [tah_ext] + payload + pad + ICRC + cng_cwnd_hdr_len（奇数向上 1B 取整）

动态超时（dyn_at_en）：

• dyn_at_en=1：基于 TPC.RTT / TPC.base_time 计算超时
• dyn_at_en=0：使用 tpc.at 作为超时时间
• 公式：Timeout = Base_time * 2^(N * Times)，N 为 at_times，建议最大重传次数时 Timeout < 5s

学习要点：5 种拥塞算法分两类——DCQCN（基于 ECN 反馈）和窗口类（LDCP/CAQM/ACC1.1）。对接双方算法必须一致。CTP 拥塞控制索引只用 DCNA 低 16bit。

---

八、关键数据结构（TP 侧 context）

数据结构	全称	用途
TPC	TP Context	TP 连接上下文（核心表，含 PSN/MSN/重传/拥塞窗口/port 选择等）
TPGC	TP Group Context	TP 组上下文（vTP→TPG 映射，组内 TP 负载均衡）
TPMM	TP Memory Management	TP 内存管理
TPWQE	TP WQE	TP 任务缓存
DAM	Dest Address Memory	目的地址表（dip/dmac/sip/smac）
EUM	EID UPI Memory	EID/UPI 映射（seid_idx 访问获取 UPI/SEID）

TPC 关键字段速记

字段	作用
tp_mode	TP 保序模式（1’b0 = TP 保序）
tpg / tpg_vld	所属 TP Group
portn / bkup_portn	主/备 port 全局编码
soft_port_sel/flg / hw_port_flg	主备 port 切换控制
cng_alg_sel	拥塞控制算法选择
cng_cwnd_ctrl / cng_cwnd_hdr_len	窗口拥塞计算方式
spray_en / switch_mp_en	端侧/交换机自主多路径使能
tpack_spray_en	TPACK 多路径开关（避免 CAQM 不准）
retry_cnt / retry_cnt_ini / port_change_retry_cnt	重传与 port 切换阈值
dyn_at_en / at_times / base_time / RTT	动态超时计算
route_addr_idx / route_type	访问 DAM 表项（IPv4/IPv6/CNA）
vlan_en	VLAN 使能（需与 dest_addr.vlan_en 一致）
oor_en	乱序接收使能
jettyn / sjetty	Send 报文目的/源 Jetty 号
MTU	00=1KB, 10=4KB（2KB 不支持）
tpack_doing	TP 存在 TPACK 在排队
wait_cqe_timeout	确保 TP 在 Timer 模块只占一个 ACK 超时结点

学习要点：TPC 是 TP 的"灵魂表"——保序、重传、拥塞、port 切换、路由全在这里配置。

---

九、重要约束（踩坑预警）

9.1 地址与配置约束

• TP pf_reg 访问范围：仅允许指定访问范围，否则挂死
  • UDIE 支持 22 个 PF（pf0~pf21），每 PF 2K 地址，共 44K；总分配 48K
• route_type 一致性：RC/RM 时 TPC.route_type 必须与 dest_addr.route_type 一致，否则硬件挂死
• vlan_en 一致性：RC/RM 时 TPC.vlan_en 必须与 dest_addr.vlan_en 一致

9.2 流量与复位约束

• pause 帧反压：TP 注销/PF 复位/flush_cqe/FE 复位会对所有 VL 排流，若某些 VL 被 pause 帧反压则无法排空导致复位失败 → 软件需开启风暴抑制功能
• TP 流量和 CTP Response 不能共用 VL，否则死锁风险；jetty ctx.sl 和 wqe.tpid 不能填错
• CQE-INLINE 约束：URMA 的 CQE-INLINE 流量在 u-die 场景下不能派生出 ubmem 流量

9.3 功能使用约束

• CTP write with immediate：消息长度最大仅支持 1 MTU size（4KB）
• RC TP 发生 RC 资源 RNR 让 TA 重传：
  • RM Jetty + RC TP：可打开此功能
  • RC Jetty + RC TP：若存在 read 不超越 atomic 的需求，需关闭此功能
• TA Jetty Error continue 模式：只能使用 TPG 模式或 CTP 模式，不能使用单 TP 模式
• TP 场景带宽达标：请求及 TAACK 需保证独立 TP 传输，否则请求与 TAACK 在相同 TP 队列 burst 排布，导致局部时间集中反馈 TAACK，带宽下降

9.4 拥塞控制约束

• 对接双方 TP cng_alg_sel 必须一致
• ack_freq_mode=1（减少 tph.a 数量）仅在 cng_alg_sel=0 时可为 1
• CTP 拥塞控制只用 DCNA 低 16bit

学习要点：这些约束是踩坑高发区。最容易出问题的是：route_type/vlan_en 不一致挂死、pause 帧导致复位失败、TP/CTP Response 共用 VL 死锁。

学习要点：Read 的 TP 延时（~276ns）远高于 Write（~68ns），因为 Read 需要等对端响应；负载从静态升到 80% 时延时增加约 10%（Read 276→301，Write 68→102）。

---

十、一图速记

软件(TA/IMP/LSA) ──TPWQE──▶ TP
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
         context维护      拥塞控制 SCC     多路径/保序
         ┌─TPC(核心)      ┌─DCQCN         ┌─源端保序(多端口)
         ├─TPG/TPGC       ├─LDCP          ├─目的保序(TP单端口)
         ├─TPMM           ├─CAQM          ├─CTP RC多路径(V160新增)
         ├─TPWQE          └─ACC1.1        └─VL Group三层水线
         ├─DAM
         └─EUM                故障切换
                              ├─多平面自动切换(V160新增)
              可靠性           ├─主备port(soft/hw_port_flg)
              ├─重传(retry_cnt)└─Pagefault(仅Nimbus V7)
              ├─TAACK/TPACK
              └─动态超时(2^N倍)

两种服务:
  TP(可靠,端到端重传) vs CTP(简易,仅Link重传,高包率低延时)

两种保序模式:
  RM(Model-1,消息保序,需TAACK) vs RC(Model-3,连接保序,无TAACK步骤)

---

学习自测问题

1. TP vs CTP 在端到端重传、消息速率、时延、适用场景上的区别？
2. RC 和 RM 模式的核心差异？为什么 RC 的 Write 包率是 RM 的 2 倍？
3. TP 模式、CTP 模式、RC 模式下 TAACK 的构造时机分别是什么？
4. CTP Path-Order 和 CTP Source-Order 的区别？SQE.Order 是否在线路传递？
5. CTP RC 多路径（V160 新增）的保序由谁实现？为什么 TA/TP 自己做不了？
6. vTP → TPG → TP 的负载均衡映射关系是什么？TA 层如何配合？
7. VL Group 三层水线涉及哪三个模块？设计几个、承诺几个、能跑满几个？
8. SCC 支持哪 5 种拥塞控制算法？对接双方需要保持什么一致？
9. Port 主备切换的 soft_port_sel/flg 和 hw_port_flg 配合机制？
10. V160 相对 V100 在 TP 上的 4 大升级是什么？Nimbus V7 独有哪两个特性？
11. TPC、TPGC、TPMM、DAM、EUM 各自的作用？V160 U die 把 TPC cache 翻到多少？
12. TPC.route_type 和 dest_addr.route_type 不一致会导致什么问题？
13. TP 流量和 CTP Response 为什么不能共用 VL？
14. RC Jetty + RC TP 时，"RC 资源 RNR 让 TA 重传"功能何时必须关闭？
15. TA Jetty Error continue 模式只能用哪两种 TP 模式？