LWN：数据中心中替代TCP，第二部分！( 三 ) _tcp

在 RPC 框架中增加 Homa 支持，就可以让使用了这些框架的应用程序简单地修改某个小的配置选项就能切换到 Homa，而不需要进行很多代码修改；就像应用程序可以改变他们所使用的服务器名称一样，他们将能够选择 Homa 而不用 TCP 。他正在进行将 Homa 支持添加到 gRPC 的工作。C++ gRPC 的集成现在已经可以工作了，尽管不支持加密，而 Java gRPC 对 Homa 的支持还是 "萌芽状态（）"，但仍在继续正在进行开发。
然而，使用 gRPC 的工作让他 "非常难受"，因为它 "慢得难以想象" 。gRPC 在 TCP 上的往返延迟是 90μs，其中三分之二的时间花在客户端和服务端上的 gRPC 层（各占了 30μs）。他说，如果目标是达到 5μs 的往返时间，很明显是无法使用 gRPC 来做到的。使用 Homa 之后，gRPC 的速度大约达到了两倍快，甚至在上的 gRPC 层也能看到这样的速度提升，他对此其实并没有什么好的解释。但即使是这样也离目标很远，所以他认为最终需要开发一个 "超级轻量级 "的框架。
他说，即使有了 Homa，性能仍然与硬件所能达到的水平差一个数量级。"网络速度正在以这种惊人的速度增长，而 CPU 的速度却没有什么变化" 。软件根本无法跟上，他认为这个问题没有解决办法。所以传输协议的软件实现就不再有意义了；这些协议都需要转移到网卡（NIC）中。
to user space
有些人会说，你只需要把 "那些可怕的操作系统" 赶走，把所有东西都转移到用户空间就好；他说，这会有一些帮助，但是完全不够的。在里，斯坦福大学的研究人员在用户空间实现了 Homa，能够实现 14μs 的 99% round-trip ，而 Linux 上 Homa 的 tail- 是 100μs 。
这么高的 tail ，主要罪魁祸首是软件开销，尤其是负载平衡方面的开销。单个 CPU core 不能处理超过的数据，但要是你把工作分到多个 core 上，就会固定有一部分的性能损失，这是由于需要进行工作分配。除此之外，还有一个 hot spot 问题，也就是在某些 core 上有太多的工作了，而其他 core 则处于 idle 状态或大部分时间处于 idle；这些都会导致出现一些 high的高峰（spike）。
他没有测量过，但他的理论是，将工作拆分到多个核心上带来的固有降速，是由于 cache导致的。与在单核上进行处理相比，来自于分配工作导致的大量 cache-降低了性能。不仅仅是他的 Homa 实现中看到了这个数量级的损失；他在谷歌的 Snap/Pony 系统中看到，当从单核切换到多核处理时，它的效率损失是 4-6 倍。他说，这里有一个经验法则，如果你需要不止一个 CPU，那么只增加第二或第三个 CPU 是不够的；"你实际上必须做到四核，才能真正比单核提升更多的性能" 。
说，如果你看一下各种论文中的一些数字，你可能会得出结论，将协议处理转移到用户空间是一个好主意。但是，所有这些用户空间的实现 "基本上只是研究原型，而且它们过于简化"；它们没有完成生产系统所需的大量处理工作。它们也是在最理想的条件下测量的，要么没有负载平衡，要么有完美的人工分析之后进行的分区配置，只处理短消息（"这太容易了"），等等。
但是 Snap 是一个可以用来比较的、达到了生产质量的用户空间实现；它大约比 Linux 内核中的 Homa 好 2 倍。如果你看一下双向实现（80%负载的网络）所需的 CPU core 的数量的话，Snap 需要 9-14 个内核，而 Linux Homa 需要 17 个。所以用户空间更好，但并不会带来数量级的变化。
To the NIC
他认为人们唯一的选择是将传输层的协议处理转移到网卡中去。应用程序将直接访问网卡，绕过内核，通过一个基于消息的接口来实现；" 这个概念从不进入软件" 。其他功能，如通过选择一个空闲的应用程序线程来实现负载平衡、虚拟化和加密，也应该被添加到网卡上。