变更摘要

本 PR 重构远端内存（远端导入/注销）的管理归属：将原位于进程级 RoceRegedMemMgr/UbRegedMemMgr 中的 MemoryImport/MemoryUnimport 逻辑整体迁移到新增的 Endpoint 实例级 wrapper RemoteMemMgrBase（派生 RoceRemoteMemMgr/UbRemoteMemMgr），进程级 mgr 只保留本端注册/注销/导出能力。各 Endpoint（cpu_roce_endpoint、cpu_urma_endpoint、uboe_endpoint、urma_endpoint、ub_rtp_endpoint）不再将 regedMemMgr_ 强转为具体进程级类型，而是将进程级 mgr 包成实例级 wrapper 后以 RegedMemMgr 基类指针持有。远端内存归属键由仅 endpointDesc 扩展为 {endpointDesc, pid}（新增 RemoteMemOwnerKey），内存描述符（memDesc）尾部追加 u64 pid 字段，同描述符重复导入改为幂等叠加实例内引用计数（不再返回 HCCL_E_AGAIN），以解决多个 Endpoint 实例共享进程级 mgr 时的重复导入报错与引用泄漏问题。

主要改动

• 新增实例级远端内存管理 wrapper（endpoint_remote_mem_mgr.h）: 新增模板类 RemoteMemMgrBase 及 RoceRemoteMemMgr/UbRemoteMemMgr 两个具体类，本端接口（RegisterMemory/UnregisterMemory/MemoryExport/GetAllMemHandles）纯转发进程级 mgr，远端接口（MemoryImport/MemoryUnimport）由实例自管，按 {endpointDesc, pid} 键管理远端缓冲并支持幂等导入与引用计数递减。
• 远端内存职责从进程级 mgr 剥离: roce_reged_mem_mgr.cc/h 与 ub_reged_mem_mgr.cc/h 删除 MemoryImport、MemoryUnimport、GetParamsFromMemDesc 实现及 remoteRdmaRmaBufferMgrs_/remoteUbRmaBufferMgrs_ 成员，reged_mem_mgr.h 中这两个接口改为带默认"不支持"实现（返回 HCCL_E_INTERNAL）的非纯虚函数。
• 内存描述符布局新增 pid 字段: RoceRegedMemMgr::GetMemDesc 与 UbRegedMemMgr::GetMemDesc 在 DTO 序列化 + EndpointDesc 之后追加 u64 getpid()，旧格式（不带 pid）的 desc 在解析时直接报错，强制两端同版本。
• 各 Endpoint 接入实例级 wrapper: cpu_roce_endpoint.cc、cpu_urma_endpoint.cc、uboe_endpoint.cc、urma_endpoint.cc 改为先取进程级 mgr 再 std::make_shared<RoceRemoteMemMgr>/<UbRemoteMemMgr>(procMgr, ctxHandle_)，ub_rtp_endpoint.cc 由实例自建 UbRegedMemMgr 后同样包 wrapper；对应头文件中 regedMemMgr_ 类型统一改为 std::shared_ptr<RegedMemMgr>。
• 补充/调整单元测试: 新增 ut_endpoint_remote_mem_mgr.cc 覆盖空指针校验、旧格式 desc 报错、同键幂等导入引用叠加、不同 pid 独立管理、末次 unimport 擦除 owner、本端接口纯转发等场景；ut_roce_mem_test.cc 删除随旧实现移除的 GetParamsFromMemDesc 用例，ut_hcomm_mem_test.cc、ut_cpu_urma_endpoint.cc 相应更新注释与 mock 描述。

代码审查

已完成对全部 20 个变更文件的逐一审查。以下为结论。

审查结论

发现 4 项问题（1 项 P0、1 项 P2、2 项 P3）：

• P0（高置信 0.85）：src/base_comm/resources/endpoints/cpu_roce_endpoint.cc:72 将 std::make_shared<RoceRemoteMemMgr> 赋给成员 regedMemMgr_，但同 PR 未修改 cpu_roce_endpoint.h（不在变更清单内），其成员声明仍为 std::shared_ptr<RoceRegedMemMgr>；RoceRemoteMemMgr 与 RoceRegedMemMgr 无继承关系，shared_ptr 无法转换，属直接编译失败。其余四个 endpoint 头文件均已同步改为 shared_ptr<RegedMemMgr>，唯独 RoCE 头被遗漏。
• P2（置信 0.55）：endpoint_remote_mem_mgr.h 新解析器只校验 descLen 下限，旧版本无 pid 的 desc（DTO 长度 ≥8 时）可绕过检查被静默错位解析（pid/desc/DTO 偏移全错），混合版本滚动升级时导致导入记账错误、注销 E_NOT_FOUND 泄漏或 Deserialize 异常穿出 C-API。
• P3（置信 0.70）：GetParamsFromMemDesc 中 resize(TRANSPORT_EMD_ESC_SIZE) 后立即被 assign 覆盖，无用预分配（可选优化）。
• P3（置信 0.40）：RemoteMemOwnerKey::operator== 对 EndpointDesc 整结构体（含 padding）memcmp，与仓库内既有"字段级 hash/compare 规避 padding 误判"的做法相悖，padding 不稳定时同一远端内存可能被识别为不同 owner。

逐文件核对：

• cpu_roce_endpoint.cc — 发现 P0（见上）
• cpu_urma_endpoint.cc / cpu_urma_endpoint.h — 无问题（AttachCache/Init 与头文件类型一致，ctxHandle_ 先于 wrapper 构造赋值）
• ub_rtp_endpoint.cc / ub_rtp_endpoint.h — 无问题（两次 EXCEPTION_CATCH 覆盖两个分配步骤，失败均回滚 ReleaseEndpointCtx）
• uboe_endpoint.cc / uboe_endpoint.h — 无问题
• urma_endpoint.cc / urma_endpoint.h — 无问题
• endpoint_remote_mem_mgr.h（新增）— 发现 P2 + 2 项 P3（见上）
• reged_mem_mgr.h — 无问题（MemoryImport/Unimport 改为带默认报错实现的虚函数，Hccs/AicpuTs/UbMem 等派生类仍自行覆盖，无行为回归）
• roce_reged_mem_mgr.cc / roce_reged_mem_mgr.h — 无问题（pid 追加有 memcpy_s 校验；远端逻辑已正确迁移至 wrapper）
• ub_reged_mem_mgr.cc / ub_reged_mem_mgr.h — 无问题
• test/ut/framework/next/CMakeLists.txt — 无问题（新增 UT 源文件路径与文件存在性一致）
• ut_hcomm_mem_test.cc — 无问题（仅注释修改）
• ut_endpoint_remote_mem_mgr.cc（新增）— 无确认问题（用例覆盖幂等导入/分 pid 管理/最后引用注销等关键路径；测试以 nullptr rdmaHandle 构造 RemoteRdmaRmaBuffer 的可行性依赖其构造函数实现，未能静态确认，但生产路径同构）
• ut_roce_mem_test.cc — 无问题（删除的用例与被移除的 GetParamsFromMemDesc API 配套）
• ut_cpu_urma_endpoint.cc — 无问题（mock 派生自 UbRegedMemMgr，可赋给基类指针成员）

总体风险判断： 本次改动（远端内存导入/注销从进程级 mgr 下移到 Endpoint 实例级 wrapper）设计方向清晰，本端接口转发与实例级 refcount 语义自洽，测试覆盖了核心路径。但存在一个必须修复的 P0 编译问题（cpu_roce_endpoint.h 类型未同步），以及一个影响混合版本部署的 desc 格式兼容性缺口（P2），建议修复后再合入。

⛔ 需要修改

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

✅ Congratulations! All modules have met the lgtm and approve requirements.

Module Approval Details

💡 Tip:

• Committer can comment /approve or /lgtm
• Commenting /approve implies both code review (lgtm) and intent to merge (approve)

CLA Signature Pass

littlemons, thanks for your pull request. All authors of the commits have signed the CLA. 👍

/lgtm