Ascend Send Ordering

导言

之前学习 Data-as-Flag 时,我们讨论过把 flag 塞进数据块:每个 512 B 块中,480 B 是有效数据,32 B 用来证明“这一块已经到达”。现在希望减少这部分控制开销,改成“前面 relaxed order 发送,最后一个 strong order”。

这个改动的核心,是把“每块都带证明”改成“用队列末尾的有序操作,为前面一批传输提供完成证明”。 但必须解释清楚:最后一个是什么、保证覆盖哪条队列、接收方如何得知完成,以及何时可以复用 buffer。本文沿实际代码逐层回答。

Read more

Ascend 950 RM Target Selection

导言

已经知道组 WQE、敲 doorbell,接下来要弄清:如果同一个本地发送端点要向不同 rank 发送,每条 WQE 的远端目标在哪里设置? 本文沿 SHMEM 的 pe → remote_mem_info → WQE 追踪源码,再对照 elastic_dispatch.cpp。关键是分清本地队列、远端寻址元数据,以及 put/write 中容易被误读成 Jetty ID 的内存 tokenId。

Read more

AIV UDMA Direct Drive

导言

刚理解 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 完成语义消失。

Read more

SHMEM UDMA Programming

导言

原生 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 说明数据和通知如何配合。

Read more

URMA Completion and Concurrency

导言

“WQE 和 Jetty SQ 还不能同时写?”这句话实际上混合了四个问题:软件和硬件能否同时访问队列、一个 SQ 能否挂多条请求、多个 Host 线程能否共享 Jetty、多个 AIV 能否直接驱动同一 QP。答案并不相同。本文先讲清提交与完成,再逐一划定并发边界。

Read more

Ascend DeepEP MoE Dispatch Optimization

导言

我面对的是一个很具体、也很容易被“理论带宽”带偏的问题: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 的尾延迟。

Read more

Ascend Data Movement Evolution

导言

在昇腾通信栈的第四轴里,ACL Copy、LD-ST、MTE、IPC、SDMA、RDMA 与 UDMA 被放在相邻位置。看到这么多搬运相关名词,一个很自然的判断是:它们大概是同一种能力的不同代际,后来者之所以出现,是因为前一代不够好。

这个判断抓住了技术演进的一部分,却把几类不同对象混在了一起。这些概念不是七代同类传输引擎,而是地址能力、操作表达和执行后端在不同距离、粒度与控制路径下的组合。本文从无法绕开的物理成本出发,再沿历史纵轴和技术横轴解释它们为何没有统一,以及什么时候一种新思想才真正值得形成新的代码仓。

Read more

Ascend Communication Stack

导言

华为昇腾通信资料最容易制造一种错觉:DMA、HCCS、HCCL、SHMEM、Fabric Memory 和 AIV 直驱仿佛是一摞可以从上到下整齐堆叠的软件层。实际并非如此。这些词分别回答“谁组织通信、谁建立地址、谁提交任务、谁搬数据、数据走哪条物理链路、对端是否参与”中的不同问题。有些是库,有些是协议或硬件,有些只是数据路径属性;把它们画在同一层,关系一定会错。

本文把历史纵轴和技术横轴合并:先建立一张总地图,再逐个概念给出小白版与专业版解释,最后核对公开仓库的首次可见提交、立项目的、硬件范围、迁移和待废弃状态。研究截止日为 2026 年 8 月 26 日。

Read more