合并受阻
变更摘要
本 PR 修复 Ain::Put 与 Ain::PutValue 中远程信号操作的完成跟踪问题。此前这两个接口在写入后会追加一个原子信号操作，但对应的 signal WQE 无条件关闭了 CQE 生成（.cqe = 0），导致 Flush 可能只观察到写入本身的完成便返回，而未等待追加的信号操作完成。改动将写入请求的 Config.cqe 配置透传到追加的 signal WQE 中，在保留其顺序与 fence 语义的同时使信号操作也能产生完成事件，并补充了针对两个接口的回归测试。
主要改动
- signal WQE 配置由常量改为模板: 在
ain_impl_def.h中，将SIGNAL_WQE_CONFIG常量改为模板SIGNAL_WQE_CONFIG_WITH_CQE<auto const& Config>，并把.cqe从固定值0改为Config.cqe，使追加的信号 WQE 继承写入请求的 CQE 配置。 Put使用带 CQE 的信号配置: 在ain_impl.h的Put中，将RemoteAction为AinSignalInc/AinSignalAdd时的Signal调用模板参数由SIGNAL_WQE_CONFIG改为SIGNAL_WQE_CONFIG_WITH_CQE<Config>。PutValue使用带 CQE 的信号配置: 在ain_impl.h的PutValue中做同样的模板参数替换，使其追加的信号操作同样启用 CQE 跟踪。- 测试新增 CQ 访问器: 在
tests/ut/aicore/ain/test_ain_urma_950.cpp中为测试夹具新增GetCqHead()与GetCqTail()，用于读取 CQ 头尾指针。 - 新增回归测试: 新增
PutWithRemoteSignalTracksSignalCompletion与PutValueWithRemoteSignalTracksSignalCompletion，验证Put/PutValue配合远程信号后Flush能正确等待信号完成（CqTail达到预期值）。
Thanks for your pull-request.
The full list of commands accepted by me can be found at here.
You can get sig-info at here.
You can self-configure the PR merge rules for this repository. For more details, please refer to Here.
For more, you also can visit HICANN.
PR Approval Progress
⚠️ This PR does not yet meet the following requirements:lgtm (requires ≥ 2 person(s) per module)、approve (requires ≥ 1 person(s) per module)
Module Approval Details
| module | lgtm status | approve status |
|---|---|---|
| src | ❌ (0/2)(You can also ask: 苏建加, hyolee, zhanghao_0689, 闫庆尚, 李东锋) | ❌ (0/1)(You can also ask: changxianyu, jiangxinyu3, qin437231, bluesky901, YeZZzzz1) |
| tests | ❌ (0/2)(You can also ask: kong0808, hyolee, 闫庆尚, 肖婷, changxianyu) | ❌ (0/1)(You can also ask: 闫庆尚, changxianyu, bluesky901, 石楠翔, 苏建加) |
💡 Tip:
- Committer can comment
/approveor/lgtm- Commenting
/approveimplies both code review (lgtm) and intent to merge (approve)
CLA Signature Pass
KaranocaVe, thanks for your pull request. All authors of the commits have signed the CLA. 👍
/compile
| 🚀 CI 流水线已启动 |
|---|
| 📋 执行详情: 点击查看流水线 |
@dengjing_aoe @changxianyu @qin437231 @zhanghao_0689 @chenma @shi_nanxiang @jiangxinyu3 @suqwe @houyuyang @YeZZzzz1 @kong0808 @bluesky901 @yanqingshang
麻烦各位抽空审核这个 PR；确认没有问题后，请按仓库规则补齐所需的 /lgtm 和 /approve。如果有需要修改的地方，请直接留言，我会跟进。谢谢！
@dengjing_aoe @changxianyu @qin437231 @zhanghao_0689 @chenma @shi_nanxiang @jiangxinyu3 @suqwe @houyuyang @YeZZzzz1 @kong0808 @bluesky901 @yanqingshang
昨天已请各位审核，这里再跟进一下：麻烦抽空看一下这个 PR。如有需要修改的地方，请直接留言；确认没有问题后，烦请按仓库规则补齐所需的 /lgtm 和 /approve，协助推进合入。谢谢！
当前Put伴随的Signal 功能正确性由odr=6和fence=1（发送方保序）+ WaitSignal（接收方轮询）共同保证。Signal主要用于远端同步，接收方通过WaitSignal轮询Signal计数来追踪Signal和Put的完成状态，发送方不需要通过 CQE 追踪Signal完成状态。设置cqe=1 只会增加发送方不必要的 CQ开销，无功能收益。
你指出额外 CQE 开销是对的。我已调整为：Put/PutValue 伴随 signal 时，写 WQE 关闭 CQE，最后的 signal WQE 沿用 Config.cqe。默认配置下仍只产生 1 个 CQE，完成事件覆盖复合操作末尾，原有顺序和 fence 保持不变。对应断言已更新，提交 c30a8c2 已推到 MR 分支。
感谢说明。这里的关键点是本地 Flush 的契约：Ain::Flush 调用 Hcomm::Drain，而 Drain 的目标是当前 ChannelEntity::cqHead；底层 PostSend 只有在 WQE 的 cqe=1 时才递增 cqHead。当前 signal WQE 使用 cqe=0 时，fence/odr 可以保证它在写操作之后执行，接收端 WaitSignal 也可以观察到远端信号，但发送端 Flush 仍可能只等待写操作产生的 CQE 后返回。新增回归用例正是检查这个差异：写入和 signal 共两个 WQE，修复前本地只记录一个 CQE，修复后记录两个并由 Flush 一并 drain。若仓库希望 Flush 只等待显式 CQE、而不承诺等待所有已提交 WQE，我们可以按该契约调整；否则保留 signal CQE 才能与当前“等待全部 pending tasks”接口说明一致。请确认期望的契约。
再跟进一下：按机器人最新审批进度，模块 src、tests 仍待 approve。麻烦 @qin437231 @shi_nanxiang @jiangxinyu3 @changxianyu @suqwe @bluesky901 @chenma @yanqingshang 再次抽空协助审批，并在审批条件满足后推进合并，谢谢！
/compile
| 🚀 CI 流水线已启动 |
|---|
| 📋 执行详情: 点击查看流水线 |
@mlidongfeng @xun_zhuge @changxianyu @suqwe @xiaoting624 @chenma @shi_nanxiang @yanqingshang @bluesky901 @YeZZzzz1 @jiangxinyu3
已推送 CI 修复提交 beb7eb1：恢复 CANN 9.3.0 CPU-debug UT 缺失类型的 UT-only 兼容定义，并把两项 remote-signal 回归用例加入 AIN UT 过滤列表。新流水线 #510 已通过全部编译、静态检查、API 检查和 UT。请协助复核，并按机器人当前模块要求补齐 src、tests 的 lgtm/approve。原评审讨论的 resolve 权限被拒绝，请有权限的评审人在确认后关闭讨论。
流水线分析报告 — asc-comm run#508
流水线: https://gitcode.com/CANN/asc-comm/actions/runs/699abaab296946b884fc56f0ece28523 | PR#240 | 2026-10-22 09:57:15 ~ 2026-10-22 10:00:31 | 失败 Job 1 个
定界结论: 代码问题 / LLT编译失败 — 类型未定义(hifloat4x2_t / vector_f8e6m2 / vector_hif4x2)
- 失败类型: 代码问题 / LLT编译失败(UT 任务编译期即失败, 测试用例未运行)
- 根因: 所有 aicore UT 编译目标在
tests/ut/aicore/stub/stub_def.h:19与环境 CANN 9.3.0c_api/defs/type.h:43/45处报类型未定义(hifloat4x2_t/vector_f8e6m2/vector_hif4x2), 编译级联失败导致Run UT TESTCASE is failed - 处置建议: 报错行均不在本 PR 变更范围内(本 PR 仅改
ain_impl.h/ain_impl_def.h/test_ain_urma_950.cpp), 建议: ① 提交者 rebase 最新 master 后重新触发, 排除分支基线引入; ② 仍失败且 master 同 Job 同样失败 → 属 UT 基线与环境 CANN 9.3.0 类型定义不匹配, 移交 UT 基线维护者对齐; ③ 仅本分支失败时, 提交者对比分支与 master 在 tests/ut/aicore 下的差异修复 - 排除项: 非平台错误/网络/取码问题(Checkout 正常); 非测试断言失败(编译期失败, 未进入用例执行); 非 PR 变更文件直接报错
失败根因分析
根因 #1: 代码问题 / LLT编译失败 — stub_def.h / CANN 9.3.0 type.h 类型未定义
- 判据: UT/ST 任务中的编译错误 → LLT编译失败(Job 名改判规则)
- 定位步骤:
4_ut_acc.log自末尾Run UT TESTCASE is failed回溯, 首个错误出现在 stub_def.h:19 - 影响 Job: UT
- 失败编译目标(同因): asccomm_ut_hcomm_ascend910B1_AIC / asccomm_ut_hcomm_ascend950pr_9599_AIV_roce / ..._AIV_urma / ..._AIV_jetty / asccomm_ut_ain_ascend950pr_9599_AIV_urma(失败文件含 main_global.cpp.o / test_hcomm.cpp.o / test_hcomm_jetty_950.cpp.o / test_hcomm_roce_950.cpp.o / test_hcomm_urma_950.cpp.o / test_ain_urma_950.cpp.o)
- 根因证据(日志原文):
tests/ut/aicore/stub/stub_def.h:19:18: error: 'hifloat4x2_t' does not name a type; did you mean 'hifloat8x2_t'?
19 | using hif4x2_t = hifloat4x2_t;
/home/jenkins/Ascend/cann-9.3.0/x86_64-linux/asc/include/c_api/defs/type.h:43:27: error: 'vector_f8e6m2' does not name a type; did you mean 'vector_f8e5m2'?
43 | using vector_fp8_e6m2_t = vector_f8e6m2;
/home/jenkins/Ascend/cann-9.3.0/x86_64-linux/asc/include/c_api/defs/type.h:45:29: error: 'vector_hif4x2' does not name a type; did you mean 'vector_s4x2'?
45 | using vector_hifloat4x2_t = vector_hif4x2;
gmake: *** [Makefile:91: all] Error 2
[ERROR] 20261022-100010 Run UT TESTCASE is failed.
- 补充论证(PR 变更对比): 本 PR 仅变更 3 个文件(
src/aicore/ain/impl/ain_impl.h、src/aicore/ain/impl/ain_impl_def.h、tests/ut/aicore/ain/test_ain_urma_950.cpp, +79/-10), 报错文件(stub_def.h 与环境 CANN 9.3.0 type.h)均不在变更列表; 且非本 PR 改动的公共编译单元(main_global.cpp / test_hcomm*.cpp)与 PR 自身文件(test_ain_urma_950.cpp)报完全相同的错误 → 单点 PR 改动难以解释, 更可能是基线代码或环境 CANN 9.3.0 头文件类型定义缺失所致
结构化定界摘要
[{"repo": "asc-comm", "run_number": 508, "Failed_Type": "代码问题",
"Failed_Sub_Type": "LLT编译失败",
"Failed_Reason": "UT编译失败: stub_def.h:19 与环境CANN 9.3.0 type.h:43/45 引用的 hifloat4x2_t/vector_f8e6m2/vector_hif4x2 类型未定义, 所有aicore UT目标同因失败; 报错文件均不在本PR变更范围内",
"evidence": "tests/ut/aicore/stub/stub_def.h:19:18: error: 'hifloat4x2_t' does not name a type; did you mean 'hifloat8x2_t'?",
"suggestion": "提交者先rebase最新master重新触发; 若master同Job也失败则属UT基线与CANN 9.3.0类型不匹配, 移交UT基线维护者; 仅本分支失败再对比分支差异修复",
"jobs": "UT"}]
由门禁失败定界分析自动生成 | repo: asc-comm | run: 699abaab296946b884fc56f0ece28523 | PR#240
/compile
| 🚀 CI 流水线已启动 |
|---|
| 📋 执行详情: 点击查看流水线 |
Fix AIN Put remote signal completion tracking
Ain::Put and Ain::PutValue append an atomic signal WQE after the write. Previously the signal WQE disabled CQE generation, so Flush could observe the write completion and return while the final signal operation was still in flight.
When a remote signal is present, disable CQE generation on the write WQE and carry Config.cqe to the appended signal WQE. This keeps the total CQE count unchanged while making the completion event cover the final operation. The existing ordering and fence behavior are preserved.
Regression coverage for both APIs asserts that the write-plus-signal sequence generates one CQE and that Flush consumes it.
Related issue: https://gitcode.com/cann/asc-comm/issues/58
CI 修复与验证（2026-10-22）
PutWithRemoteSignalTracksSignalCompletion和PutValueWithRemoteSignalTracksSignalCompletion加入 AIN UT 过滤列表，确保 CI 实际运行回归用例。