10 5 月, 2026
距上次梳理阿里HPN的论文已过去2年时间了,这次看微软/OpenAI联合多家NIC/交换机厂商(NV CX-8、AMD Pollara/Vulcano、BRCM Thor Ultra、NV Spectrum 4/5、BRCM TH5)发布的 MRC + SRv6 论文,网络架构思路差异很大,但很多设计点跟HPN/UEC形成对比,值得对照仔细研究,里面很多信息可以借鉴和参考,可以说是为数不多的好论文(对我的领域而言)。从目前的形式看,业界有从 Lossless RDMA -> Lossy RDMA 转向的趋势,目前国内看到的阿里已经大规模部署Lossy RDMA,字节去年也发布了他们自己的Lossy RDMA方案,UEC里的UET也是定义在Lossy以太网中,现在MRC又拱了一把火。
在论文中,MRC把应用层的多路径(1 collective 拆多 QP,每 QP 经 ECMP 一条路径)下沉到transport层,对应用透明。而且把大量网侧的功能下沉到NIC,完全由NIC来完成。虽然规避了一些问题,但也带来了tradeoff,使应用场景受限。而对于网侧来说,除了要支持SRv6和Packets Trim外,就是傻大快了。当然决定架构走向的往往不是技术本身。
注:以下纯属个人分析,很多内容是根据论文推出来的,权当自己的阅读笔记,留作日后 review。理解难免有偏差,若有错漏之处,恳请留言指正,不胜感激。
论文原文:
完整阅读
5 5 月, 2026
架构概述
之前使用过chatgpt和claude协助写过一些测试脚本,比如早期的:RDMA测试脚本 by ChatGPT?!,后来优化的就没更新在blog中了。以至于后来研发的同事帮忙优化的测试脚本,虽然目前可以达到一定需求,但python精度太差,都是ms级精度控制,效率不是很高。因此需要一套高性能RDMA测试脚本,满足不同场景下针对交换机的测试需求。目前看上去使用openmpi来控制perftest的思路比较合理,而且有的用户也在使用类似的方式,所以就尝试走这条路。以下是五一期间跟claude合作开发的测试系统,里面很多细节还有待完善中。
设计思想
本方案采用 MPI 指挥 + perftest 执行的分离架构:
- MPI(mpi4py):只做”指挥官”——进程启动、全局同步(Barrier)、决策广播(Bcast)
- perftest(ib_write_bw):做”士兵”——真正发送 RDMA Write 流量,由 HCA 硬件直接执行
- 流量控制:通过 SIGSTOP/SIGCONT 信号(training 模式,毫秒级突发)、perftest 内置 rate_limit/burst_size(storage 模式,微秒级突发,但并行打流时机会错开)、或两者结合(sync_burst 模式,微秒级突发,同步并行打流)
完整阅读
14 6 月, 2024
背景
之前一直看到有人谈论用Chatgpt编程序,设计产品,做游戏,反正很神就是了。在我使用过程中,并没有感觉那么神,也许是提示字给的不标准吧。最近正好有个机会,需要搞一个All2all的测试脚本,可自动化提供大规模All2All的测试任务。因此就测试了下GPT的能力。
目前用的是最新版本GPT4o(自行花了20美金),整体使用下来,GPT确实可以协助编程,只是沟通起来比较费劲和费时间……如果真正要搞一个项目,就不太现实了。估计还要再迭代几轮吧。即使是最牛的GPT4o,在沟通交互中,仍然会有以下问题:
- 强调过的内容,可能要重复说3-4遍,GPT才真的听进去了,但过了几轮后可能就又忘记了,比如”不着急出优化代码,先讨论问题“;
- 为了提升效率,对于一些小优化,其实可以提供代码片段,但GPT有时候提供的片段跟代码本身没有强联系;
- 为了排障,在脚本中增加了一些提示信息(增加执行log)。后面随着不断迭代优化,就会发现有些功能消失了。这种现象很明显,很可能会遇到之前解决过的问题再次出现……
完整阅读
9 8 月, 2023
之前建了两台VM,测试了下Soft-RoCE,但当时忘记抓包了,想打开再发些流量,发现详细步骤已经忘记了。。。所以这次还是把步骤记录下来,后面不断完善,防止下次忘记。
Topology
注:为了避免麻烦,我使用的是比较新的ubuntu 22.04.2,这里面自带iproute2和perftest,以及相应的Soft-RoCE的包;
192.168.123.130
┌────────────┐ ┌────────────┐
│ ubuntu1 ├─────────────┤ ubuntu2 │
│ rdma1 │ │ rdma2 │
└────────────┘ └────────────┘
192.168.123.129
部署Soft-RoCE
完整阅读