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

" 很有趣；你不能和忍受它们，但你也不能没有它们。" 在交换机上总是需要一定数量的，从而确保在较高优先级的发送者因任何原因停止发送时，链路带宽不会被浪费。通过让较低优先级的数据包排队，并在较高优先级的发送方出现空闲时来发送这些低优先级数据，从而保持吞吐量；然后 Homa 可以向其他发送者发送 grant，从而让他们加速。他说，对 grant 信息的会提供 "（过度承诺）"，再配合上带有优先级的功能，就可以在得到高吞吐量到同时，让重要的、较短的信息实现低延迟。
人们可能会认为，较长的信息有可能在一个负载过重的网络上出现饿死的情况（）。他说，他试图在 Homa 中产生这种现场，从而对其进行研究，但他发现这真的很难做到；他可以创建出饿死的场景，但必须得通过 "对进行一些歪曲 "来实现。但是，为了避免出现，Homa 挪用了接收方的一小部分带宽（通常是 5-10%），将其用于等待时间最久的消息（），而不是严格地按照 SRPT 所说来传输最短小的消息。这样保证了这些消息可以取得进展；最终它们的剩余 size 变得足够小，就可以与其他 small一起被优先处理。
Homa 不要求数据包要按顺序交付；数据包可以以任何顺序到达，接收者将根据需要对其进行分类。他说在实践中无论如何，数据包基本上都是按顺序到达的，所以进行重新排序的计算开销并不高。他认为，Homa 消除了数据中心的核心拥堵（core-）问题，除非整体流量本身就过高了。因为数据包可以通过 core来采用不同的路径。这就可以在中更好地实现负载平衡，以及在接收主机的 CPU 核心之间实现更好地负载平衡。
TCP?
说，很难想象一个比 TCP 协议更牢固（）的标准，所以 "我在进行这项工作时充分认识到，我可能是疯了才会想要这么做" 。基于他从 Homa 看到的结果，他已经给自己设立了一个任务，要找出一种方法来让 Homa 接管数据中心中大部分 TCP 流量，否则就要得出一个明确的结论说为什么不可能；"我要一直走下去，直到我遇到一个根本无法解决的障碍" 。
做到这一点的第一步是要有一个 "人们可以真正使用的"、达到了生产质量（-）的 Homa 实现。他说，他是 "学术界的一个小怪胎"，因为他喜欢写代码。几年前，他着手为 Homa 编写一个 Linux 内核驱动程序；他本来 "对 Linux 内核一无所知"，但现在已经有了一个可以使用的 Homa 驱动程序。
这个 Homa可以在 Linux 5.17 和 5.18 上运行，它并不是一个 "研究原型（）"，这个术语他不喜欢。研究原型是指无法正常用起来的东西，"可以以某种方式写一篇关于它的论文，并提出关于它的主张，尽管它实际上并不真正用起来" 。他说，目前 Homa 模块已经接近生产质量；发现和 fix 剩余 bug 的唯一方法是开始在生产环境中实际运行。
他说，就性能而言，Homa 在所有工作场景和所有各种消息 size 方面已经 "完全超出" 了 TCP 和 DataTCP（DCTCP）。他给出了几个样例，其中显示在第 50 百分位的 short-方面有 3-7 倍的改进，而在第 99 百分位（"tail "）有 19-72 倍的改进。关于 Homa 的内核驱动的更多信息可以在他 2021 年年度技术会议的论文中找到。
【LWN：数据中心中替代TCP，第二部分！】他在这个任务中看到的最大的问题，是有大量的应用程序通过接口直接使用 TCP 。Homa 的基于的 API 与之不同，他一直无法找到一种 "在现有的 TCP 套接字接口下无缝切换" 的方法。但是，不太可能替换这些应用程序中的相关代码，哪怕只替换大部分，也是不现实的。这种直接使用 TCP 套接字的应用程序中的大部分还需要能在广域网上正常工作，而 Homa 并不是一个好的选择；其他的应用程序确实不需要 Homa 带来的性能提升。真正受益于 Homa 的应用是比较新的数据中心应用程序，它们大多都从少数几个 RPC 框架中选了一个来使用。