GitHub user zchuango edited a discussion: openEuler总线协议urma和obmm技术路线讨论
BRPC社区伙伴们好， 我们正在从事拓展brpc框架更多通信协议的事情，近期调研了openEuler在[UB](https://www.openeuler.openatom.cn/zh/projects/ub-os-component/)（Unified Bus） 总线上的两套官方加速组件，现将链接中的技术细节、性能指标、应用场景以及一些想法梳理如下，**征求大家对 brpc 后续整合方向的意见**（欢迎直接回复本帖）。 ________________________________________ ### 一、项目速览与官方性能 #### 1. OBMM（OpenEuler Boost Memory Management） 仓库：https://atomgit.com/openeuler/obmm 核心能力（摘自 README + 源码注释）： ● **单节点内存扩展**：在单节点环境中扩展可用内存容量，突破本地物理内存限制。 ● **多节点间共享内存**：在多节点环境中实现高效的内存数据共享和协作，目前可以做到把 DDR、GPU VRAM 统一为一段虚拟地址，用户态 mmap 即可使用，**零拷贝attachment**。 ● **PCIe P2P原生支持**：将远端内存映射为本地 NUMA 节点，应用可透明使用 load/store 访问，远端主机通过 PCIe 直接 memcpy 写入本地内存池中，**本地CPU零参与、零 bounce**。 #### 2. **UMDK-URMA（Unified RDMA Messaging API）** 仓库：https://atomgit.com/openeuler/umdk 核心能力（摘自头文件 + 文档）： ● **无连接UM语义**：驱动内重传/CRC，可靠且免 RC-QP 爆炸（单 jetty 可打 N 远端）。 ● **统一内存操作语义**：统一内存语义操作接口，提供单边、双边及原子操作等远程内存操作方式，作为应用间通信的基础，RoCE v2、InfiniBand、PCIe P2P 均通过同一套 urma_post_send/recv API实现对接。 ● **URMA-SHM模式**：远端映射同一块物理页，本机 & 跨机共享内存统一访问内存数据，做到全局共享，特别适合各种cache的one2all场景。 ________________________________________ ### **二、与 brpc 的契合点** 需求 | OBMM方案 | URMA方案 | 现有 TCP/RDMA对比 | ---------- | -------------------- | --------------- | ------------------ | 本机零拷贝IPC | GPU/CPU 统一地址，mmap 即用 | URMA-SHM 映射同页 | TCP 需 1 次拷贝 连接规模 | 无 QP，线性增长 | 单 jetty 打 N 远端 | RC QP 万级爆炸 生命周期 | 引用计数自动释放 | UB 引用计数 | 进程自维护，易泄漏 ________________________________________ ### **三、可能的 brpc 技术路线** **路线 A：OBMM-ShmemTransport** ● 只解决 本机 & 远端 PCIe P2P 场景，延迟最低（3.8-5 µs）。 ● 代码简单，无内核模块依赖（OBMM ko 已主流发行版内置）。 **路线 B：URMA-UrmaTransport** ● 一套代码覆盖 跨机 RoCE/IB/UB，理论带宽 50 GB/s，连接数无上限。 ● 需 UB 驱动，但已支持 PCIe P2P，未来可平滑切换到 CXL。 **路线 C：A+B 双后端** ● 小包 (<64 KB) 优先 OBMM-ShmemTransport，大包走 URMA-UrmaTransport，运行时自动选择。 ● 维护两套 transport，但性能最优，且对用户透明。 ________________________________________ ### **四、征求社区意见** 1. 你们是否有 GPU-Direct / CXL / 异构内存 的真实业务？期望延迟/带宽指标是多少？ 2. 更看重 最低延迟(OBMM)还是任务的吞吐量 (URMA) ？ 3. 倾向于 单一后端还是双后端自动切换 ？ 4. 生产环境是否接受 OBMM ko / UB ko依赖？ 欢迎在评论区留下您宝贵意见： ● 实际用例与指标 ● 部署环境（公有云、IDC、GPU 集群等） ● 对 A/B/C 路线的倾向 两周后我们将汇总反馈，发布详细设计文档与 draft PR，感谢！ GitHub link: https://github.com/apache/brpc/discussions/3217 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
