| Files | Last commit | Last update |
|---|---|---|
[clean]修改不符合规范的头文件 Co-authored-by: LQ_OY<ouyangzhikang@huawei.com> # message auto-generated for no-merge-commit merge: !4954 merge unmeaningfulHeadFile into master [clean]修改不符合规范的头文件 Created-by: LQ_OY Commit-by: LQ_OY Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> 该PR主要解决头文件重名（重名头文件）问题：将unified_platform/pub_inc/下的config_plf_log.h重命名为config_plf_log_v2.h,并同步更新其头文件保护宏，同时将全部引用该头文件的路径统一修改为引用config_plf_log_v2.h;此外还删除了重复的定义whitelist。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [x] 📋 其他，请描述：告警修复，修改不符合规范的头文件 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR不涉及Issue，可填写"NA"。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于构造对应xx测试用例、二级冒烟、算子泛化等。--> 已完成的测试用例和场景： 1. 2. 补充的UT用例：不涉及 ## 文档更新 <!--如果这个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!4954 | 2 months ago | |
[fix] fix AICPU thread notify allocation Co-authored-by: ganglei123<zhaoganglei@huawei.com> # message auto-generated for no-merge-commit merge: !4795 merge fix/aicpu-thread-host-notify into master [fix] fix AICPU thread notify allocation Created-by: ganglei123 Commit-by: ganglei123 Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> 修复 AicpuTsThread::SupplementNotify 扩容后末尾 notify 未初始化、可能产生空指针的问题。 - HCOMM 不再为 A5 AICPU Thread 隐式增加 notify，申请数量严格与 HCCL 传入数量一致。 - AICPU Thread 统一使用 HOST_NOTIFY，用于卡内流同步。 - 两个补充路径均从末尾直接初始化新增 notify，不再移动已有元素，保持原索引不变。 - 补充 A3/A5、Host/Device 侧 UT，验证数量、非空及索引稳定性。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [ ] 📋 其他，请描述： ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR不涉及Issue，可填写"NA"。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于构造对应xx测试用例、二级冒烟、算子泛化等。--> 已完成的测试用例和场景： 1.上板测试，报错用例已通过 2. 新增/更新 UT 覆盖： Ut_AicpuTsThread_SupplementNotify_On_A3_When_Normal_Expect_AppendAllNotifies Ut_AicpuTsThread_SupplementNotify_On_A5_When_Normal_Expect_AppendAllNotifies Ut_NotifyLoadType_When_AicpuEngine_Expect_HostNotify ## 文档更新 <!--如果这个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!4795 | 2 months ago | |
hostcpuroce、urma支持drain Co-authored-by: YantingLiu<liuyanting11@huawei.com> # message auto-generated for no-merge-commit merge: !4667 merge hostcpurocedrain into master hostcpuroce、urma支持drain Created-by: YantingLiu Commit-by: YantingLiu Merged-by: cann-robot Description: ## 描述 ### 背景 HcommChannelDrainOnThread 用于阻塞等待 Channel 上调用前已经提交的通信任务完成。 Host CPU内置 Channel 虽然维护了待完成 WQE 数量，但未实现独立的 Drain 能力，调用时返回不支持。 Host CPU已有的 ChannelFence 会等待 WQE 完成并设置 fenceFlag_，用于约束后续通信任务的执行顺序。Drain 与 Fence 语义不同： - Drain：仅等待调用前已经提交的任务完成，不设置 Fence 标记。 - Fence：等待已有任务完成，并设置 Fence 标记，为后续任务增加保序约束。 ### 修改方案 1. 为内部 Channel 基类增加 ChannelDrain() 虚函数，默认返回 HCCL_E_NOT_SUPPORT。 2. 为以下Host CPU Channel实现Drain： - HostCpuRoceChannel - HostCpuUrmaChannel Drain复用Channel已有的WQE完成轮询逻辑，等待待完成WQE数量归零，但不修改fenceFlag_。 3. 将RoCE和URMA中原有Fence等待逻辑抽取为内部公共等待函数： - ChannelFence()：等待WQE完成后设置fenceFlag_。 - ChannelDrain()：只等待WQE完成。 原有Fence语义保持不变。 4. 补充HcommChannelDrainOnThread的Host CPU分发： - 插件Channel继续通过nicOps->drainOnThread()分发，原有插件行为不变。 - Host CPU内置Channel通过Builtin NIC Ops调用Channel::ChannelDrain()。 - AICPU/legacy Transport场景继续调用HcclRemoteDrain()，原有路径不变。 5. 增加Drain入口、成功及失败日志，便于定位阻塞等待和异常返回。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [ ] 📋 其他，请描述： ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR不涉及Issue，可填写"NA"。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于构造对应xx测试用例、二级冒烟、算子泛化等。--> 已完成的测试用例和场景： 1. 上板验证：hixl h2d打流验证；hccl allgather reduce nhr等打流验证 2. rdv 补充的UT用例： ## 文档更新 <!--如果这个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!4667 | 2 months ago | |
[feat] hcomm endpoint refactor Co-authored-by: guoziqi2025<guoziqi2@huawei.com> # message auto-generated for no-merge-commit merge: !4658 merge endpoint_refactor into master [feat] hcomm endpoint refactor Created-by: guoziqi2025 Commit-by: guoziqi2025 Merged-by: cann-robot Description: ## 描述 本 PR 对 base_comm 的 Endpoint/RegedMemMgr 类层次做**公共流程抽取归一**内部重构：将"基类持有数据成员 + 继承复用"模型重构为"纯虚接口 + 组合"模型。对外 C 接口（ include/hcomm_res.h）签名不变，运行行为与重构前对齐。 **改动原因**（重构前的四类问题）： 1. **冗余**：6 个 endpoint 子类各自重复实现 6 个内存注册方法的一行转发（38 处、约 245 行） 2. **抽象不彻底**：Endpoint/RegedMemMgr 基类同时承担接口契约与数据成员持有；AicpuTsHccs 存在 8 处向下强转 3. **资源管理分散**：endpoint 句柄表为全局静态、不受 HcommResMgr 管理，进程销毁无兜底清理 4. **能力耦合**：监听/jetty/NIC 插件能力挂在 Endpoint 接口上，非持有方被迫实现空 stub **核心改动**： 1. **Endpoint 纯虚接口化**：ctxHandle_/regedMemMgr_/缓存成员等全部下放各派生类私有；内存注册接口从 Endpoint 移除（统一经 GetRegedMemMgr() 访问）；各子类 regedMemMgr_ 声明为具体 RegedMemMgr 子类类型并在 Init 构造（消除 8 处 dynamic_cast 强转） 2. **RegedMemMgr 纯虚接口化**：rdmaHandle_/memMtx_ 下放派生类私有、改为构造注入 3. **新增 ServerSocketContext 体系**（resources/endpoints/server_socket_context/，按类一文件）：抽象基类 + Host/Device/AicpuTsRoce/AicpuTsHccs/UbRtpUboe 五个路径子类 + 插件路径 PluginServerSocketContext（nic_plugin_holder.h 内）；监听三接口从 Endpoint 移除，统一经 GetServerSocketContext() 访问（AicpuTsRoce 的 HcclSocket 自管理/静态 map + refCount 复用、AicpuTsHccs 的 GlobalNetDevMgr 路径整体迁入） 4. **新增 EndpointMgr**（endpoint_mgr/）：收编原全局 endpoint 句柄表；EndpointCtx 按 {devPhyId, LinkProtoType, ip} 去重，多 endpoint 实例共享同一底层 RDMA 句柄（AcquireEndpointCtxByAddr/ByEid 出参接口 + ReleaseEndpointCtx 共享引用计数判定 + victim 模式锁外析构）；~HcommResMgr() 兜底 DeInit 释放残留；作为 HcommResMgr 成员持有 5. **NIC 插件路径归一**：nicOps_/nicCtx_ 移入 PluginEndpointHolder；PluginRegedMemMgr（内存五接口转发）、PluginServerSocketContext（getListenPort 转发）承载插件能力 6. **删除 UboeUbRtpEndpointHelper 中间继承层**；coll_communicator_mgr 侧同名 EndpointMgr 命名空间 hcomm→hccl 消除冲突 7. C 适配层统一经 HcommResMgr::GetInstance().GetEndpointMgr() 路由（句柄查找失败返回 HCCL_E_NOT_FOUND）；指针入参判空校验下沉至各派生类接口入口（插件路径除外，由插件侧自负）；HcommResMgrInit/RefreshEndpointContext 保持原有调用副作用 ## 变更类型 请选择本次引入的变更类型： - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [x] 📋 其他，请描述：内部重构（接口与实现分离、公共流程归一；对外 C API 签名不变、行为对齐重构前） ## 关联的Issue NA ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于构造对应xx测试用例、二级冒烟、算子泛化等。--> 已完成的测试用例和场景： 1. pkg 全量编译通过（x86_64，0 error，endpoint 相关无 warning） 2. UT & ST 通过 3. HCOMM仓RDV验证通过 4. aiv共享jetty功能验证通过 5. 单边通信验证通过 补充的UT用例： - ut_hcomm_endpoint_mgr.cc：EndpointMgr 的 Add/Remove/Update/Get、Acquire 去重（同 key 共享、use_count 递增）、Release 共享判定、DeInit 兜底清理 - ut_endpoint_ctx.cc：EndpointCtx/EndpointCtxKey - ut_server_socket_context.cc：五路径子类的监听行为、析构兜底停止监听、no-op 语义、继承基类默认 NOT_SUPPORT - ut_plugin_reged_mem_mgr.cc：插件内存五接口转发 + GetListenPort 转发 - 既有 endpoint/channel UT 全量适配新接口（Init 签名、具体类型 mgr、stub 派生类等） ## 文档更新 NA（纯代码重构，无对外接口与文档变更） ## 合入检查 <!-- 在正式合入前，请做好必要的代码测试，用例补充，软件代码风格检查等。提高合入效率。--> - [x] 🧐 已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 - [x] 🔍 邀请 committer评论/lgtm前的必要检查 - [x] 🏷️ 标题中使用了合适的类型标签（如：[feat], [fix]） - [x] 📄 代码修改内容已简要描述，相关文档已更新 - [x] 📝 代码注释已更新，代码遵循项目整体代码风格 - [x] 🧪 代码UT测试已更新，覆盖率已达标 - [x] 🔬 验证方法已更新到"测试"部分 - [x] 🛠️ 代码已通过静态分析工具检查，无错误 - [x] 👥 代码检视/code review/同行评议和必要的代码串讲，确保代码质量 - [x] ✅ 代码检视意见已处理或答复，无未处理的检视意见 - [ ] 🚀 预约 前冒烟 用例前的必要检查 - [ ] ✔️ 代码已有committer的/lgtm 和 模块committer的/lgtm评论 - [ ] 🔧 代码已通过compile，编译无错误，无告警 - [ ] 🖥️ 代码已通过基本功能本地测试或者在线测试，确保基本功能正常 - [ ] 🎯 预约 approver评论/approve，正式合入前的必要检查 - [ ] 📊 前冒烟 用例已全量通过 - [ ] 📦 新增功能已同步补充基本功能测试用例到前冒烟里 See merge request: cann/hcomm!4658 | 2 months ago | |
[feat] 支持peer模式hccp读取host侧配置文件 Co-authored-by: LQ_OY<ouyangzhikang@huawei.com> # message auto-generated for no-merge-commit merge: !4885 merge feature/hccp_peer_multi_qp_config_query into master [feat] 支持peer模式hccp读取host侧配置文件 Created-by: LQ_OY Commit-by: LQ_OY Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> 改动原因： peer（host 网卡，nicDeployment=ONLINE）场景下，HCCL 通过 dlsym 调用 HCCP 的 RaGetHccnCfg 读取 Host 侧配置。原实现入口会拒绝非 offline 模式，且 Host 侧配置文件（/etc/hcomm.cfg）与 Device 侧配置文件（/etc/hccl.cfg）路径不同，导致 peer 模式无法读取 Host 侧配置。底层 FileReadCfg 已具备文件读取及 key 匹配能力，ra_peer 也已链接 rs，当前缺少 peer 模式调用分支以及根据 mode 选择配置文件路径的逻辑。 改动方法： 1. RaGetHccnCfg 由“非 offline 模式直接拒绝”调整为三个分支：NETWORK_PEER_ONLINE 调用新增的 RaPeerGetHccnCfg；NETWORK_OFFLINE 保持原有 HDC 链路；其他 mode 按 -ENOTSUPP 语义转换后返回不支持错误。 2. ra_peer 新增 RaPeerGetHccnCfg：从传入的 RaInfo 获取 phyId；按既有调用方式执行 RaPeerMutexLock 和 RsSetCtx；将传入的 RaInfo、key、value 和 valueLen 原样传递给 RsGetHccnCfg；调用完成后解锁并返回 RsGetHccnCfg 的结果。 3. RsGetHccnCfg 的入参由 phyId 扩展为 RaInfo（包含 mode 和 phyId），并根据 mode 选择配置文件：NETWORK_OFFLINE 读取 /etc/hccl.cfg；NETWORK_PEER_ONLINE 读取 /etc/hcomm.cfg；其他 mode 返回 -ENOTSUPP。文件读取及 key 匹配继续复用 FileReadCfg，peer 和 offline 模式对各配置 key 保持相同的读取语义，offline 模式原有行为保持不变。 4. 适配层 gRaRsOps.getHccnCfg 的函数指针签名同步更新。Device 侧 HDC 请求到达 RaRsGetHccnCfg 后，以 mode=NETWORK_OFFLINE 和请求中的 phyId 构造 RaInfo，再调用 RsGetHccnCfg，保证原有 Device 侧 HDC 链路行为不变。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [x] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [ ] 📋 其他，请描述： ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于构造对应xx测试用例、二级冒烟、算子泛化等。--> 已完成的测试用例和场景： 1. peer-online 模式能够从 Host 侧 /etc/hcomm.cfg 按物理卡号读取 multi_qp_count。 2. 卡 0 和卡 1 的配置隔离正确，分别读取到 4 和 8。 3. 配置文件不存在时返回成功及空值，行为符合当前实现预期。 4. 配置文件存在但目标字段不存在时返回成功及空值，行为符合当前实现预期。 5. 三类场景中均未出现崩溃，初始化和反初始化流程正常。 补充的UT用例： 1.tc_ra_peer.c（TcRaPeerGetHccnCfg，新增用例并注册到 ut_test.cc）： 初始化 peer 后查询成功；通过 stub 捕获 RsGetHccnCfg 入参，校验 mode=NETWORK_PEER_ONLINE、phyId 和 key 透传正确，并校验不同 key 对应的 value 与 valueLen 返回正确。 2.tc_ut_rs.c（TcRsGetHccnCfg）： info 为 NULL 返回 -EINVAL；mode=NETWORK_ONLINE 返回 -ENOTSUPP；校验 NETWORK_OFFLINE 读取 /etc/hccl.cfg、NETWORK_PEER_ONLINE 读取 /etc/hcomm.cfg；通过五参数 stub 校验 filePath、keyName、devId、输入缓冲区长度、返回值、value 与 valueLen。 3.tc_rdma_agent.c（TcRaGetHccnCfg）： 补充 NETWORK_PEER_ONLINE 分支验证，通过 stub 返回确定的配置内容，校验查询成功、value 与 valueLen 正确；校验不支持的 mode 返回转换后的 -ENOTSUPP 错误码。 4.stub/rs.c： RsGetHccnCfg 桩函数同步新的 RaInfo 入参签名。 ## 合入检查 <!-- 在正式合入前，请做好必要的代码测试，用例补充，软件代码风格检查等。提高合入效率。--> <!-- [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!4885 | 2 months ago | |
[feat] hcomm endpoint refactor Co-authored-by: guoziqi2025<guoziqi2@huawei.com> # message auto-generated for no-merge-commit merge: !4658 merge endpoint_refactor into master [feat] hcomm endpoint refactor Created-by: guoziqi2025 Commit-by: guoziqi2025 Merged-by: cann-robot Description: ## 描述 本 PR 对 base_comm 的 Endpoint/RegedMemMgr 类层次做**公共流程抽取归一**内部重构：将"基类持有数据成员 + 继承复用"模型重构为"纯虚接口 + 组合"模型。对外 C 接口（ include/hcomm_res.h）签名不变，运行行为与重构前对齐。 **改动原因**（重构前的四类问题）： 1. **冗余**：6 个 endpoint 子类各自重复实现 6 个内存注册方法的一行转发（38 处、约 245 行） 2. **抽象不彻底**：Endpoint/RegedMemMgr 基类同时承担接口契约与数据成员持有；AicpuTsHccs 存在 8 处向下强转 3. **资源管理分散**：endpoint 句柄表为全局静态、不受 HcommResMgr 管理，进程销毁无兜底清理 4. **能力耦合**：监听/jetty/NIC 插件能力挂在 Endpoint 接口上，非持有方被迫实现空 stub **核心改动**： 1. **Endpoint 纯虚接口化**：ctxHandle_/regedMemMgr_/缓存成员等全部下放各派生类私有；内存注册接口从 Endpoint 移除（统一经 GetRegedMemMgr() 访问）；各子类 regedMemMgr_ 声明为具体 RegedMemMgr 子类类型并在 Init 构造（消除 8 处 dynamic_cast 强转） 2. **RegedMemMgr 纯虚接口化**：rdmaHandle_/memMtx_ 下放派生类私有、改为构造注入 3. **新增 ServerSocketContext 体系**（resources/endpoints/server_socket_context/，按类一文件）：抽象基类 + Host/Device/AicpuTsRoce/AicpuTsHccs/UbRtpUboe 五个路径子类 + 插件路径 PluginServerSocketContext（nic_plugin_holder.h 内）；监听三接口从 Endpoint 移除，统一经 GetServerSocketContext() 访问（AicpuTsRoce 的 HcclSocket 自管理/静态 map + refCount 复用、AicpuTsHccs 的 GlobalNetDevMgr 路径整体迁入） 4. **新增 EndpointMgr**（endpoint_mgr/）：收编原全局 endpoint 句柄表；EndpointCtx 按 {devPhyId, LinkProtoType, ip} 去重，多 endpoint 实例共享同一底层 RDMA 句柄（AcquireEndpointCtxByAddr/ByEid 出参接口 + ReleaseEndpointCtx 共享引用计数判定 + victim 模式锁外析构）；~HcommResMgr() 兜底 DeInit 释放残留；作为 HcommResMgr 成员持有 5. **NIC 插件路径归一**：nicOps_/nicCtx_ 移入 PluginEndpointHolder；PluginRegedMemMgr（内存五接口转发）、PluginServerSocketContext（getListenPort 转发）承载插件能力 6. **删除 UboeUbRtpEndpointHelper 中间继承层**；coll_communicator_mgr 侧同名 EndpointMgr 命名空间 hcomm→hccl 消除冲突 7. C 适配层统一经 HcommResMgr::GetInstance().GetEndpointMgr() 路由（句柄查找失败返回 HCCL_E_NOT_FOUND）；指针入参判空校验下沉至各派生类接口入口（插件路径除外，由插件侧自负）；HcommResMgrInit/RefreshEndpointContext 保持原有调用副作用 ## 变更类型 请选择本次引入的变更类型： - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [x] 📋 其他，请描述：内部重构（接口与实现分离、公共流程归一；对外 C API 签名不变、行为对齐重构前） ## 关联的Issue NA ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于构造对应xx测试用例、二级冒烟、算子泛化等。--> 已完成的测试用例和场景： 1. pkg 全量编译通过（x86_64，0 error，endpoint 相关无 warning） 2. UT & ST 通过 3. HCOMM仓RDV验证通过 4. aiv共享jetty功能验证通过 5. 单边通信验证通过 补充的UT用例： - ut_hcomm_endpoint_mgr.cc：EndpointMgr 的 Add/Remove/Update/Get、Acquire 去重（同 key 共享、use_count 递增）、Release 共享判定、DeInit 兜底清理 - ut_endpoint_ctx.cc：EndpointCtx/EndpointCtxKey - ut_server_socket_context.cc：五路径子类的监听行为、析构兜底停止监听、no-op 语义、继承基类默认 NOT_SUPPORT - ut_plugin_reged_mem_mgr.cc：插件内存五接口转发 + GetListenPort 转发 - 既有 endpoint/channel UT 全量适配新接口（Init 签名、具体类型 mgr、stub 派生类等） ## 文档更新 NA（纯代码重构，无对外接口与文档变更） ## 合入检查 <!-- 在正式合入前，请做好必要的代码测试，用例补充，软件代码风格检查等。提高合入效率。--> - [x] 🧐 已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 - [x] 🔍 邀请 committer评论/lgtm前的必要检查 - [x] 🏷️ 标题中使用了合适的类型标签（如：[feat], [fix]） - [x] 📄 代码修改内容已简要描述，相关文档已更新 - [x] 📝 代码注释已更新，代码遵循项目整体代码风格 - [x] 🧪 代码UT测试已更新，覆盖率已达标 - [x] 🔬 验证方法已更新到"测试"部分 - [x] 🛠️ 代码已通过静态分析工具检查，无错误 - [x] 👥 代码检视/code review/同行评议和必要的代码串讲，确保代码质量 - [x] ✅ 代码检视意见已处理或答复，无未处理的检视意见 - [ ] 🚀 预约 前冒烟 用例前的必要检查 - [ ] ✔️ 代码已有committer的/lgtm 和 模块committer的/lgtm评论 - [ ] 🔧 代码已通过compile，编译无错误，无告警 - [ ] 🖥️ 代码已通过基本功能本地测试或者在线测试，确保基本功能正常 - [ ] 🎯 预约 approver评论/approve，正式合入前的必要检查 - [ ] 📊 前冒烟 用例已全量通过 - [ ] 📦 新增功能已同步补充基本功能测试用例到前冒烟里 See merge request: cann/hcomm!4658 | 2 months ago | |
[fix] taskexception issue Co-authored-by: lhdlhdlhd1234569<lihaodong19@h-partners.com> # message auto-generated for no-merge-commit merge: !4843 merge master into master [fix] taskexception issue Created-by: lhdlhdlhd1234569 Commit-by: lhdlhdlhd1234569 Merged-by: cann-robot Description: ## 描述 ### 简要描述 修复 TaskException 异常处理链路问题：按 CtxHandle 分组查询 Jetty 状态、注册时注销遗留回调、AIV 任务分支提前返回，并统一回调注册函数命名。 ### 问题描述 1. RaBatchQueryJettyStatus 将所有 Jetty 一次性批量查询，但不同 Jetty 隶属不同 CtxHandle（上下文），跨上下文批量查询会导致状态查询失败或结果错乱。 2. TaskExceptionHost::Register 注册新回调时未注销 legacy TaskExceptionHandler::Process 回调，导致新旧回调并存，异常事件被重复处理，存在冲突风险。 3. TaskExceptionHost::Process 为超大函数，且 AIV 类型任务被误入 HCCL 任务异常处理分支，产生无意义的错误日志和多余处理。 4. HrtReg/UnregTaskFailCallbackByModule 命名中 "Fail" 与实际语义 "Exception" 不符，易误导。 ### 解决方案 1. CcuJetty 新增 GetCtxHandle() 暴露上下文句柄；RaBatchQueryJettyStatus 改名为 HccpBatchQueryJettyStatus 并新增 ctxHandle 入参与空指针校验；PrintCcuUbRegisters 按 CtxHandle 分组，逐组调用 HccpBatchQueryJettyStatus 查询状态并回填至原始索引位置。 2. TaskExceptionHost::Register 在 aclrtExceptionInfoCallbackRegister 成功后调用 HrtUnregTaskExceptionCallbackByModule(TaskExceptionHandler::Process) 注销遗留回调，并合并日志。 3. 将 Process 拆分为 Process（入参校验）与 ProcessHcclTaskException（业务处理）；在 ProcessHcclTaskException 中新增 AIV 任务分支，命中时打印 RUN_INFO 并 return，避免后续无意义处理。 4. HrtRegTaskFailCallbackByModule → HrtRegTaskExceptionCallbackByModule、HrtUnregTaskFailCallbackByModule → HrtUnregTaskExceptionCallbackByModule，同步更新 .cc/.h/日志/legacy 调用方。 ### 影响范围 - 修改：CcuJetty、hcomm_adapter_hccp、CcuTaskException::PrintCcuUbRegisters、TaskExceptionHost::Register/Process、TaskExceptionHandler::Register/UnRegister、orion_adapter_rts 回调注册接口 - 行为：Jetty 状态查询按上下文分组，正确性提升；异常回调注册唯一化，消除重复处理；AIV 任务不再误入 HCCL 异常分支 - 兼容性：接口重命名为内部包间改动，对外 API 无影响；legacy 目录仅做 bug 修复与命名对齐，未新增特性 - 配置/依赖：无变化 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [ ] 📋 其他，请描述： ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR不涉及Issue，可填写"NA"。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于构造对应xx测试用例、二级冒烟、算子泛化等。--> ### 新增用例 - 单元测试 PrintCcuUbRegisters_When_JettysExist_Expect_QueryByCtxGroups：构造非空 Jetty 集合，验证按 CtxHandle 分组查询与状态回填逻辑 - 单元测试 Ut_Register_When_CommRegisterMapEmpty_Expect_RegisterCallbackAndUnregisterLegacy：验证 Register 成功注册回调并注销 legacy 回调 - 单元测试更新 HccpBatchQueryJettyStatusTest：适配重命名与新增 ctxHandle 入参，覆盖 size 不匹配与 num=0 场景 - stub 补充 HrtUnregTaskExceptionCallbackByModule 以支撑 UT 编译链接 ## 文档更新 <!--如果这个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!4843 | 2 months ago | |
[build] License Header Co-authored-by: ouyangcaike<ouyangcaike@h-partners.com> # message auto-generated for no-merge-commit merge: !4556 merge build/oat into master [build] License Header Created-by: ouyangcaike Commit-by: ouyangcaike Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> 1. 全仓C/C++、CMake、Python、Shell文件规范头部License的使用 ## 变更类型 请选择本次引入的变更类型： <!-- [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!4556 | 2 months ago |
| Files | Last commit | Last update |
|---|---|---|
| 2 months ago | ||
| 2 months ago | ||
| 2 months ago | ||
| 2 months ago | ||
| 2 months ago | ||
| 2 months ago | ||
| 2 months ago | ||
| 2 months ago |