为何控制信号通信更偏好RDMA SEND/RECV而非RDMA WRITE？

很多人会疑惑为什么 RDMA SEND/RECV 在命令、信号或小体量数据场景中被广泛使用，毕竟 WRITE/READ 内存语义操作的理论延迟和 CPU 负载看起来更低。但两者的核心差异不在于单纯的性能指标，而在于语义模型、控制权和场景适配性：

• 天然的消息边界与同步语义：SEND/RECV 是基于消息的通信模式，每个操作都有明确的消息边界——接收方通过完成队列（CQ）事件就能确认一条完整的命令/信号已经到达，不需要额外逻辑判断数据是否完整、是否为新指令。而 WRITE 是直接写入远程内存，接收方无法被动感知数据写入完成，必须通过轮询内存状态、额外信号通知或同步原语来确认，这部分额外开销在小数据场景下会完全抵消 WRITE 的性能优势。

• 内存权限与安全性控制：SEND/RECV 不需要接收方预先向发送方开放内存写入权限。命令/信号属于控制类数据，接收方通常不希望发送方直接修改自身内存空间，SEND/RECV 的消息传递模式让接收方可以在用户态完全掌控数据处理流程，避免了内存权限配置不当带来的安全风险或误操作。而 WRITE 操作要求接收方预先注册内存区域并授予写入权限，对于频繁变化的控制类场景，权限管理的复杂度会显著提升。

• 小数据场景的实际开销平衡：虽然 WRITE/READ 的理论延迟更低，但在几十字节级的小数据场景下，两者的实际性能差距微乎其微。此外，部分 RDMA 实现中 SEND/RECV 可以使用未注册内存（不需要提前完成内存注册流程），而 WRITE/READ 必须依赖注册内存——内存注册的开销对于小体量的命令/信号来说，可能比通信本身的开销还大，反而让 SEND/RECV 更高效。

• 编程模型的适配性：命令/信号通常是异步通知类场景，SEND/RECV 的消息队列模型天然贴合这种需求——接收方可以通过 CQ 事件驱动处理新指令，不需要主动轮询。而 WRITE 操作需要接收方主动检查内存变化，或者额外搭建事件通知机制，编程复杂度更高，也更容易引入bug。

内容的提问来源于stack exchange，提问作者mike_jack