作者：The Next Platform联合主编Timothy Prickett Morgan
远程过程调用（RPC）可能是现代计算发展史上最重要的一项发明。能够从一个运行中的程序发起通信，并激活另一组代码执行某项任务（获取数据或以某种方式处理数据），这本身是一个强大而普遍的概念，并催生了模块化编程和微服务的崛起。
当下，在与昔日的整体式代码截然不同的环境，代码块与跨集群运行的系统各组件之间的延迟至关重要。而缩短这个延迟从未如此艰难。但是斯坦福大学和普渡大学的一些追求创新的研究人员已提出了一种协同设计的网络接口卡（NIC）和RISC-V处理器，它为可显著缩短RPC的延迟，同时使它们更具确定性的CPU提供了一条捷径。相关研究成果已在最近的USENIX操作系统设计和实现研讨会（OSDI '21）大会上作了介绍，表明了nanoPU混合方法为何是加快至少某一类RPC（指信息量很小，通常需要超低延迟的RPC）的出路，同时让其他类型的RPC可以使用平常的远程直接内存访问（RDMA）路径，这条路径已使用了几十年，遇到了较低延迟方面的瓶颈。
Stephen Ibanez是斯坦福大学的博士后，师从Nick McKeown，后者是P4网络编程语言的联合开发者，还是Barefoot Networks公司的联合创始人，现在是英特尔网络和边缘集团总经理。Ibanez在OSDI '21大会上阐述了nanoPU概念，解释了为什么这个概念很重要，可能会为将来针对各种工作负载的其他类型的网络加速开辟一条道路。
简而言之，问题如下。
托管在超大规模业者和云构建者的大型应用程序使用远程过程调用即RPC进行通信，搜索引擎、推荐引擎和联机事务处理应用程序就是三个典例。现代应用程序中的RPC散布在这些大规模分布式系统中，完成一件工作常常意味着等待最后一部分数据被处理或被检索。正如我们之前多次解释的那样，大规模分布式应用程序的尾部延迟常常是应用程序整体延迟的决定性因素。这就是为什么超大规模业者总是竭力为跨系统网络的所有通信获得可预测的、一致的延迟，而不是试图尽可能获得最低的平均延迟，而对尾部延迟不闻不问。
Ibanez表示，nanoPU研究论文开始着手回答这个问题：怎样才能绝对最小化RPC中值和尾部延迟以及软件处理开销？
Ibanez在介绍论文时解释：“说到管理尾部延迟和小消息吞吐量，传统的Linux堆栈效率低得可怜。网络界已意识到了这一点，一直在探索许多提升性能的方法。”
下表概述了这方面的工作：
nanoPU论文中使用的线对线（wire-to-wire）延迟的定义非常清楚；对于上述任何一种方法而言，线对线延迟是指从以太网线路到用户空间应用程序再返回到以太网线路的时间。有使用内核绕过技术的自定义数据平面操作系统。但是尝试将特定的IPC放到特定的可用 CPU线程上的软件开销却很大，最终会变得非常粗粒度。中值延迟可能在2微秒至5微秒之间，尾部延迟可能在10微秒到100微秒之间。因此，这不适用于细粒度任务，比如现代应用程序中使用RPC变得越来越普遍的任务。
还有专门的RPC库可以缩短延迟并提高吞吐量——卡内基梅隆大学和英特尔实验室的eRPC就是一个典例，但Ibanez表示，他们未能足够有效地控制尾部延迟，这对整体性能来说是一个问题。所以还有其他方法可以将传输协议卸载到硬件，但保持RPC软件在CPU上运行（比如来自普林斯顿大学的Tonic)，这可以提高吞吐量，但只是解决了问题的一方面。虽然许多商用网络接口卡（NIC）支持RDMA协议很好，RDMA的中值线对线延迟可以低至700纳秒也很好，但是问题是分布式计算集群中所用到的无数小RPC需要远程访问计算，而不是远程访问内存。因此，我们需要远程直接计算访问。
正如nanoPU项目所示，要做到这一点，解决办法是创建一条进入CPU寄存器文件本身的快速路径，并绕过所有可能会挡道的软硬件堆栈。为了测试这个想法，斯坦福大学和普渡大学的研究人员研制了一个自定义的多核RISC-V处理器和提升RPC的NIC，并运行了一些测试，以证明这个概念有一定的有效性。
这不是一个新概念，而是实现该想法的新方法。如上表所示，Nebula NIC项目做到这一点的方法是，将NIC与CPU整合起来，并将中值延迟缩短到100纳秒以内，这非常好，但尾部延迟仍然在2微秒到5微秒之间（数据平面操作系统对中值延迟所做的），但斯坦福大学和普渡大学的技术人员表示，还有更多的空间来缩短延迟、提高吞吐量。（Nebula NIC源自瑞士洛桑联邦理工学院、美国佐治亚理工学院和雅典国立技术大学与Oracle实验室合作的一个项目。）
这是nanoPU的样子：
nanoPU实现了多核处理器，带有你可能想到的硬件线程调度器，每个都有自己的专用收发器队列，与NIC集成起来，并且与Tonic一样，它也在NIC硬件中实现了可编程传输机制。对于延迟长得多，不需要从网络直接进入到CPU寄存器的快速路径的那些应用程序而言，从NIC中的硬件传输到最后一级缓存或CPU主内存的DMA路径仍然存在。硬件线程调度器独立运行，不让操作系统处理，因为这会大大增加操作系统堆栈上下的延迟。
FPGA中实现的nanoPU原型被模拟后以3.2GHz的频率运行，这与当今最高速度的CPU差不多，并使用经过改进的五级“Rocket”RISC-V核心。线对线延迟仅为69纳秒，单个RISC-V核心每秒可以处理1.18亿个RPC调用。（相当于一个72B的数据包中含有8B消息。）
以下是与支持 RDMA的NIC相比，nanoPU运行单边RDMA和老式应用程序所具有的表现：
我们假设这是图表左侧的InfiniBand，但不知道年份，它可能是带RoCEv2的以太网。
以下是nanoPU运行MICA键值存储系统的表现，该存储系统同样来自卡内基梅隆和英特尔实验室：
正如您所见，与传统RDMA方法相比，nanoPU在这个键值存储系统上可以提高吞吐量，还显著缩短延迟，而且是同时做到了这点。
看起来我们可能需要一个新标准来允许所有CPU支持嵌入式NIC，无需让任何人承诺使用任何特定的嵌入式NIC。或者更有可能的是，每家CPU厂商都会有自家版本的嵌入式NIC，并试图将两者的性能和收入联系起来。市场总是先走专有道路，然后走开放道路。毕竟，这是实现销售额和利润最大化的最佳途径。
顺便说一下，nanoPU项目得到了赛灵思、谷歌、斯坦福大学和美国国防高级研究计划局的资助。
最后提一下：这种方法难道不是会带来很好的MPI加速器？很久以前，据nanoPU论文介绍，J-Machine超级计算机和当时的Cray T3D支持类似于RPC的低延迟、核心间通信，但由于它们需要原子读写操作，所以很难阻止线程执行本不应该执行的读写操作。nanoPU中的集成线程调度器似乎通过寄存器接口解决这个问题。也许有一天所有CPU都会有寄存器接口，就像它们集成了PCI-Express和以太网接口等其他部件一样。
相关阅读 ·
- Uber一个团队放弃「微服务」改用「宏服务」
- 住手！！你不需要微服务！
- 切勿盲目崇拜微服务！
- 1.14 亿元、崂山区城市云脑：东华软件中标；长城软件、用友政务、青岛联通、金航数码落标
- 国家交通运输部《交通运输领域新型基础设施建设行动方案》：智慧公路、智慧航道、智慧港口、智慧枢纽等交通新基建工程建设是重点
- 一运维工程师、被判 5 年：为了学习，登陆老东家云桌面系统，延时点了几下鼠标、磁盘格式化了。。。
