| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
【feat】【HCOMM仓】【A5】基础通信层支持进程级资源统一管理（A5新老流程单例管理） Co-authored-by: xijianfei<xijianfei@huawei.com> Co-authored-by: gaoshuai3011<gaoshuai12@huawei.com> # message auto-generated for no-merge-commit merge: !5433 merge br_hccl_gs0907 into master 【feat】【HCOMM仓】【A5】基础通信层支持进程级资源统一管理（A5新老流程单例管理） Created-by: gaoshuai3011 Commit-by: gaoshuai3011;xijianfei Merged-by: cann-robot Description: ## 描述 修改补充： aicpu_ts_hccs_channel.cc TransportInit：new (std::nothrow) 后补 CHK_SMART_PTR_NULL 判空，防 O 时空指针解引用； ccu_conn.cc Describe：reqHandles_ 空池防护（empty() ? 0 : front()），防请求池回收为空后越界访问。 ## 背景与问题 base_comm 的资源生命周期长期由约 39 个互不相识的散落单例/全局变量分管（函数级 static / Meyers 单例）。 C++ 静态对象按"构造完成的逆序"析构，而首触时机取决于运行时业务路径——**同一份代码， 析构顺序随运行路径漂移**，进程退出期因此存在概率性 coredump：endpoint 析构链回调 EndpointCtxMgr 释放 ctx、归还 CCU 与网卡上下文时，被依赖的资源管理器可能已先析构 （僵尸对象访问）。该问题复现难、定位难（崩溃构链上，与业务调用对不上）。 ## 方案 将散落单例收敛为一棵**进程级资源树**，把析构顺序从"运行时碰运气"变为"编译期显式契约"： - **单根**： BaseCommMgr 为唯一 Meyers 单例树根；其余资源收编为树节点的值成员 （值成员组合为主，unique_ptr 仅用于运行时数量不定的设备子树表与 endpoint 句柄表）； - **声明序 = 析构契约**：先声明的后死。EndpointMgr 全树最先死（其析构链回调设备子树 与网络资源时它们必须存活），基础设施与 legacy 锚定- **粒度分层**：进程级（树根直属）→ 设备级（每物理卡一棵子树，首访懒建、构造即锚定）； 实例级（per-endpoint 子树）降为二期（依赖 #759 的 EndpointDesc 键）； - **生命周期双路径**：DeInit(ExitProfile) 管动作（按契约序清理、幂等），析构管内存 （未显式 DeInit 时析构先走一遍 DeInit 链兜底）；双 profile——GRACEFUL 完整动作链 （默认），RESET 跳过触设备动作（设备热复位场景预留，当前无业务调用方）； - **跨二进制搬不动的 legacy950 单例只锚定不入树**：由锚定节点构造时按依赖序首触， C++ 静态析构逆序锁死其晚于全树死亡； - **调用点一律走窄访问器**（base_comm_node_accessors.h），保证树根构造与锚定早于 一切业务首触； ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [x] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [ ] 📋 其他，请描述： ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR不涉及Issue，可填写"NA"。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于构造对应xx测试用例、二级冒烟、算子泛化等。--> 已完成的测试用例和场景： 1. 黄区、蓝区RDV 2. 上板环境联调 3. checker 补充的UT用例： ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> 新增了src/base_comm/README.md文件 ## 合入检查 <!-- 在正式合入前，请做好必要的代码测试，用例补充，软件代码风格检查等。提高合入效率。--> <!-- [x] 表示选中 --> - [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!5433 | 9 天前 | |
【feat】【HCOMM仓】【A5】基础通信层支持进程级资源统一管理（A5新老流程单例管理） Co-authored-by: xijianfei<xijianfei@huawei.com> Co-authored-by: gaoshuai3011<gaoshuai12@huawei.com> # message auto-generated for no-merge-commit merge: !5433 merge br_hccl_gs0907 into master 【feat】【HCOMM仓】【A5】基础通信层支持进程级资源统一管理（A5新老流程单例管理） Created-by: gaoshuai3011 Commit-by: gaoshuai3011;xijianfei Merged-by: cann-robot Description: ## 描述 修改补充： aicpu_ts_hccs_channel.cc TransportInit：new (std::nothrow) 后补 CHK_SMART_PTR_NULL 判空，防 O 时空指针解引用； ccu_conn.cc Describe：reqHandles_ 空池防护（empty() ? 0 : front()），防请求池回收为空后越界访问。 ## 背景与问题 base_comm 的资源生命周期长期由约 39 个互不相识的散落单例/全局变量分管（函数级 static / Meyers 单例）。 C++ 静态对象按"构造完成的逆序"析构，而首触时机取决于运行时业务路径——**同一份代码， 析构顺序随运行路径漂移**，进程退出期因此存在概率性 coredump：endpoint 析构链回调 EndpointCtxMgr 释放 ctx、归还 CCU 与网卡上下文时，被依赖的资源管理器可能已先析构 （僵尸对象访问）。该问题复现难、定位难（崩溃构链上，与业务调用对不上）。 ## 方案 将散落单例收敛为一棵**进程级资源树**，把析构顺序从"运行时碰运气"变为"编译期显式契约"： - **单根**： BaseCommMgr 为唯一 Meyers 单例树根；其余资源收编为树节点的值成员 （值成员组合为主，unique_ptr 仅用于运行时数量不定的设备子树表与 endpoint 句柄表）； - **声明序 = 析构契约**：先声明的后死。EndpointMgr 全树最先死（其析构链回调设备子树 与网络资源时它们必须存活），基础设施与 legacy 锚定- **粒度分层**：进程级（树根直属）→ 设备级（每物理卡一棵子树，首访懒建、构造即锚定）； 实例级（per-endpoint 子树）降为二期（依赖 #759 的 EndpointDesc 键）； - **生命周期双路径**：DeInit(ExitProfile) 管动作（按契约序清理、幂等），析构管内存 （未显式 DeInit 时析构先走一遍 DeInit 链兜底）；双 profile——GRACEFUL 完整动作链 （默认），RESET 跳过触设备动作（设备热复位场景预留，当前无业务调用方）； - **跨二进制搬不动的 legacy950 单例只锚定不入树**：由锚定节点构造时按依赖序首触， C++ 静态析构逆序锁死其晚于全树死亡； - **调用点一律走窄访问器**（base_comm_node_accessors.h），保证树根构造与锚定早于 一切业务首触； ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [x] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [ ] 📋 其他，请描述： ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR不涉及Issue，可填写"NA"。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于构造对应xx测试用例、二级冒烟、算子泛化等。--> 已完成的测试用例和场景： 1. 黄区、蓝区RDV 2. 上板环境联调 3. checker 补充的UT用例： ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> 新增了src/base_comm/README.md文件 ## 合入检查 <!-- 在正式合入前，请做好必要的代码测试，用例补充，软件代码风格检查等。提高合入效率。--> <!-- [x] 表示选中 --> - [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!5433 | 9 天前 | |
[fix] 允许hcomm.cfg多QP端口列表为空 Co-authored-by: qq_45577430<liuhongming4@huawei.com> # message auto-generated for no-merge-commit merge: !6466 merge fix/host-multi-qp-empty-ports into master [fix] 允许hcomm.cfg多QP端口列表为空 Created-by: qq_45577430 Commit-by: qq_45577430 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> 改动原因：支持配置多 QP 模式和 QP 数量，同时不指定 UDP 源端口。 改动方法： 1. 允许 multi_qp_udp_ports_<phyId> 配置项存在但值为空，保留三个配置项的存在性检查。 2. 非空端口列表继续校验，非法配置仍报错拦截。 3. 拆分 QP count 与端口校验，分别记录错误日志。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [x] 📋 其他，请描述： ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR不涉及Issue，可填写"NA"。--> NA ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于构造对应xx测试用例、二级冒烟、算子泛化等。--> 补充的UT用例： - ut_host_multi_qp_config.cc：覆盖空值、空白值及文件覆盖环境变量、非法非空端口、配置项缺失，以及空端口时 mode/count 非法。 ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 合入检查 <!-- 在正式合入前，请做好必要的代码测试，用例补充，软件代码风格检查等。提高合入效率。--> <!-- [x] 表示选中 --> - [x] 🧐 已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 - [x] 🔍 邀请 committer评论 /lgtm前的必要检查 - [x] 🏷️ 标题中使用了合适的类型标签（如：[feat], [fix]） - [x] 📄 代码修改内容已简要描述，相关文档已更新 - [x] 📝 代码注释已更新，代码遵循项目整体代码风格 - [x] 🧪 代码UT测试已更新，覆盖率已达标 - [x] 🔬 验证方法已更新到"测试"部分 - [x] 🛠️ 代码已通过静态分析工具检查，无错误 - [x] 👥 代码检视/code review/同行评议和必要的代码串讲，确保代码质量 - [x] ✅ 代码检视意见已处理或答复，无未处理的检视意见 - [x] 🚀 预约 前冒烟 用例前的必要检查 - [ ] ✔️ 代码已有committer的/lgtm 和 模块committer的/lgtm评论 - [ ] 🔧 代码已通过compile，编译无错误，无告警 - [ ] 🖥️ 代码已通过基本功能本地测试或者在线测试，确保基本功能正常 - [ ] 🎯 预约 approver评论/approve，正式合入前的必要检查 - [ ] 📊 前冒烟 用例已全量通过 - [ ] 📦 新增功能已同步补充基本功能测试用例到前冒烟里 See merge request: cann/hcomm!6466 | 5 小时前 | |
[feat] rename UB protocol enums with backward compatibility Co-authored-by: z00940303<zhangzhuopan@huawei.com> # message auto-generated for no-merge-commit merge: !4370 merge master into master [feat] rename UB protocol enums with backward compatibility Created-by: zhangzhuopan Commit-by: z00940303 Merged-by: cann-robot Description: ## 描述 本次修改统一 UB 协议枚举命名，使协议名称与当前架构定义保持一致： - 新增 COMM_PROTOCOL_UB_CTP = 4，替代原有命名 COMM_PROTOCOL_UBC_CTP。 - 新增 COMM_PROTOCOL_UB_RTP = 9，替代原有命名 COMM_PROTOCOL_UBG。 - 保留旧枚举作为兼容别名： - COMM_PROTOCOL_UBC_CTP = COMM_PROTOCOL_UB_CTP - COMM_PROTOCOL_UBG = COMM_PROTOCOL_UB_RTP - 枚举数值保持不变，确保已有调用方的源码兼容性和接口 ABI 不受影响。 - 将 Endpoint、Channel、通信域资源管理、拓扑转换、NIC Plugin 等代码中的协议判断和日志统一为新名称。 - 在 AIV/AICPU 通信路径中补充并保留 UB_RTP 处理： - AIV + UB_RTP 使用 AivUrmaChannel。 - AICPU/AICPU_TS + UB_RTP 使用 AicpuTsUbgChannel。 - 支持 UB_RTP 的 Device ChannelEntity 创建、预分配及 Device Handle 转换。 - 更新相关中英文接口文档和通信算子开发文档，将旧协议名称替换为新协议名称。 ## 变更类型 请选择本次引入的变更类型： - [ ] 🐛 Bug修复 - [x] ✨ 新特性 - [ ] 🚀 性能优化 - [x] 📝 文档更新 - [ ] 📋 其他，请描述： ## 关联的Issue NA ## 测试 已完成的测试用例和场景： 1. 检查 COMM_PROTOCOL_UB_CTP 和 COMM_PROTOCOL_UB_RTP 在 Endpoint、Channel 创建、资源转换及拓扑映射等路径中的处理逻辑。 2. 检查 AIV/AICPU 场景下 UB_RTP Channel 创建及 Device ChannelEntity 转换流程，确认主线已有的 AIV 直驱 URMA 适配未在冲突解决过程中丢失。 3. 执行代码静态检查，确认无残留冲突标记，git diff --check 检查通过。 补充的UT用例： - 补充新旧协议枚举兼容性校验： - COMM_PROTOCOL_UBC_CTP == COMM_PROTOCOL_UB_CTP - COMM_PROTOCOL_UBG == COMM_PROTOCOL_UB_RTP - 更新 Endpoint、协议转换、NIC Plugin 等相关 UT，使其使用新的 UB_CTP、UB_RTP 协议名称。 已通过 A3、A5 RDV用例 ## 文档更新 更新了以下文档中的协议名称及说明： - CommProtocol 数据类型定义文档。 - HcommChannelCreate、HcommEndpointCreate 和 HcclChannelAcquire 接口文档。 - Hcomm Read、Write、Fence 等通信操作接口文档。 - CCU 通信算子开发指南及快速入门文档。 - NIC Plugin 中英文 README。 文档中将 UBC_CTP、UBG 分别更新为 UB_CTP、UB_RTP，同时保留旧枚举名称的兼容性说明。 ## 合入检查 <!-- 在正式合入前，请做好必要的代码测试，用例补充，软件代码风格检查等。提高合入效率。--> <!-- [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!4370 | 2 个月前 | |
【feat】base_comm提供边界目录给coll_comm使用 Co-authored-by: BenjaminKk<xieyukun1@huawei.com> Co-authored-by: zjw22<zhujiawei29@huawei.com> Co-authored-by: zzzdddhhh22<zhaodehan@huawei.com> # message auto-generated for no-merge-commit merge: !5577 merge 930_1 into master 【feat】base_comm提供边界目录给coll_comm使用 Created-by: zjw22 Commit-by: zjw22;BenjaminKk;zzzdddhhh22 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> ### 背景 base_comm 内部实现头（resources/**、dfx/**、primitives/**、common/** 等）被 coll_communicator_mgr、legacy、测试以裸头名直接 #include，边界不清、内部类型外泄、跨模块强耦合，且 base_comm 反向依赖了 L2 的 comm_addr_logger、ccuTaskException，违反「上层依赖下层、下层不反向依赖」的分层约束。 ### 采取的方法 1. **新增边界目录 src/base_comm/inc/**：新增 20 个 *_pub.h（ccu/6、comm/4+comm/debug/1、dfx/3、channel/2、endpoint/1、thread/1+thread/aicpu/2），并将 base_comm 内部 21 个需对外暴露的头整体重命名/迁移到 inc/ 下（原位置改为转发 shim 或直接迁移），头保护宏统一为 HCOMM_ 前缀。inc/ 下最终共 41 个 _pub.h。 2. **消除反向依赖**：将 coll_communicator_mgr/common/loggers/comm_addr_logger.{h,cc} 下沉到 base_comm/common/、ccuTaskException.{h,cc} 下沉到 base_comm/resources/ccu/ccu_dfx/。 3. **编译隔离**：新增 src/coll_communicator_mgr/hcomm_coll_comm.cmake，定义 OBJECT 库 hcomm_coll_comm_obj（显式 include 白名单）并链入 hcomm；顶层 CMakeLists.txt 与 cmake/device/CMakeLists.txt 全局声明 src/base_comm/inc；约 30 个 coll 子目录 CMake 由 hcomm 切到 hcomm_coll_comm_obj，并清理重复/冗余 include（ccl_kernel.cmake、hcomm.cmake、hcomm_base_obj.cmake、nic_plugin 等）。 4. **门面化/回调解耦**：新增 ccuTaskExceptionAdpt.cc（L2 注册 CCU 任务异常回调，使 base_comm 解码不依赖 L2 CollComm/HcclCommunicator/RankGraph）、AicpuThreadLaunchMgr（承接 AicpuLaunchMgr，仅 base_comm 内部使用）、channel_map_registry.h；线程公开 C API HcommThreadCreateAicpu/GetStreamLite/RegisterCacheCallback/Destroy 等；CCU 新增 QueryCcuInstanceEntity/CcuInstanceExists；通道新增 HcommChannelBuildDeviceEntity 等。 5. **include 路径统一**：全仓改为边界相对路径（comm/、ccu/、thread/、dfx/、endpoint/、config/、comm_engine_res/ 等）。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [x] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [ ] 📋 其他，请描述： ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR不涉及Issue，可填写"NA"。--> NA ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于构造对应xx测试用例、二级冒烟、算子泛化等。--> 已完成的测试用例和场景： 1. bash build.sh --pkg --full：主机侧 + device 侧全量编译通过，无 error。 2. bash build.sh --ut --st：UT/ST 目标全量编译通过，边界头、门面接口（线程/通道/CCU）、CCU 任务异常回调相关用例回归通过。 3. checker: CCU_SCHED  AICPU  AIV  补充的UT用例： - 同步更新门面化接口与桩：ut_thread_aicpu_mgr、ut_engine_aicpu_interface、ut_hcclCommTaskExceptionLite、ut_coll_comm_res_c_adpt、llt_next_orion_stub 等（新增 HcommThreadCreateAicpu/GetStreamLite/Destroy/RegisterCacheCallback 桩）。 ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> - 随头文件迁移同步更新 src/coll_communicator_mgr/dfx/taskException/taskException.md 等模块说明。 ## 合入检查 <!-- 在正式合入前，请做好必要的代码测试，用例补充，软件代码风格检查等。提高合入效率。--> <!-- [x] 表示选中 --> - [x] 🧐 已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 - [x] 🔍 邀请 committer评论/lgtm前的必要检查 - [x] 🏷️ 标题中使用了合适的类型标签（如：[feat], [fix]） - [x] 📄 代码修改内容已简要描述，相关文档已更新 - [x] 📝 代码注释已更新，代码遵循项目整体代码风格 - [x] 🧪 代码UT测试已更新，覆盖率已达标 - [x] 🔬 验证方法已更新到"测试"部分 - [x] 🛠️ 代码已通过静态分析工具检查，无错误 - [ ] 👥 代码检视/code review/同行评议和必要的代码串讲，确保代码质量 - [ ] ✅ 代码检视意见已处理或答复，无未处理的检视意见 - [ ] 🚀 预约 前冒烟 用例前的必要检查 - [ ] ✔️ 代码已有committer的/lgtm 和 模块committer的/lgtm评论 - [ ] 🔧 代码已通过compile，编译无错误，无告警 - [ ] 🖥️ 代码已通过基本功能本地测试或者在线测试，确保基本功能正常 - [ ] 🎯 预约 approver评论/approve，正式合入前的必要检查 - [ ] 📊 前冒烟 用例已全量通过 - [ ] 📦 新增功能已同步补充基本功能测试用例到前冒烟里 See merge request: cann/hcomm!5577 | 10 天前 | |
【feat】【HCOMM仓】【A5】基础通信层支持进程级资源统一管理（A5新老流程单例管理） Co-authored-by: xijianfei<xijianfei@huawei.com> Co-authored-by: gaoshuai3011<gaoshuai12@huawei.com> # message auto-generated for no-merge-commit merge: !5433 merge br_hccl_gs0907 into master 【feat】【HCOMM仓】【A5】基础通信层支持进程级资源统一管理（A5新老流程单例管理） Created-by: gaoshuai3011 Commit-by: gaoshuai3011;xijianfei Merged-by: cann-robot Description: ## 描述 修改补充： aicpu_ts_hccs_channel.cc TransportInit：new (std::nothrow) 后补 CHK_SMART_PTR_NULL 判空，防 O 时空指针解引用； ccu_conn.cc Describe：reqHandles_ 空池防护（empty() ? 0 : front()），防请求池回收为空后越界访问。 ## 背景与问题 base_comm 的资源生命周期长期由约 39 个互不相识的散落单例/全局变量分管（函数级 static / Meyers 单例）。 C++ 静态对象按"构造完成的逆序"析构，而首触时机取决于运行时业务路径——**同一份代码， 析构顺序随运行路径漂移**，进程退出期因此存在概率性 coredump：endpoint 析构链回调 EndpointCtxMgr 释放 ctx、归还 CCU 与网卡上下文时，被依赖的资源管理器可能已先析构 （僵尸对象访问）。该问题复现难、定位难（崩溃构链上，与业务调用对不上）。 ## 方案 将散落单例收敛为一棵**进程级资源树**，把析构顺序从"运行时碰运气"变为"编译期显式契约"： - **单根**： BaseCommMgr 为唯一 Meyers 单例树根；其余资源收编为树节点的值成员 （值成员组合为主，unique_ptr 仅用于运行时数量不定的设备子树表与 endpoint 句柄表）； - **声明序 = 析构契约**：先声明的后死。EndpointMgr 全树最先死（其析构链回调设备子树 与网络资源时它们必须存活），基础设施与 legacy 锚定- **粒度分层**：进程级（树根直属）→ 设备级（每物理卡一棵子树，首访懒建、构造即锚定）； 实例级（per-endpoint 子树）降为二期（依赖 #759 的 EndpointDesc 键）； - **生命周期双路径**：DeInit(ExitProfile) 管动作（按契约序清理、幂等），析构管内存 （未显式 DeInit 时析构先走一遍 DeInit 链兜底）；双 profile——GRACEFUL 完整动作链 （默认），RESET 跳过触设备动作（设备热复位场景预留，当前无业务调用方）； - **跨二进制搬不动的 legacy950 单例只锚定不入树**：由锚定节点构造时按依赖序首触， C++ 静态析构逆序锁死其晚于全树死亡； - **调用点一律走窄访问器**（base_comm_node_accessors.h），保证树根构造与锚定早于 一切业务首触； ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [x] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [ ] 📋 其他，请描述： ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR不涉及Issue，可填写"NA"。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于构造对应xx测试用例、二级冒烟、算子泛化等。--> 已完成的测试用例和场景： 1. 黄区、蓝区RDV 2. 上板环境联调 3. checker 补充的UT用例： ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> 新增了src/base_comm/README.md文件 ## 合入检查 <!-- 在正式合入前，请做好必要的代码测试，用例补充，软件代码风格检查等。提高合入效率。--> <!-- [x] 表示选中 --> - [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!5433 | 9 天前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 9 天前 | ||
| 9 天前 | ||
| 5 小时前 | ||
| 2 个月前 | ||
| 10 天前 | ||
| 9 天前 |