导言
刚理解 WQE 时，我看到一份 MoE dispatch 头文件没有调用 aclshmemx_udma_put_nbi()，也没有在发送热路径调用 aclshmemx_udma_quiet()。第一反应是：它是不是用 SIMT 加速了 WQE 下发，又用 Data-as-Flag 代替了完成通知？本文先沿标准接口追踪 Tensor 如何被降成地址、长度与 WQE，再把它与头文件中的批量直驱实现逐项比较。最后得到的边界是：SIMT 加速的是提交，Data-as-Flag 加速的是接收端就绪判断；二者都没有让 UDMA、SQ/CQ 生命周期或源 buffer 完成语义消失。
导言
原生 URMA 要显式管理 Context、Segment、Jetty、WR 和完成队列。cann/shmem 提供了更高层的 PGAS 编程模型：程序主要面对“对称地址、目标 PE、put/get 和同步”。本文先解释 aclshmem_my_pe()、aclshmem_n_pes() 和 aclshmemx_udma_put_nbi()，再用两 PE 的 put-with-signal Case 说明数据和通知如何配合。
导言
“WQE 和 Jetty SQ 还不能同时写？”这句话实际上混合了四个问题：软件和硬件能否同时访问队列、一个 SQ 能否挂多条请求、多个 Host 线程能否共享 Jetty、多个 AIV 能否直接驱动同一 QP。答案并不相同。本文先讲清提交与完成，再逐一划定并发边界。
导言
本文把 URMA 官方样例中的核心 WRITE 路径收缩成一个教学 Case。目标不是复制几百行初始化代码，而是让零基础读者看懂：程序要准备哪些资源、每个结构体字段是什么意思、一条请求如何提交和确认完成。文中的核心代码按官方接口整理；初始化和带外交换用伪代码表示，实际编译时应以所使用 UMDK 版本的头文件与官方样例为准。
导言
我刚开始接触 URMA 时，最容易卡住的问题不是某个函数不会调用，而是概念没有连成一条线：WQE 和 Jetty SQ 是什么关系，Segment 为什么要注册和导入，urma_post_jetty_send_wr() 提交之后又去了哪里。本文只做一件事：沿着一条 WRITE 请求的生命周期，把这些名词放回它们各自的位置。
导言
阅读 4357 行 deepep_moe_dis_dispatch.h 时，最大的困难不是找到某个函数，而是持续维护 E2E 阶段、函数调用和具体源码行之间的对应关系。静态长文适合建立概念框架，却不便于在多条并行执行路径之间反复定位。
本页将同一份 Ascend C 参考实现组织为三轨联动工作区：左侧展示 Full-Mesh dispatch 的端到端执行 DAG，中间拆解当前函数的调用和分段逻辑，右侧保留完整源码。读者可以从阶段进入函数、从调用跳转到被调函数，也可以通过搜索和行号反向追踪同步协议与数据流。
导言
MoE dispatch 的困难并不只是把 token 从一张卡搬到另一张卡，而是要在 Top-K 路由运行时才确定的前提下，同时解决槽位分配、跨核协作、远程写入、完成通知和接收端连续排布。如果只盯着某个拷贝循环，很容易忽略控制面和同步协议才是这份实现的骨架。
本文以 deepep_moe_dis_dispatch.h 的 4357 行 Ascend C 参考实现为对象，从 SIMT 线程模型和 Full-Mesh 通信窗讲起，沿“本地打包 → 生成并提交 URMA WQE → doorbell 触发 → flag/count 对账 → 前缀和定位 → 输出重排”还原完整执行路径。页面把关键函数、内存布局、时序约束和可验证的优化方向放到一张连续地图中，帮助初学者建立从源码行号到通信机制的对应关系。
导言
这是一篇用于验证 HTML 正文文章接入 的站内测试文章。它保留 Markdown front matter 和简短导言，让 MkDocs Blog 能继续生成文章 URL、首页摘要、分类、标签和搜索索引；实际正文则由同名 .preview.html 在文章详情页中展示。
核心判断是：HTML 只是正文表现形式，Markdown 文件仍然是站内文章身份和索引入口。因此读者可以从笔记、分类或标签进入本文，也可以从本文返回对应索引页面。
导言
一次 64 B 远端读取，数据在链路上只需要约 200 ns，端到端却可能超过 2 μs；当 1024 个本地发起上下文连接 1024 个远端端点时，按 Queue Pair（QP）组织的连接状态又会膨胀到约 537 MB。OpenURMA 认为这不是某个 RDMA Kernel 写得不够快，而是 QP over PCIe 这一抽象同时制造了状态乘积和外围设备往返。
OpenURMA 是 Unified Bus（UB）传输层与事务层的 clean-room 开放实现。它用 Jetty / TP Channel 拆开应用状态与可靠传输状态，把 UB Controller 放到片上总线，并为短同步操作提供绕过 Work Queue 的 Load/Store 路径。本文沿这条依赖链解释方案，同时把 500 ns / 2186 ns 放回论文的模拟条件：这组结果证明新抽象值得继续做成硅，不等于 Ascend 950 或任意商用 UB 产品已经交付同样数字。
导言
我面对的是一个很具体、也很容易被“理论带宽”带偏的问题：Ascend DeepEP 的 MoE dispatch 吞吐只有硬件理论值的一半，128P 跨机场景尤其明显，而且系统里还有两层路由。麻烦在于，我既不熟悉 MoE dispatch 的接口与数据协议，也没写过典型 URMA/UDMA 算子，更不知道应该在哪里计时、打印和判断瓶颈。
这篇文章不从零散优化技巧出发，而是沿一条 token 的真实旅程，依次读懂 Python 接口、Host 侧 workspace/notify、Device 侧 AIV/UDMA/QP、目标 rank 的接收布局与反向 combine；再把 ascend_deepep、海思 hierarchy 和 MoonEP 的 peer 调度放进同一张拓扑图。最终目标不是立即猜出一个“神奇参数”，而是建立一条可证伪的优化路线：先区分数据面、控制面和同步面，再判断 128P 下真正撞到的是字节带宽、WQE 提交率、P 维路由扫描、拓扑扇出还是最慢 rank 的尾延迟。