是否可以使用 Windows 每秒处理数百万个数据报？

Question

我正在研究是否可以在 Windows 上实现一个 HPC 应用程序，该应用程序使用十几个或最多 200 个多播组（即使用 MSI-X 和 RSS，我可以）以高速率接收小型 UDP 多播数据报（主要是 100-400 字节）扩展到多个内核），对每个数据包进行一些处理，然后将其发送出去。通过 TCP 发送我设法达到了我需要的程度（6.4Gb/秒）而没有撞墙，但是以高 pps 速率接收数据报却成了一个问题。

在最近对 Windows 2012 R2 上带有 2 端口 10Gb 以太网 NIC 的高规格 NUMA 机器进行的测试中，我每秒只能接收数十万个 UDP 数据报（早期丢弃，即没有实际处理数据，使用 2x12 内核从等式中删除我的应用程序的处理开销以查看它的速度有多快，并且测试的 12 个多播组的内核部分似乎分布在一个 NUMA 节点的 8 或 10 个内核上（设置了最大 RSS 队列）到 16) - 尽管使用 .net 应用程序，因此本机应用程序应该能够运行得更快。

但即使是Len Holgate 在他的高性能 Windows RIO 测试中也只能以 500kpps 的速度接收 UDP 数据包，使用 1024 字节的 UDP 负载。

在QLogic 的白皮书（未提及被测操作系统）中，“多线程超小数据包路由”（包括接收和后续发送？）的限制设置为5.7Mpps。在关于Linux 网络的文章中，限制设置为每个内核1Mpps 到 2Mpps（据报道或多或少线性地扩展），或者甚至是15Mpps，使用绕过内核的特殊解决方案。

例如网络地图

可以在10GigE 链路上以线速 ( 14.88Mpps )生成流量，只需一个以 900Mhz 运行的内核。这相当于每个数据包大约 60-65 个时钟周期，并且可以很好地扩展内核和时钟频率（4 个内核，线速低于 450 MHz）。接收端也达到了类似的速率。

那么我可以使用（最新版本的）Windows / Windows Server 多远，特别是接收 UDP 多播，如前导段落中所述？

编辑有一篇关于如何在 Linux 上执行此操作的 cloudflare 博客文章 - 和一个有趣的评论部分：如何每秒接收一百万个数据包，以及相应的黑客新闻评论页面。

Answer 1

根据微软的说法，他们实验室的测试表明，在RIO 的“早期测试中的特定服务器上” ，他们能够处理

• 2Mpps在 Windows Server 2008R2 中没有损失，即没有 RIO
• 4Mpps 在（预发布）Windows Server 8 上使用 RIO

该视频的屏幕截图 (44:33)：

所以我的问题的答案Is it possible to process millions of datagrams per second with Windows?是：是的，显然它甚至在 RIO 之前，在 Windows Server 2008R2 中。

但是，除了官方数据，尤其是未发布的软件的数据之外，必须小心翼翼，仅凭本演示文稿中提供的稀疏信息，关于测试以及如何正确解释结果的许多问题仍然存在。最相关的是：

1. 是发送的数字吗？接收？或者也许用于路由（即接收+发送）？
2. 什么数据包大小？-> 可能是最低的，通常在试图让 pps 数字吹嘘时这样做
3. 多少个连接（如果是 TCP）/数据包流（如果是 UDP）？-> 可能是分配工作负载所需的数量，以便可以使用所有存在的核心
4. 什么测试设置？机器和 NIC 规格和接线

第一个是至关重要的，因为发送和接收需要不同的步骤，并且可以显示出显着的性能差异。对于其他数字，我们可以假设在高规格机器上使用最低数据包大小，每个核心至少有一个连接/数据包流，以获得最大可能的 Mpps 数据。

编辑我刚刚偶然发现了一份关于 Linux上高性能数据包处理的英特尔文档，据此，（Linux）

平台可维持每秒约 200 万笔交易的交易速率

使用标准 Linux 网络堆栈（在具有 2x8 内核的物理主机上）。此请求/回复测试中的事务包括

1. 接收UDP数据包
2. 该数据包的后续转发

（使用 netperf 的网络服务器）。该测试并行运行 100 个事务。论文中有更多细节，感兴趣的朋友可以看看。我希望我们有这样的东西供 Windows 比较......无论如何，这是该请求/回复测试最相关的图表：

Answer 2

太长了；博士

为了给出明确的答案，似乎需要更多的测试。但间接证据表明 Linux 是实际上专门用于超低延迟社区的操作系统，它也经常处理 Mpps 工作负载。这并不意味着 Windows 不可能做到这一点，但 Windows 可能会落后相当多，尽管有可能达到 Mpps 数字。但这需要通过测试来确定，例如弄清楚需要多少（CPU）成本才能实现这些数字。

注意这不是我打算接受的答案。它的目的是为任何对这个问题的答案感兴趣的人提供一些关于我们的立场以及进一步调查的地方的提示。

据 google 称，Len Holgate 似乎是唯一测试 RIO 以从 Windows 网络中获得更多性能的人（并发布了结果），他刚刚在其博客的评论中澄清说，他使用的是单个 IP/端口组合用于发送 UDP 数据包。

换句话说，他的结果应该在某种程度上与 Linux 上的测试中的单核数据相当（尽管他使用 8 个线程 - 在尚未检查他的代码的情况下，这似乎对仅处理单个 UDP 数据包流而不是处理单个 UDP 数据包流时的性能有害）对数据包进行任何繁重的处理，他提到实际上只使用了很少的线程，这是有道理的）。尽管他说：

我并没有那么努力地获得最大性能，只是为了比较新旧 API 之间的相对性能，因此我的测试并没有那么彻底。

但是，除了“努力”之外，还有什么是为了更粗糙的 RIO 世界而放弃标准 IOCP 的（相对）舒适区呢？至少就单个 UDP 数据包流而言是这样。

我猜他的意思是——正如他在几次 RIO 测试中尝试了各种设计方法一样——他没有微调 NIC 设置来挤出最后一点性能。例如，在接收缓冲区大小的情况下，这可能会对 UDP 接收性能和数据包丢失数字产生巨大的积极影响。

然而，当尝试直接将他的结果与其他 Linux/Unix/BSD 测试的结果进行比较时，问题是：大多数测试在尝试推动“每秒数据包”边界时，使用尽可能小的数据包/帧大小，即以太网64字节的帧。Len 测试了 1024 字节数据包（-> 1070 字节帧），这（特别是对于 No-Nagle UDP）可以让您获得更高的“每秒比特数”数字，但可能无法像较小的数据包那样推动 pps 边界。因此，按原样比较这些数字是不公平的。

总结到目前为止我对 Windows UDP 接收性能的探索结果：

• 在尝试开发超低延迟和/或高吞吐量应用程序时，没有人真正使用 Windows，现在他们正在使用 Linux
• 现在几乎所有带有实际结果的性能测试和报告（即不仅仅是产品广告）都是在 Linux 或 BSD 上进行的（感谢 Len 作为先驱，给我们至少提供了一个参考点！）
• Windows 上的 UDP（标准套接字）比 Linux 上更快/更慢吗？我还不能确定，必须自己测试
• Windows 上的高性能 UDP（RIO 与 netmap）比 Linux 上更快/更慢吗？Linux可以使用 900MHz 的单核轻松处理全 10Gb 线路速度，Windows 在已发布的最佳情况下对于 1024 的大 UDP 数据包大小能够达到 43% 或 492kpps，即较小大小的 bps 数字可能会显着增加更糟糕的是，尽管 pps 数字可能会上升（除非中断处理或其他一些内核空间开销是限制因素）。

至于他们为什么使用 Linux，那一定是因为开发涉及内核更改（如 netmap 或 RIO）的解决方案（将性能推向极限时所必需的）对于像 Windows 这样的封闭系统几乎是不可能的，除非您的薪水恰好来自雷蒙德，或者您与 Microsoft 签订了一些特殊合同。这就是为什么 RIO 是 MS 产品。

最后，举几个极端的例子来说明我在 Linux 领域曾经和正在发生的事情：

早在 15 年前，一些设备就使用800 mHz Pentium III CPU、 1GbE NIC 上的133 mHz 前端总线接收 680kpps 的速度。 编辑：他们使用Click，这是一个内核模式路由器，它绕过了许多标准网络堆栈，即他们“作弊”。

2013年，Argon Design成功获得

勾选交易延迟低至 35ns [纳秒]

顺便说一句，他们还声称

目前绝大多数现有的交易计算代码都是针对 x86 处理器架构上的 Linux 编写的。

Argon 使用Arista 7124FX 交换机，该交换机（除了 FPGA 之外）还有一个操作系统

构建在标准 Linux 内核之上。