一、TP 在协议栈中的定位
UB 协议栈自顶向下四层：
Transaction(TA) → Transport(TP/CTP) → Network(NL) → DataLink+Physical(DL_PHY) ↓ H112 SerDesTP 是第二层，向下对接 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 写数据：
- 对 A Observed：A 拿到 Completion 后，再发起对 B 的读能读到 / 写能覆盖
- 对 B Observed：B 上请求源发起对 B 地址的读能读到 / 写能覆盖
- 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 抢占问题，三层水线涉及模块：
- NL_OQ（维护对端 RX buffer 信用）
- U_DIE OSS（维护本端主机侧 QoS）
- 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步骤)学习自测问题
- TP vs CTP 在端到端重传、消息速率、时延、适用场景上的区别？
- RC 和 RM 模式的核心差异？为什么 RC 的 Write 包率是 RM 的 2 倍？
- TP 模式、CTP 模式、RC 模式下 TAACK 的构造时机分别是什么？
- CTP Path-Order 和 CTP Source-Order 的区别？SQE.Order 是否在线路传递？
- CTP RC 多路径（V160 新增）的保序由谁实现？为什么 TA/TP 自己做不了？
- vTP → TPG → TP 的负载均衡映射关系是什么？TA 层如何配合？
- VL Group 三层水线涉及哪三个模块？设计几个、承诺几个、能跑满几个？
- SCC 支持哪 5 种拥塞控制算法？对接双方需要保持什么一致？
- Port 主备切换的
soft_port_sel/flg和hw_port_flg配合机制？ - V160 相对 V100 在 TP 上的 4 大升级是什么？Nimbus V7 独有哪两个特性？
- TPC、TPGC、TPMM、DAM、EUM 各自的作用？V160 U die 把 TPC cache 翻到多少？
TPC.route_type和dest_addr.route_type不一致会导致什么问题？- TP 流量和 CTP Response 为什么不能共用 VL？
- RC Jetty + RC TP 时，"RC 资源 RNR 让 TA 重传"功能何时必须关闭？
- TA Jetty Error continue 模式只能用哪两种 TP 模式？
