| Files | Last commit | Last update |
|---|---|---|
CCU A6代际0.5rtt特性接口 Co-authored-by: gcw_7BxPXy6M<luoxiangyong1@huawei.com> Co-authored-by: Haoran Zheng<zhenghaoran22@huawei.com> Co-authored-by: hulk1997<hulinkang1@huawei.com> Co-authored-by: zhh<zenghonghui5@huawei.com> Co-authored-by: linzy_hccl<linzhiyang5@huawei.com> Co-authored-by: qq_46994783<sunenguang1@h-partners.com> # message auto-generated for no-merge-commit merge: !4873 merge ccu_rtt into master CCU A6代际0.5rtt特性接口 Created-by: gcw_7BxPXy6M Commit-by: hulk1997;qq_46994783;linzy_hccl;gcw_7BxPXy6M;Haoran Zheng;zhh Merged-by: cann-robot Description: ### 简要描述 新增 A6 代际 CCU 0.5-RTT（半往返）特性接口，通过级联计数器聚合同步替代逐事件信号量等待，减少通信往返次数 ### 问题描述 现有 CCU 通信同步机制依赖逐事件信号量（Post/Wait Sem），每次数据操作完成后需单独 Post 信号量通知对端，对端需逐个 Wait。在多对端聚合场景下，N 个对端的到达通知需要 N 次 Wait，同步开销随对端数线性增长，成为通信延迟的主要瓶颈。此外，DMA 写与计数器递增分两条指令完成，无法在一次操作中同时通知对端，进一步增加了同步往返。 ### 解决方案 - **资源层**：新增 HcommCcuCascCntHandle 句柄类型与 HCOMM_CCU_RES_TYPE_CASC_CNT 资源枚举，在 CcuComponent 中实现级联计数器块的分配/查询（CcuCascCntAlloc/CcuCascCntGetMem），每 die 上限 4 块，每块含 wishCntXn + totalCntXn + expectedCntXn - **Kernel 层**：在 CcuKernel 中新增 CascCntWait/CascCntClear/WriteVarAtomicAdd/WriteWithCascCntInc/LoadAddImm/AddImmStore 六个 API，封装为 CcuKernel 成员方法 - **Rep 层**：新增 6 个 IR 表示类（CcuRepCascCntWait/CcuRepCascCntClear/CcuRepWriteVarAtomic/CcuRepWriteWithCntInc/CcuRepLoadAddImm/CcuRepStoreAddImm），以及对应的 CcuRepType 枚举值 - **翻译层**：在 CcuInsGeneratorV2 中实现 6 个 translate 方法，调用 CcuV2::SyncAtX（原子写）、CcuV2::TransMem（带计数器递增的 DMA 写）等微码构造函数；后端优化器（InstructionScheduler）增加对 0.5-RTT 特殊指令的 LoadX/StoreX 读写优化识别 - **C API 层**：在 ccu_primitives.hpp 中暴露 CascCntWait/CascCntClear/WriteVarAtomicAdd/WriteWithCascCntInc/LoadAddImm/AddImmStore/ChannelIdGet 等 C++ inline 封装；在 ccu_res_c_adpt.cc 中实现资源侧 C 接口 - **资源管理**：新增 CcuCascCntBlockMgr 管理级联计数器块的生命周期，随 CcuInstance 创建/销毁 ### 影响范围 - 新增功能：6 个 0.5-RTT 数据面 API（级联计数器等待/清零、原子写、带计数器递增的写、Load/AddImm 复合操作） - 新增功能：3 个资源侧 C 接口（HcommCcuCascCntAlloc/HcommCcuCascCntGetMem/HcommCcuGetRmtMemToken） - 新增功能：级联计数器资源类型 HCOMM_CCU_RES_TYPE_CASC_CNT 及 CcuCascCntBlockMgr 管理器 - 性能：多对端聚合同步从 N 次 Wait 降为 1 次 CascCntWait，DMA 写与计数器递增合并为单条指令 - 兼容性：新增接口不影响已有通信流程，向后兼容 - 后端优化：InstructionScheduler 扩展支持 0.5-RTT 指令的寄存器读写优化，通过环境变量 HCOMM_CCU_HALF_RTT_XN_OPT=1 开启 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [x] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [ ] 📋 其他，请描述： ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR不涉及Issue，可填写"NA"。--> ## 测试 - UT：ut_ccuTaskException_halfRtt_test.cc — 验证 0.5-RTT 异常诊断场景 - UT：ut_ccu_microcode_loadx_storex.cc — 验证后端优化器对 LoadX/StoreX 的读写优化 - UT：ccu_imm_casc_demo.h — 级联计数器立即数 demo kernel - 手动测试：验证hcommtest中，dispach算子一卡多专家场景，bs=8和bs=256的正确性 ## 文档更新 <!--如果这个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!4873 | 1 month ago | |
[feat] support A5 UB Memory symmetric memory Co-authored-by: hblnb<huangbolin3@huawei.com> Co-authored-by: z00940303<zhangzhuopan@huawei.com> # message auto-generated for no-merge-commit merge: !5128 merge master into master [feat] support A5 UB Memory symmetric memory Created-by: zhangzhuopan Commit-by: hblnb;z00940303 Merged-by: cann-robot Description: ## 描述 本 PR 新增 A5 UB Memory 对称内存能力，主要改动如下： - 通信域初始化阶段按 COMM_PROTOCOL_UB_MEM 和 NetLayer 预制 LSA WorldTeam。 - 实现 UB Memory 对称窗口注册、查询和解注册： - 建立 LSA WorldTeam Socket Ring； - 预留 lsaTeamSize × stride 对称 VA 空间； - 获取并导出本地 allocation 物理内存描述； - 通过 Ring AllGather 交换各 LSA 成员的 Shareable Handle、大小和窗口偏移； - 完成远端内存 Grant、Import 和固定 VA 槽位映射； - 将 UB Memory 信息发布到统一 HcommWindow.lsaWin。 - 支持同一 allocation 的重复、包含及交叉重叠注册，通过 PA Handle 复用底层映射并维护引用计数。 - 支持 UB Memory 与 URMA 共用同一个 HcommWindow，分别维护 lsaWin 和 URMA 相关字段。 - 新增 LSA Team 查询及 Rank/Member 转换接口： - HcclTeamGetLsaTeam - HcclTeamMemberToRank - HcclTeamRankToMember - 适配 HcclSymWinGetPeerPointer： - A5 UB Memory 场景输入 LSA memberId； - A3 Legacy 场景继续保持 Rank ID 语义。 - 完善异常及资源管理： - 在集合操作阶段同步各成员本地执行结果，避免单 Rank 失败导致其他 Rank持续等待； - 配对释放 Retain 和 Import 得到的物理内存 Handle； - Import/Map 部分失败时即时回滚已建立的映射； - 调整组合窗口注销顺序，在全部资源注销成功前保留 Host 索引； - Socket 建链和 Ring 数据交换统一使用通信配置中的 LinkTimeout。 - 补充 UB Memory 对称内存接口资料及使用约束。 ## 变更类型 请选择本次引入的变更类型： - [ ] 🐛 Bug修复 - [x] ✨ 新特性 - [ ] 🚀 性能优化 - [x] 📝 文档更新 - [ ] 📋 其他，请描述： ## 关联的Issue - A5 UB Memory 对称内存需求：请填写实际 Issue 链接 ## 测试 已完成的测试用例和场景： 1. A5 双 Rank 数据面验证： - 对称窗口注册及查询； - 非零 Window offset 查询； - LSA Team 获取； - Rank ID 与 LSA memberId 双向转换； - GetPeerPointer 获取远端对称 VA； - Device 侧远端地址写入及数据校验； - 对称窗口集合解注册。 2. 重叠注册验证： - 完全相同区间重复注册； - 同一 allocation 子区间注册； - 同一 allocation 不同区间交叉注册； - 包含及被包含区间注册； - 相邻区间注册； - 不同 allocation 独立注册； - 多个外层 Window 按不同顺序解注册。 补充的 UT 用例： - 注册参数、地址溢出及映射范围校验。 - Window offset 分配、释放及空洞复用。 - Window 查询成功、越界和非 ACTIVE 状态。 - 本地 Handle 借用和远端 Handle Import。 - 多成员 Map 部分失败后的即时资源清理。 - 单成员及双成员 Ring AllGather 数据聚合。 - Register → Get → Deregister 完整生命周期。 - 重叠注册时 PA Mapping 及引用计数复用。 - Finalize 时 Window、VA 和 Handle 资源清理。 - UB Memory与URMA共存时 PeerPointer 分发。 - A3 Legacy PeerPointer Rank ID兼容。 - LSA memberId 越界及地址计算异常校验。 - Device Window注销失败时保留Host索引以支持重试。 - URMA重复及子区间窗口在最后一个别名注销后释放底层资源。 ## 文档更新 <!--如果这个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!5128 | 1 month ago | |
[feat] A5 平台 UB 支持 Jetty 队列深度（SCQ）可配置 Co-authored-by: liusr1008<liusiran4@h-partners.com> # message auto-generated for no-merge-commit merge: !5133 merge ub_queue_depth_dev into master [feat] A5 平台 UB 支持 Jetty 队列深度（SCQ）可配置 Created-by: liusr1008 Commit-by: liusr1008 Merged-by: cann-robot Description: ## 描述 A5 平台 UB 支持 Jetty 队列深度（SCQ）可配置：在 HcommChannelDesc.ubAttr 中新增 scqDepth 字段，允许调用方自定义 UB SCQ 队列深度；当 scqDepth 为有效值时（非 0 且非 0xFFFFFFFF），JFC 以**独占模式**创建（HrtRaUbCreateJfc 传入自定义 cqDepth），不与其他 Channel 共享，并在连接释放时由连接自行销毁。 具体改动： - **对外接口**（include/hcomm_channel.h）：ubAttr 新增 scqDepth，语义为"UB SCQ 队列深度，0 和 0xffffffff 表示使用默认值；有效值时 JFC 以独占模式创建"；HCOMM_CHANNEL_VERSION 由 4 递增至 5（union 内字段新增，遵循 ABI v4 先例） - **规格校验**（src/base_comm/common/orion_adpt_utils.cc/h）：新增 CheckUbScqDepth，校验范围 host（NORMAL 模式）[64, 32768]、AICPU（STARS_POLL 模式）[64, 16384]、AIV（USER_CTL 模式，复用 NORMAL 上限）[64, 32768]；UbConnBuildContext 透传 scqDepth - **各 Channel 透传**：HostCpuUrmaChannel、AicpuTsUrmaChannel、AicpuTsUboeChannel、AicpuTsUbRtpChannel、AivUrmaChannel 的 BuildConnection 增加 CheckUbSqDepth/CheckUbScqDepth 校验并将 sqDepth/scqDepth 传入连接构造；其中 UBOE/RTP channel 同时修复了 engine 从 COMM_ENGINE_RESERVED 改为 COMM_ENGINE_AICPU_TS、以及 sqDepth/scqDepth 透传缺失的问题（此前使用默认参数，用户配置不生效） - **Init 调用顺序调整**（host_cpu_urma_channel.cc）：将 BuildConnection() 从 DlUrmaFunctionInit()/HccpRaGetDevBaseAttr() 之前移到之后，确保 CheckUbSqDepth(ctx, devBaseAttr_) 执行时 devBaseAttr_ 已由 HccpRaGetDevBaseAttr 填充 - **连接层**（host_ub_connection.cc、dev_ub_connection.cc）：构造参数新增 inSqDepth/inScqDepth；指定 scqDepth 时调用 HrtRaUbCreateJfc(..., scqDepth) 创建独占 JFC（isExclusiveJfc），否则沿用 RdmaHandleManager::GetJfcHandle 共享路径；sqDepth 未指定时保持原有默认（OPBASE=8192 / OFFLOAD=128）；释放路径中独占 JFC（或 AIV 引擎 JFC）由连接调用 HrtRaUbDestroyJfc 销毁，共享 JFC 仍由 RdmaHandleManager 统一管理；共享 jetty（EXTERNAL_INJECT）模式下 sqDepth/scqDepth 不生效（深度由 SetSharedJettyFields 的 sDepth 统一决定），AIV 共享 jetty 路径已加告警日志提示 - **adapter_hccp 层**：HrtRaUbCreateJfc 新增 cqDepth 参数（默认 0），大于 0 时使用自定义 CQ 深度，否则按模式默认（CCU_POLL=64，其余=2M/64） ## 变更类型 - [ ] 🐛 Bug修复 - [x] ✨ 新特性 - [ ] 🚀 性能优化 - [x] 📝 文档更新 - [ ] 📋 其他，请描述： ## 关联的Issue NA ## 测试 已完成的测试用例和场景： 1. 新增 ST 用例 test/legacy/st/otherFiles/unified_platform/st_ub_queue_depth_config.cc（497 行）：覆盖 Host/AICPU 各连接类型（TP/CTP/UBOE/RTP）指定 scqDepth 创建独占 JFC、未指定使用共享 JFC、独占 JFC 析构释放、共享 JFC 不释放、sqDepth/scqDepth 生效、默认深度（OPBASE 8192 / OFFLOAD 128）及 CheckUbScqDepth 规格边界（min/max/超界/哨兵值，含 USER_CTL 模式） 2. 新增 UT 工程 test/ut/base_comm/common/orion_adpt_utils/（ut_orion_adpt_utils.cc 290 行）：验证 CheckUbScqDepth 与规格校验逻辑 3. 同步更新 stub 及既有用例签名（llt_next_orion_stub.cc、orion_adapter_hccp_stub.cc、st_coverResult.cc、st_dev_ccu_connection.cc、ut_dev_ccu_connection.cc） 补充的UT用例： 1. st_ub_queue_depth_config.cc — 独占/共享 JFC 创建与释放全场景（如 HostUbTp_WithScqDepth_CreatesExclusiveJfc、ExclusiveJfc_ReleasedOnConnectionDestroy、SharedJfc_NotReleasedOnDestroy） 2. ut_orion_adpt_utils.cc — CheckUbScqDepth 规格边界（NORMAL/STARS_POLL/USER_CTL 的 min/max/越界/默认值） ## 文档更新 - HcommChannelDesc 新增 scqDepth 字段说明：docs/zh/api_ref/comm_opdev/datatype_definition/HcommChannelDesc.md ## 合入检查 - [ ] 🧐 已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 - [ ] 🔍 邀请 committer评论/lgtm前的必要检查 - [ ] 🏷️ 标题中使用了合适的类型标签（如：[feat]） - [ ] 📄 代码修改内容已简要描述，相关文档已更新 - [ ] 📝 代码注释已更新，代码遵循项目整体代码风格 - [ ] 🧪 代码UT测试已更新，覆盖率已达标 - [ ] 🔬 验证方法已更新到"测试"部分 - [ ] 🛠️ 代码已通过静态分析工具检查，无错误 - [ ] 👥 代码检视/code review/同行评议和必要的代码串讲，确保代码质量 - [ ] ✅ 代码检视意见已处理或答复，无未处理的检视意见 - [ ] 🚀 预约 前冒烟 用例前的必要检查 - [ ] ✔️ 代码已有committer的/lgtm 和 模块committer的/lgtm评论 - [ ] 🔧 代码已通过compile，编译无错误，无告警 - [ ] 🖥️ 代码已通过基本功能本地测试或者在线测试，确保基本功能正常 - [ ] 🎯 预约 approver评论/approve，正式合入前的必要检查 - [ ] 📊 前冒烟 用例已全量通过 - [ ] 📦 新增功能已同步补充基本功能测试用例到前冒烟里 See merge request: cann/hcomm!5133 | 1 month 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 | |
[feat]提供查device的endpointdesc接口 Co-authored-by: YantingLiu<liuyanting11@huawei.com> # message auto-generated for no-merge-commit merge: !4232 merge getdescs into master [feat]提供查device的endpointdesc接口 Created-by: YantingLiu Commit-by: YantingLiu Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> 本次 PR 新增了查询设备 EndpointDesc 的对外接口，允许用户通过设备逻辑 ID 获取该设备上所有端点的描述信息。实现上，调用链路从上层 HcommEndpointGetDescNum / HcommEndpointGetDescs 进入适配层，通过 HCCP 南向接口获取设备的 EID 列表，再根据不同协议类型（UBOE / UBC_CTP / UBG）填充 EndpointDesc 结构。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [ ] 📋 其他，请描述： ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR不涉及Issue，可填写"NA"。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于构造对应xx测试用例、二级冒烟、算子泛化等。--> 已完成的测试用例和场景： 1. 原ut和补充ut 成功 2. UBG, UBOE, UB_CTP 真机 查询成功 3. hccl_vm checker 构造rtp ctp 查询成功 4. RDV通过 补充的UT用例： 增加 HccpGetIpByEid 查询成功和底层查询失败用例。 增加 HccpGetCtpEnable 的 CTP 支持、全 RTP、查询失败及空指针用例。 增加 Endpoint 查询接口对非 950 设备、不存在 EID 等异常场景的验证。 增加 UBC_CTP、UBG 返回 EID，以及 UBoE 返回 IPv4 描述的成功场景验证。 ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> 新增 HcommEndpointGetDescNum 接口文档。 新增 HcommEndpointGetDescs 接口文档，说明两阶段调用、数组容量及协议地址格式。 ## 合入检查 <!-- 在正式合入前，请做好必要的代码测试，用例补充，软件代码风格检查等。提高合入效率。--> <!-- [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!4232 | 2 months ago | |
CCU A6代际0.5rtt特性接口 Co-authored-by: gcw_7BxPXy6M<luoxiangyong1@huawei.com> Co-authored-by: Haoran Zheng<zhenghaoran22@huawei.com> Co-authored-by: hulk1997<hulinkang1@huawei.com> Co-authored-by: zhh<zenghonghui5@huawei.com> Co-authored-by: linzy_hccl<linzhiyang5@huawei.com> Co-authored-by: qq_46994783<sunenguang1@h-partners.com> # message auto-generated for no-merge-commit merge: !4873 merge ccu_rtt into master CCU A6代际0.5rtt特性接口 Created-by: gcw_7BxPXy6M Commit-by: hulk1997;qq_46994783;linzy_hccl;gcw_7BxPXy6M;Haoran Zheng;zhh Merged-by: cann-robot Description: ### 简要描述 新增 A6 代际 CCU 0.5-RTT（半往返）特性接口，通过级联计数器聚合同步替代逐事件信号量等待，减少通信往返次数 ### 问题描述 现有 CCU 通信同步机制依赖逐事件信号量（Post/Wait Sem），每次数据操作完成后需单独 Post 信号量通知对端，对端需逐个 Wait。在多对端聚合场景下，N 个对端的到达通知需要 N 次 Wait，同步开销随对端数线性增长，成为通信延迟的主要瓶颈。此外，DMA 写与计数器递增分两条指令完成，无法在一次操作中同时通知对端，进一步增加了同步往返。 ### 解决方案 - **资源层**：新增 HcommCcuCascCntHandle 句柄类型与 HCOMM_CCU_RES_TYPE_CASC_CNT 资源枚举，在 CcuComponent 中实现级联计数器块的分配/查询（CcuCascCntAlloc/CcuCascCntGetMem），每 die 上限 4 块，每块含 wishCntXn + totalCntXn + expectedCntXn - **Kernel 层**：在 CcuKernel 中新增 CascCntWait/CascCntClear/WriteVarAtomicAdd/WriteWithCascCntInc/LoadAddImm/AddImmStore 六个 API，封装为 CcuKernel 成员方法 - **Rep 层**：新增 6 个 IR 表示类（CcuRepCascCntWait/CcuRepCascCntClear/CcuRepWriteVarAtomic/CcuRepWriteWithCntInc/CcuRepLoadAddImm/CcuRepStoreAddImm），以及对应的 CcuRepType 枚举值 - **翻译层**：在 CcuInsGeneratorV2 中实现 6 个 translate 方法，调用 CcuV2::SyncAtX（原子写）、CcuV2::TransMem（带计数器递增的 DMA 写）等微码构造函数；后端优化器（InstructionScheduler）增加对 0.5-RTT 特殊指令的 LoadX/StoreX 读写优化识别 - **C API 层**：在 ccu_primitives.hpp 中暴露 CascCntWait/CascCntClear/WriteVarAtomicAdd/WriteWithCascCntInc/LoadAddImm/AddImmStore/ChannelIdGet 等 C++ inline 封装；在 ccu_res_c_adpt.cc 中实现资源侧 C 接口 - **资源管理**：新增 CcuCascCntBlockMgr 管理级联计数器块的生命周期，随 CcuInstance 创建/销毁 ### 影响范围 - 新增功能：6 个 0.5-RTT 数据面 API（级联计数器等待/清零、原子写、带计数器递增的写、Load/AddImm 复合操作） - 新增功能：3 个资源侧 C 接口（HcommCcuCascCntAlloc/HcommCcuCascCntGetMem/HcommCcuGetRmtMemToken） - 新增功能：级联计数器资源类型 HCOMM_CCU_RES_TYPE_CASC_CNT 及 CcuCascCntBlockMgr 管理器 - 性能：多对端聚合同步从 N 次 Wait 降为 1 次 CascCntWait，DMA 写与计数器递增合并为单条指令 - 兼容性：新增接口不影响已有通信流程，向后兼容 - 后端优化：InstructionScheduler 扩展支持 0.5-RTT 指令的寄存器读写优化，通过环境变量 HCOMM_CCU_HALF_RTT_XN_OPT=1 开启 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [x] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [ ] 📋 其他，请描述： ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR不涉及Issue，可填写"NA"。--> ## 测试 - UT：ut_ccuTaskException_halfRtt_test.cc — 验证 0.5-RTT 异常诊断场景 - UT：ut_ccu_microcode_loadx_storex.cc — 验证后端优化器对 LoadX/StoreX 的读写优化 - UT：ccu_imm_casc_demo.h — 级联计数器立即数 demo kernel - 手动测试：验证hcommtest中，dispach算子一卡多专家场景，bs=8和bs=256的正确性 ## 文档更新 <!--如果这个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!4873 | 1 month ago | |
[build] format all C/C++ files Co-authored-by: ouyangcaike<ouyangcaike@h-partners.com> # message auto-generated for no-merge-commit merge: !4462 merge build/clang-format into master [build] format all C/C++ files Created-by: ouyangcaike Commit-by: ouyangcaike Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> 1. format all C/C++ files ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] 🚀 性能优化 - [ ] 📝 文档更新 - [x] 📋 其他，请描述：工程 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。--> <!-- 如果这个PR不涉及Issue，可填写"NA"。--> NA ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于构造对应xx测试用例、二级冒烟、算子泛化等。--> 已完成的测试用例和场景： 1. 编译成功 2. 全量拦截项通过 3. 前冒烟测试通过 补充的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!4462 | 3 months ago |
| Files | Last commit | Last update |
|---|---|---|
| 1 month ago | ||
| 1 month ago | ||
| 1 month ago | ||
| 2 months ago | ||
| 2 months ago | ||
| 1 month ago | ||
| 3 months ago |