| Files | Last commit | Last update |
|---|---|---|
[fix]移除AIV/CCU检查拦截 Co-authored-by: littlemons<yaowenjie7@huawei.com> # message auto-generated for no-merge-commit merge: !5508 merge thread into master [fix]移除AIV/CCU检查拦截 Created-by: littlemons Commit-by: littlemons Merged-by: cann-robot Description: ## 描述 1. HcommThreadAllocWithStream：删除上游引入的引擎白名单（仅 CPU/CPU_TS），分支上 CCU kernel launch 依赖此接口申请 host 线程，引擎合法性由 thread.cc 的 CommHostEngineToNotifyLoadType 单点保证，避免两处引擎列表漂移； 2. 删除 HcommThreadAllocWithCommConfigCheck 与 L2 ValidateThreadAcquireParams 中的 AIV/CCU 拦截：底层替换 C 接口后该休眠拦截被激活，导致老接口 HcclThreadAcquire 透传的 CCU 流量（engine=5）误报 E_PARA；下游 thread.cc 转换表 （NOTIFY/STREAM_TYPE_CONVERT）已支持 (CCU/AIV, THREAD_TYPE_TS)，拦截属误伤， 删除后引擎裁决单点收敛到 thread.cc； 3. TS 枚举拦截（CPU_TS/AICPU_TS）保留，作为防呆校验； ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [ ] 📋 其他，请描述： ## 关联的Issue <!-- 待填：cherry-pick 原提交关联的 Issue 链接；若无则填 NA --> ## 测试 已完成的测试用例和场景： 1. 冒烟用例 2. bash build.sh --pkg --ut：threads 模块（TestHcclThreadAllocWithStream、 TestHcclThreadAcquireWithConfig）与 CCU 控制面用例（HcommCcuControlApiTest）全量通过 <!-- 上述结果请以实际跑测为准，未通过前不要勾选下方检查项 --> 补充的UT用例： When_EngineCcu 期望值由 HCCL_E_PARA 调整为 HCCL_SUCCESS（随引擎能力演进）； Ut_When_UnsupportedEngine 清单收窄（AIV/CCU 移出，改由 thread.cc 转换表裁决）。 ## 文档更新 NA ## 合入检查 - [x] 🧐 已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 - [x] 🔍 邀请 committer评论/lgtm前的必要检查 - [x] 🏷️ 标题中使用了合适的类型标签（如：[feat], [fix]） <!-- 标题建议：[feat]ThreadMgr底层替换HcommThread标准C接口（cherry-pick 320de944） --> - [x] 📄 代码修改内容已简要描述，相关文档已更新 - [x] 📝 代码注释已更新，代码遵循项目整体代码风格 - [x] 🧪 代码UT测试已更新，覆盖率已达标 <!-- UT 跑过后勾选 --> - [x] 🔬 验证方法已更新到"测试"部分 - [x] 🛠️ 代码已通过静态分析工具检查，无错误 - [x] 👥 代码检视/code review/同行评议和必要的代码串讲，确保代码质量 - [x] ✅ 代码检视意见已处理或答复，无未处理的检视意见 - [ x 🚀 预约 前冒烟 用例前的必要检查 - [x] ✔️ 代码已有committer的/lgtm 和 模块committer的/lgtm评论 - [x] 🔧 代码已通过compile，编译无错误，无告警 - [x] 🖥️ 代码已通过基本功能本地测试或者在线测试，确保基本功能正常 - [x] 🎯 预约 approver评论/approve，正式合入前的必要检查 - [x] 📊 前冒烟 用例已全量通过 - [x] 📦 新增功能已同步补充基本功能测试用例到前冒烟里 See merge request: cann/hcomm!5508 | 1 month ago | |
[fix] sort rankid in deserialize ranktable Co-authored-by: zhiweihai_00958272<zhiweihai@huawei.com> # message auto-generated for no-merge-commit merge: !5377 merge fix/sortRankId into master [fix] sort rankid in deserialize ranktable Created-by: Helmar Commit-by: zhiweihai_00958272 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> HcclCommInitClusterInfoV2 初始化通信域时，当 ranktable 文件中 rank_id 顺序与 JSON rank_list 数组顺序不一致（例如 rank_id:2 排在 rank_id:1 前面），会导致 RankGraphBuilder::AddFabricInfo 用 rankId 作为数组下标访问 ranks[rankId] 时取到错误 rank 条目的网络地址，进而在 CheckRankGraphAddrs 的 EID 校验阶段报错。 根因：RankTableInfo::Deserialize 按 JSON 出现顺序填充 ranks[]，Check() 只校验 rankId 连续/不重复/范围，不排序. 修复方案：在 Deserialize 的 Check() 之后补 std::sort 按 rankId 升序排序。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [ ] 📋 其他，请描述： ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR不涉及Issue，可填写NA。--> NA ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于构造对应xx测试用例、二级冒烟、算子泛化等。--> 已完成的测试用例和场景： 1. 构造 rank_id 顺序与 rank_list 数组顺序不一致的 ranktable 文件（rank_id:1 排在 rank_id:0 前面，同时含 net_layer:0 和 net_layer:2），使用 HcclCommInitClusterInfoV2 初始化，修复前在 CheckRankGraphAddrs EID 校验报错，修复后初始化成功 2. 验证只有 net_layer:0 的场景修复前后行为一致（level 0 路径不依赖排序） 补充的UT用例： 待补充 ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> 无 ## 合入检查 <!-- 在正式合入前，请做好必要的代码测试，用例补充，软件代码风格检查等。提高合入效率。--> <!-- [x] 表示选中 --> - [x] 🧐 已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 - [ ] 🔍 邀请 committer评论/lgtm前的必要检查 - [x] 🏷️ 标题中使用了合适的类型标签（如：[feat], [fix]） - [x] 📄 代码修改内容已简要描述，相关文档已更新 - [x] 📝 代码注释已更新，代码遵循项目整体代码风格 - [ ] 🧪 代码UT测试已更新，覆盖率已达标 - [x] 🔬 验证方法已更新到测试部分 - [x] 🛠️ 代码已通过静态分析工具检查，无错误 - [ ] 👥 代码检视/code review/同行评议和必要的代码串讲，确保代码质量 - [ ] ✅ 代码检视意见已处理或答复，无未处理的检视意见 - [ ] 🚀 预约 前冒烟 用例前的必要检查 - [ ] ✔️ 代码已有committer的/lgtm 和 模块committer的/lgtm评论 - [ ] 🔧 代码已通过compile，编译无错误，无告警 - [ ] 🖥️ 代码已通过基本功能本地测试或者在线测试，确保基本功能正常 - [ ] 🎯 预约 approver评论/approve，正式合入前的必要检查 - [ ] 📊 前冒烟 用例已全量通过 - [ ] 📦 新增功能已同步补充基本功能测试用例到前冒烟里 See merge request: cann/hcomm!5377 | 1 month ago | |
[fix]crcmap加锁 Co-authored-by: YantingLiu<liuyanting11@huawei.com> # message auto-generated for no-merge-commit merge: !5206 merge fix/rank-table-crc-bridge-lock into master [fix]crcmap加锁 Created-by: YantingLiu Commit-by: YantingLiu Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> RankTableCrcBridge 为进程级单例，多个通信域并发初始化时，不同线程可能同时调用 RecordRankTableJsonCrc() 和 ConsumeRankTableJsonCrc()。原实现无锁访问 rankTableJsonCrcMap_，并发执行插入、查找和删除会触发 std::unordered_map 数据竞争，概率性导致容器状态损坏，并在 ConsumeRankTableJsonCrc() 中发生 coredump。 本 PR 增加互斥锁保护： - RecordRankTableJsonCrc()：CRC 计算完成后，加锁写入 map。 - ConsumeRankTableJsonCrc()：锁内完成 find → 读取 → erase，保证消费操作的原子性。 - 不改变现有接口及 deviceLogicId → CRC 的存储语义。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [ ] 📋 其他，请描述： ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR不涉及Issue，可填写"NA"。--> NA ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于构造对应xx测试用例、二级冒烟、算子泛化等。--> 已完成的测试用例和场景： 1. ascend-dmi 原场景，反复测试无core无报错。 2. rdv 补充的UT用例： 分别覆盖两个场景： 1. 不同 device 并发 Record + Consume Ut_ConcurrentRecordAndConsumeDifferentDevices_ExpectExactCrc 32 个线程同时启动 验证点： - 即使 key 不同，多个线程仍在修改同一个 unordered_map。 - 覆盖并发插入、查找、删除以及可能的 rehash。 - 每个线程必须取回自己预先计算的 CRC，不能返回 0、丢失或串到其他 device 的 CRC。 - 对应现场 device12、device14 同时操作 CRC map 的场景。 2. 同一个 device 并发 Consume Ut_ConcurrentConsumeSameDevice_ExpectSingleConsumer 先执行： Record(device2000, CRC) 然后32个线程同时执行： Consume(device2000) 验证点： - Consume 中的 find -> 读取 -> erase 必须是一个原子过程。 - 只能有一个线程取得正确 CRC。 - 其余 31 个线程必须返回 0。 - 最后再次 Consume 也必须返回 0。 - 防止两个线程重复消费同一条记录，或者一个线程 erase 后另一个线程继续访问失效迭代器。 ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 合入检查 <!-- 在正式合入前，请做好必要的代码测试，用例补充，软件代码风格检查等。提高合入效率。--> <!-- [x] 表示选中 --> - [ ] 🧐 已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 - [ ] 🔍 邀请 committer评论 /lgtm前的必要检查 - [ ] 🏷️ 标题中使用了合适的类型标签（如：[feat], [fix]） - [ ] 📄 代码修改内容已简要描述，相关文档已更新 - [ ] 📝 代码注释已更新，代码遵循项目整体代码风格 - [ ] 🧪 代码UT测试已更新，覆盖率已达标 - [ ] 🔬 验证方法已更新到"测试"部分 - [ ] 🛠️ 代码已通过静态分析工具检查，无错误 - [ ] 👥 代码检视/code review/同行评议和必要的代码串讲，确保代码质量 - [ ] ✅ 代码检视意见已处理或答复，无未处理的检视意见 - [ ] 🚀 预约 前冒烟 用例前的必要检查 - [ ] ✔️ 代码已有committer的/lgtm 和 模块committer的/lgtm评论 - [ ] 🔧 代码已通过compile，编译无错误，无告警 - [ ] 🖥️ 代码已通过基本功能本地测试或者在线测试，确保基本功能正常 - [ ] 🎯 预约 approver评论/approve，正式合入前的必要检查 - [ ] 📊 前冒烟 用例已全量通过 - [ ] 📦 新增功能已同步补充基本功能测试用例到前冒烟里 See merge request: cann/hcomm!5206 | 1 month ago | |
[build] remove redundant header file search paths Co-authored-by: ouyangcaike<ouyangcaike@h-partners.com> # message auto-generated for no-merge-commit merge: !4920 merge build/head_search_path into master [build] remove redundant header file search paths Created-by: ouyangcaike Commit-by: ouyangcaike Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> 1. 展开原有LEGACY_ASCEND950_INCLUDE_LIST搜索路径表 2. 消除冗余头文件搜索路径 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [x] 📋 其他，请描述：工程 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR不涉及Issue，可填写"NA"。--> NA ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于构造对应xx测试用例、二级冒烟、算子泛化等。--> 已完成的测试用例和场景： 1. 编译通过 2. 全量拦截项通过 补充的UT用例： NA ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> NA ## 合入检查 <!-- 在正式合入前，请做好必要的代码测试，用例补充，软件代码风格检查等。提高合入效率。--> <!-- [x] 表示选中 --> - [x] 🧐 已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 - [x] 🔍 邀请 committer评论 /lgtm前的必要检查 - [x] 🏷️ 标题中使用了合适的类型标签（如：[feat], [fix]） - [x] 📄 代码修改内容已简要描述，相关文档已更新 - [x] 📝 代码注释已更新，代码遵循项目整体代码风格 - [x] 🧪 代码UT测试已更新，覆盖率已达标 - [x] 🔬 验证方法已更新到"测试"部分 - [x] 🛠️ 代码已通过静态分析工具检查，无错误 - [x] 👥 代码检视/code review/同行评议和必要的代码串讲，确保代码质量 - [x] ✅ 代码检视意见已处理或答复，无未处理的检视意见 - [x] 🚀 预约 前冒烟 用例前的必要检查 - [x] ✔️ 代码已有committer的/lgtm 和 模块committer的/lgtm评论 - [x] 🔧 代码已通过compile，编译无错误，无告警 - [x] 🖥️ 代码已通过基本功能本地测试或者在线测试，确保基本功能正常 - [x] 🎯 预约 approver评论/approve，正式合入前的必要检查 - [x] 📊 前冒烟 用例已全量通过 - [x] 📦 新增功能已同步补充基本功能测试用例到前冒烟里 See merge request: cann/hcomm!4920 | 2 months ago |
| Files | Last commit | Last update |
|---|---|---|
| 1 month ago | ||
| 1 month ago | ||
| 1 month ago | ||
| 2 months ago |