# HotNets 2020《Challenging the Stateless Quo of Programmable Switches》中文译注与分析

**Source:** Nadeen Gebara, Alberto Lerner, Mingran Yang, Minlan Yu, Paolo Costa, Manya Ghobadi, *Challenging the Stateless Quo of Programmable Switches*, ACM HotNets 2020.
**URL:** https://www.microsoft.com/en-us/research/uploads/prod/2020/09/gebara20challenging.pdf
**DOI:** 10.1145/3422604.3425928
**Pages:** 7
**Notes date:** 2026-04-28

本文是面向 OpenUSim / UBody 建模讨论的中文精读译注和分析，不是论文逐字全文翻译。重点保留论文对 PISA、多 pipeline、stateful application、recirculation 和 Stateful Data Plane (SDP) 的论证，以及这些内容对 `UBody` 的公开依据价值。

---

## 1. 论文定位

这篇论文讨论一个核心问题：PISA programmable switches 最初主要为 packet protocols 设计，而 packet protocols 通常偏无状态；但 in-network computing applications 往往需要频繁操作 switch 内维护的共享状态。二者之间存在结构性错配。

论文不是证明某个商业 ASIC 的具体微架构，也不是给出已量产硬件方案。它是一篇 HotNets 立场 / 设计愿景论文，主张应在传统 PISA conventional data plane 旁边增加一个专门处理复杂有状态计算的 Stateful Data Plane (SDP)。

对 `UBody` 调研最有价值的部分：

- PISA switch 的多层结构：MAU stage、pipeline、multi-pipeline switch。
- MAU stages 之间独立、无资源共享、feed-forward。
- multi-pipeline switch 中多条 parallel pipelines 之间无 state sharing。
- ingress / egress pipelines 与 input / output ports 静态绑定。
- packet 可以经 switching elements 从 ingress pipeline 到任意 egress pipeline。
- packet 若要访问另一条 pipeline 中的应用状态，只能 recirculate 到那条 pipeline。
- 作者把 multi-pipeline switch 类比为 multi-core processor，但 core 之间只能通过 recirculation paths 通信。

这些都是 `UBody` 作为 body-local datapath/network slice 的公开学术依据。

---

## 2. 摘要意译

论文摘要的大意是：

基于 PISA 的 programmable switches 让网络能够在不改变硬件的情况下部署新协议，也推动了 in-network computing。但 in-network applications 的特征和需求与传统 packet protocols 不同。传统 packet protocols 通常无状态，而 in-network applications 需要频繁操作 switch 中维护的共享状态。

这种错配增加了开发复杂度，也阻碍了 in-network computing 的广泛采用。作者描述了在 PISA 上开发 in-network applications 的关键障碍，并提出重新思考当前交换机架构。作者不主张替换现有架构，而是建议增加一个 Stateful Data Plane (SDP)。SDP 支持 stateful applications 的需求，Conventional Data Plane (CDP) 继续负责 packet-protocol functions。

---

## 3. 引言精读

论文开头指出，PISA switches 可以 line-rate 执行 data-plane programs，推动了协议、架构和 in-network computing 创新。典型 in-network computing 应用包括：

- caching。
- database query processing。
- machine learning。
- consensus。

作者认为，虽然 PISA 是这些创新的关键基础，但当前架构并不适合 emerging stateful applications。原因是：

- PISA 及其扩展最初主要服务传统 packet-processing，例如地址重写、基于 header fields 的转发。
- 这类传统任务通常状态需求有限。
- 因此 PISA 架构采用 independent match-action stages 组成的 pipeline，并把 memory / compute resources 分散在各 stage。
- in-network applications 往往是有状态的，且需要复杂数据结构，例如 hash table、cache。
- 应用状态会散落在 pipelines 和 match-action stages 中。
- 复杂操作经常无法在一次 pipeline traversal 中完成，需要 recirculation。
- Recirculation 会影响正确性和性能。

作者给出的典型例子是 cache insert：

- 插入新 item 到 cache 前，需要检查 item 是否已经存在。
- packet 可能需要遍历所有 match-action stages。
- 如果遍历后发现 item 不存在，应该插入到之前某个 stage。
- 但 PISA pipeline 是 feed-forward 的，不能回头写之前 stage。
- 常见 workaround 是把 packet recirculate 回 pipeline，但这可能影响正确性和性能。

这个问题和 `UBody` 相关：如果 body-local resource / state 分散在不同 body 或不同内部 stage，跨边界访问不能被当成普通内存访问，必须显式建模路径和代价。

---

## 4. PISA switch 结构

论文第二节介绍当前 programmable switches 的一般结构。作者把 PISA-based switch 分成三个观察层级：

- 单个 Match-Action Unit (MAU) stage。
- 一条由 MAU stages 组成的 pipeline。
- 一个包含多条 pipeline 的 switch。

### 4.1 Parser、PHV 和 deparser

Packet 处理从 programmable parser 开始。parser 抽取程序需要的 header fields，并把它们放入 Packet Header Vector (PHV)。每个 MAU stage 接收一个 PHV instance，基于 PHV 中的数据执行操作，再通过 bus 把结果送到下一个 stage 的 PHV。

最后，deparser 使用最终 PHV 重新组装 packet 和新的 headers。

对建模的启发：

- packet payload 和 header / metadata 处理路径可以分离。
- pipeline 中移动的往往是 header vector / metadata，而不一定是完整 packet body。
- `UBody` 后续如果引入 descriptor-based forwarding，可以借鉴这个思想。

### 4.2 MAU stages

MAU stage 是 programmable switch 的处理单元。它可以执行 match-action table：

- 选取 PHV 中的字段。
- 和 match table 中的值比较。
- 如果匹配，执行对应 action。
- match table 可放在 SRAM 或 TCAM。
- action unit 中的 ALU 对 PHV fields 或 register data 做简单操作。

论文强调：ALU 操作复杂度受单个 pipeline stage 的 timing constraint 限制。

### 4.3 Registers

PISA switches 在 MAU stages 中提供 registers，通常存储在 SRAM 中。Registers 是可以由 data plane 更新的 state holders。

限制是：

- 同一 stage 内可并发访问的 register 数量通常很有限。
- 复杂 stateful operation 可能超过单 stage 能力。

对 `UBody` 的启发：

- body-local state 不只是“有无”的问题，还要有访问带宽、访问次数和时序约束。
- 如果后续 `UBody` 建模 ContextBuffer / WriteBuffer / counters，最好保留 resource access limit 的入口。

### 4.4 由 MAU stages 组成的 pipeline

多个 MAU stages 组成 parser 和 deparser 之间的 pipeline。

论文的关键表述是：

- MAU stages 彼此独立。
- MAU stages 不共享资源。
- 信息沿着 stages 单方向传播。
- 如果计算需要多次读写某些值，packet 需要多次 traversing pipeline。
- 这种多次 traversing 被称为 recirculation。

对 `UBody` 的启发：

- 如果 `UBody` 内部未来拆成多个 stage，也要明确是否 feed-forward。
- 如果需要回写前级状态，必须引入 recirculation 或专用 stateful path。

### 4.5 Multi-pipeline switches

这是对 `UBody` 最关键的部分。

论文明确写到，为了扩展端口数量，交换机厂商使用多条 parallel pipelines，且 pipeline 之间没有 state sharing。

核心点：

- ingress pipelines 静态绑定到各自 input ports。
- egress pipelines 静态绑定到各自 output ports。
- packet 可以通过 switching elements 从 ingress pipeline 移动到任意 egress pipeline。
- 但如果 packet 要从一条 pipeline 移动到另一条 pipeline 去访问那里的 state，只能通过 recirculation。

作者从应用角度给出类比：

```text
multi-pipeline switch 类似一个 multi-core processor；
但一个 processor 只能通过 recirculation paths 和另一个 processor 通信。
```

这段是 `UBody` 的强公开依据之一：

```text
pipeline = port-bound local datapath with local state/resources;
cross-pipeline data path exists;
cross-pipeline state access is not free and requires explicit path.
```

---

## 5. PISA 与 stateful applications 的冲突

论文第三节系统总结 PISA 支持有状态应用时的五类限制。

### L1：复杂操作支持有限

由于每个 stage 的 cycle budget 很小，复杂算术操作很难支持，例如乘法、浮点、复杂聚合。这会影响 ML gradient aggregation、database query 等应用。

对 OpenUSim 的启发：

- `UBody` 后续如果支持复杂 stateful compute，不应默认它和简单 route decision 同成本。

### L2：Shared-nothing stage architecture

Stage 内虽然能并行做多个简单操作，但这些操作必须彼此独立。一个操作的输出不能作为同 stage 内另一个操作的输入。顺序动作必须展开到多个 stages。

此外，同 stage 可访问的 register 数量有限；stateful register operation 可能需要跨多个 stages 分区。

对 OpenUSim 的启发：

- 复杂 body-local resource 操作应有分阶段或多周期代价。
- 不应把多个状态访问都视为一个零成本事件。

### L3：Feed-forward transfer across stages

当程序状态分布在多个 stages，如果操作需要全局状态，packet 必须经过所有 stages。如果经过 pipeline 后需要更新前面 stage 的变量，只能 recirculate。

问题是：

- packet 重新进入 pipeline 时，状态可能已经变化。
- 之前读取的结果可能失效。
- recirculation 会降低新 packet 进入 pipeline 的速率，从而降低吞吐。

对 `UBody` 的启发：

- `ForwardToBody` 或跨 body state access 也可能面对同类问题：路径延迟期间目标状态可能变化。
- 如果要支持强一致语义，必须明确锁、事务或事件顺序。

### L4：固定 memory access pattern

当状态分布在 stages 中，编译器必须对变量访问顺序施加强约束。例如变量 `a` 在 stage 1，变量 `b` 在 stage 2，那么程序总是按 `a -> b` 的物理顺序访问。开发者必须按物理 memory layout 而不是逻辑 layout 思考，降低灵活性。

对 OpenUSim 的启发：

- 如果 `UBody` 未来建模多个 buffer / queue / stage，访问顺序应被文档化。
- 不应让公开 API 暗示资源可以任意顺序访问，除非模型确实支持。

### L5：No state-sharing across pipelines

这是最直接支撑 `UBody` 的限制。

论文指出，现代 switch 常见 multiple parallel pipelines。由于 switch ports 和 input pipelines 静态绑定，且缺少 inter-pipeline channels，packet 要访问另一条 pipeline 中的应用状态，只能 recirculate 到那条 pipeline。

从应用角度看，multi-pipeline switch 像 multi-core processor，但 core 之间只能通过 recirculation paths 通信。

对 `UBody` 的启发：

- body-local state 不默认跨 body 共享。
- 如果 packet 需要访问另一 body 的 state，必须显式走 `ForwardToBody` 或其他同步路径。
- 跨 body 访问应该计入性能和一致性风险。

---

## 6. 示例：Top-k heavy-hitter detection

论文用 HashPipe / top-k heavy-hitter detection 展示 PISA 对有状态数据结构的限制。

### 6.1 应用目标

Top-k heavy-hitter detection 要识别 packet 数量最多的前 k 个 flow。经典思路是维护一个固定大小的表，每个 entry 存 flow ID 和计数。

每来一个 packet：

- 如果 flow ID 已在表中，计数加一。
- 否则，找到计数最小的 entry，将其替换为新 flow ID，并把计数设为旧最小值加一。

### 6.2 Shared-nothing stage 带来的近似

找全局最小计数需要多个 register access 和顺序比较，超过单个 stage 能力。HashPipe 把表分散到多个 stages，每个 stage 用一个 hash function 随机检查一个 entry。

这会带来精度损失，因为它只比较若干随机 entry，而不是全表最小值。

### 6.3 Feed-forward 带来的 recirculation 或精度问题

朴素算法需要先遍历所有 stages 找到最小 entry，然后如果新 flow 不存在，就回到对应 stage 更新它。但 pipeline 不能回头，因此需要 recirculate。

Recirculation 最坏可能让所有 packets 都再次经过 pipeline，吞吐可能减半。

HashPipe 为避免 recirculation，把新 flow 先插入第一 stage，被踢出的 flow 随 metadata 往后传。如果后续发现更小计数就交换。这避免了 recirculation，但可能产生 duplicate entries，降低有效表容量并增加误判。

### 6.4 Multiple pipelines 下的新问题

如果 flow 定义导致同一 flow ID 可能出现在不同 pipelines，则 HashPipe-like 实现更复杂。

可能方案：

- 强制 packets 通过同一 ingress / egress pipeline，通常靠 recirculation。
- 每个 ingress pipeline 维护独立 table。

后者会增加 duplicate keys 风险，降低准确性。

对 `UBody` 的启发：

- 如果同一 flow / transaction 可能跨 body 出现，per-body table 会带来重复和统计偏差。
- 需要明确 flow owner / transaction owner。
- 对跨 body workload，聚合或 owner routing 是模型中不可省略的问题。

---

## 7. PISA 中常见 stateful data structures

论文 survey 了 in-network computing literature 中常见数据结构，并按实现难度分类。

### C1：实践上可行但受限

包括：

- Bloom filter。
- Count-min sketch。
- Hash table 的部分变体。

限制：

- Bloom filter 和 Count-min sketch 需要多个 hash functions，对应多个 registers 的读和合并。由于 L2，它们通常需要跨多个 stages。
- hash functions 数量会受 pipeline stages 数限制。
- hash table 的 collision list 长度受剩余 stages 限制，overflow 往往需要控制面处理，增加延迟。

### C2：违反 line-rate 或需要近似

包括：

- Vector。
- Priority queue。

限制：

- ML vector 可能太大，需要跨多个 packets。
- 不支持浮点会带来精度问题。
- priority queue 深度受 stages 数限制，需要近似方案，降低准确性。

### C3：缺乏完整 data-plane 实现

包括：

- Cache。
- Cuckoo hash table。
- Matrix。

限制：

- Cache replacement 需要回写前面 stage，往往需要 recirculation 或控制面管理。
- Cuckoo hash eviction 可能从最后一个 table 继续驱逐，需要 recirculation，并可能产生 race condition。
- matrix / ML inference 涉及更复杂 multiply-accumulate，超过 PISA 能力。

对 `UBody` 的启发：

- `UBody` 不应只建模 packet forwarding，还应该为 stateful resource 的访问成本和一致性问题留接口。
- 对 OpenUSim 来说，`ContextBuffer / WriteBuffer / IngressQueue` 的生命周期和 owner 比“是否有一个容器”更重要。

---

## 8. Bridging the gap：Stateful Data Plane

论文第四节提出一个方向：不继续把 PISA pipeline 做得更复杂，而是在 conventional data plane (CDP) 旁边增加一个 tightly integrated pipeline，专门处理 stateful computations，称为 Stateful Data Plane (SDP)。

### 8.1 为什么不直接扩展 PISA

已有一些 PISA 变体尝试：

- 添加更复杂的 atoms / actions，例如 Domino。
- 支持更灵活 memory access pattern，例如 dRMT。
- 在 pipeline 中混合 MAU stages 和 configurable logic-based stages，例如 FlowBlaze、Taurus。

这些能提高表达力，但可能导致：

- pipeline 更长。
- packet cut-through latency 增加。
- 不需要 stateful operations 的普通 packet 也受影响。
- 资源浪费。

### 8.2 SDP 基本思想

作者建议：

- CDP 继续处理传统 packet protocol 功能。
- SDP 专门处理复杂 stateful operations。
- parser 同时把传统 header fields 送入 CDP，把 stateful computation 需要的 fields 送入 SDP。
- SDP 通过 Stateful Queue (SQ) 接收数据。
- SDP 内部由 Data Structure Instance Blocks (DSIB) 组成。
- Application Bus 把 stateful data 送到对应 DSIB。
- Packet Reorder 单元保证 CDP 和 SDP 输出顺序一致。

一个关键约束是 slack time：

- CDP pipeline 自身有几百纳秒 end-to-end latency。
- SDP 需要在这个 slack time 内完成 stateful operations。
- 只要 SDP 在 slack time 内完成且不阻塞 packets，就不会降低传统流量性能。

### 8.3 DSIB

DSIB 是保存应用状态并执行特定操作的专用块。它们可以：

- 为特定数据结构定制，例如 top-k。
- 使用 pipeline 实现高吞吐。
- 避免 PISA 的部分限制，因为它们不必遵守传统 PISA stage 结构。
- 在一些场景下被多个应用共享。

对 `UBody` 的启发：

- 如果未来 `UBody` 需要复杂 stateful compute，可以把它拆成普通 datapath 和 stateful side-path，而不是把所有操作塞进 `NetworkUnit`。
- `ContextBuffer / WriteBuffer` 可以逐步演化为 body-local stateful blocks，但要保留时延和顺序约束。

### 8.4 Timing predictability

作者强调 SDP 必须具备可预测时延。原因是要保证 stateful computation 在 slack time 内完成。

PISA 之所以相对可预测，是因为：

- MAU stages 静态指令调度。
- 没有复杂 memory hierarchy。
- 没有 speculative execution。

作者希望 SDP 也保持类似设计目标。

对仿真模型而言：

- `UBody` 的复杂状态路径最好可配置 deterministic latency 或 bounded latency。
- 不要默认使用不可预测 host CPU-like processing 表达 line-rate datapath。

### 8.5 FPGA-based realization

作者提出初步可用 FPGA 实现 SDP path，因为 FPGA 支持 pipeline computation 和可控硬件时序。论文讨论了 FPGA 资源、100G hard MAC、on-chip RAM、400-850 MHz clock 等可能性，也指出 CPU 因 PCIe bandwidth、cache 和 speculative execution，不适合这种确定时延 / 高带宽路径。

这部分不是 `UBody` 的直接依据，但提供一个重要思想：

- 有状态复杂计算可以通过专用硬件块和 pipeline 化实现。
- 不应把它抽象成通用 CPU 处理。

### 8.6 Top-k DSIB

作者用 top-k DSIB 说明 SDP 的可能实现：

- parser 抽取 flow ID。
- flow ID 通过 stateful queue 和 application bus 送到 top-k DSIB。
- DSIB 维护 k 个 bins，每个 bin 包含 flow ID 和 counter。
- pipeline 中的 bins 通过比较、更新和 swap 模拟类似 bubble sort 的过程。
- 这种设计可以避免在原始 CDP 中因 L1/L2/L3 无法跨 stage swap 的问题。

论文引用旧 FPGA 实现的吞吐约 110M items/s，clock 约 115 MHz。作者认为现代 FPGA 可能更高，并预计在不少可编程 switch pipeline 的 slack 时间内维护数百个 top-k values 是可能的。

对 `UBody` 的启发：

- 如果 `UBody` 后续需要更复杂的 body-local scheduler / queue / top-k / allocator，可以考虑专用 stateful block，而不是挤进普通 packet forwarding path。

### 8.7 Scaling to multi-pipeline switches

作者最后指出，前面讨论的是给单个 CDP 增加 SDP。但很多高端口交换机会有多条 pipelines。

他们判断：

- 2-pipeline switch 可能一个 SDP path 就够。
- 64-port / 4-pipeline switch 可能需要更多 SDP paths，甚至每条 pipeline 一个。
- 这种情况下，可能还需要 reduction SDP path，把所有 SDPs 连接起来做 global computations。

对 `UBody` 的启发：

- 多 body 里，如果每个 body 都有本地 stateful block，可能还需要一个 IoDie-level reduction / aggregation path。
- 这和我们把 `IoDie` 作为 body 管理和聚合边界的设计方向一致。

---

## 9. 结论意译

论文结论认为，in-network computing 是 programmable networks 带来的新应用类别。第一代应用已经在多个非传统网络领域展示收益，但也暴露出现有 programmable switches 执行 stateful computations 的严重限制。

作者总结了影响 in-network applications 的架构特征，整理了常见 stateful data structures，并说明它们在当前 PISA 上的痛点。基于这些观察，作者提出在 conventional data plane 之外部署第二个 data plane，即 Stateful Data Plane，让交换机能够执行更复杂的有状态计算。

---

## 10. 对 UBody 的强支撑点

这篇论文对 `UBody` 的支撑主要有七条。

### 10.1 多 pipeline 是现代 switch 常见结构

论文明确说 modern switches 常见 multiple parallel pipelines。这个事实支撑 `UBody` 可以类比公开的 datapath pipeline / slice。

### 10.2 端口与 pipeline 静态绑定

论文明确写到 ingress / egress pipelines 分别静态绑定 input / output ports。这支撑 `UBody` 拥有本地 port set。

### 10.3 pipeline 间无 state sharing

论文明确写到多个 parallel pipelines 没有 state sharing。这个点直接支撑 `UBody` 之间不应默认共享 resource / state。

### 10.4 跨 pipeline packet path 存在

论文指出 packet 可以通过 switching elements 从 ingress pipeline 到任意 egress pipeline。这支撑 `ForwardToExternalPort` / cross-body egress 的存在。

### 10.5 跨 pipeline state access 需要 recirculation

论文指出 packet 若要访问另一 pipeline 中的 application state，只能 recirculate 到那条 pipeline。这支撑 `ForwardToBody` 作为显式跨 body state access path，而不是免费共享访问。

### 10.6 多 pipeline 像 multi-core，但通信路径受限

作者的 multi-core 类比很有用：多个 pipeline 类似多个处理核，但只能经 recirculation paths 互通。对 `UBody` 可以类比为多个 body-local datapath slices，通过显式内部互联通信。

### 10.7 复杂 stateful compute 可以走旁路专用数据面

论文提出 CDP + SDP 的 split。对 OpenUSim 的启发是，未来 `UBody` 中复杂状态逻辑可以被建模为 body-local stateful blocks 或 IoDie-level reduction path，而不是全部塞进基本 NetworkUnit。

---

## 11. UBody 映射表

| 论文概念 | OpenUSim / UBody 映射 |
| --- | --- |
| PISA pipeline | body-local datapath slice |
| ingress pipeline statically bound to input ports | body owns ingress/local ports |
| egress pipeline statically bound to output ports | egress port maps to body owner |
| no state sharing across pipelines | no implicit cross-body state/resource sharing |
| switching elements between pipelines | `UbNetworkOnChip` / future body fabric |
| recirculation to access state in another pipeline | explicit `ForwardToBody` / state-owner path |
| MAU stages share no resources | future body-internal stages should expose resource boundaries |
| registers in MAU SRAM | body-local counters / buffers / context state |
| SDP / DSIB | future body-local stateful blocks or IoDie reduction blocks |
| reduction SDP path | IoDie-level aggregation path |

---

## 12. 不能从该论文推出的结论

这篇论文不能支撑以下说法：

- `UBody` 就是 PISA pipeline。
- `UBody / BD` 是公开行业术语。
- 所有商业交换机都按 PISA 结构实现。
- 所有 pipeline 都只能通过 recirculation 通信；这是论文针对 PISA/multi-pipeline state access 的描述，不是所有硬件的普遍规范。
- 论文给出了具体 crossbar、VOQ、buffer depth、latency 或 arbitration 参数。
- 论文的 SDP 是已被标准化或商业化的方案。

这篇论文真正支撑的是：

```text
PISA-based programmable switches expose a public architecture pattern where
ports are bound to local pipelines, pipelines have local state/resources,
cross-pipeline forwarding is explicit, and cross-pipeline state access is costly.
```

---

## 13. 建议写入 OpenUSim 公开文档的中文表述

```text
UBody 是 OpenUSim 中的 body-local 数据路径 / 网络切片抽象。公开 PISA 研究指出，
现代可编程交换机常使用多条 parallel pipelines；ingress / egress pipeline 静态绑定
到各自 input / output ports，pipeline 之间不默认共享 state。Packet 可以经 switching
elements 从 ingress pipeline 转到任意 egress pipeline，但访问另一 pipeline 的应用状态
需要显式 recirculation。OpenUSim 用 UBody 表达类似的本地端口、本地资源和显式
cross-body path。
```

更保守的英文表述：

```text
UBody is an OpenUSim abstraction for a body-local datapath/network slice.
It is aligned with public PISA multi-pipeline observations: pipelines are
statically associated with ports, maintain local state/resources, and require
explicit paths for cross-pipeline state access.
```

---

## 14. 对 OpenUSim 后续建模的具体建议

短期保持：

- `UBody` 继续表示 body-local `NetworkUnit`。
- `body -> ports` 显式配置。
- 跨 body 访问继续通过 `ForwardToBody` / `UbNetworkOnChip` 表达。
- 不默认 `UBody` 之间共享 counters、queues、register-like state。

中期可细化：

- 把 `UBody` 内部分成 conventional datapath 和 stateful resource path。
- 为复杂 body-local 状态操作增加 bounded latency / access limit。
- 为 cross-body state access 增加 recirculation-like cost。
- 为需要全局计算的状态增加 IoDie-level reduction / aggregation path。
- 区分 ordinary forwarding packet 和 stateful computation event。

不建议：

- 不要把 `ForwardToBody` 视为零成本函数调用。
- 不要把复杂有状态操作混入普通 fast path 而不计时延。
- 不要公开宣称 `UBody` 复刻 PISA 或 SDP。

---

## 15. 与 Cisco Q200、PSA、NetSoft 2021 的关系

这篇 HotNets 2020 论文和前几份资料形成互补：

- Cisco Q200 白皮书给工业 multislice ASIC 证据：slice、crossbar、VOQ、SMS、OQ。
- P4 PSA 规范给规范级 multi-pipeline 证据：ports hard-wired to pipeline、pipeline-local state、output-port-driven egress pipeline。
- NetSoft 2021 论文给应用系统层证据：multi-pipeline 无 coherence 会让有状态应用失效。
- HotNets 2020 论文给 PISA 架构层证据：MAU stages、feed-forward pipeline、multi-pipeline port binding、no state sharing、recirculation-only state access，以及可能的 stateful side-plane 设计方向。

合起来可以支撑：

```text
UBody 是公开可解释的 body-local datapath/network slice 抽象；
其建模重点应包括本地端口、本地资源、显式 cross-body path、state owner、
同步/重定向代价，以及未来可能的 body-local stateful blocks。
```

---

## 16. 一句话结论

这篇 HotNets 2020 论文强力支撑 `UBody` 的公开论据：现代 PISA-style programmable switches 中，多 pipeline、端口静态绑定、本地 state/resource、无默认 state sharing 和显式 recirculation/state path 都是公开讨论过的架构事实。`UBody` 可以被保守描述为 OpenUSim 对这类 body-local datapath/network slice 的仿真抽象，而不是某个商业实现的复刻。
