每秒如何接收上百万数据包

摘要
在Linux系统中，写一个能每秒接收1000000 UDP数据包的程序有多难？
linux

数据
多线程

原文链接：How to receive a million packets per second
译文链接：每秒如何接收上百万数据包
译者：曾越

上周聊天的时候，我无意间听到一个同事说："Linux网络堆栈（Linux network stack）太慢了！你不能指望它用一个CPU每秒处理50000个以上的数据包！"

这引发了我深深的思考。我认同每个核心50kpps对任何实际的应用来说可能就是极限了，但Linux网络堆栈的能力只是如此吗？让我们换个角度来更有趣的叙述这件事。

在Linux系统中，写一个能每秒接收1000000 UDP数据包的程序有多难？

我希望，回答这个问题的过程，也能成就一篇关于现代网络堆栈设计的优秀教程。




CC BY-SA 2.0
image by
Bob McCaffrey

首先，让我们假设：
● 测量数据包每秒（packets per second 缩写pps）比测量字节每秒（bytes per second简写Bps）更有意义。你可以通过优化管道（piplelining）和发送更长的数据包来实现高Bps。但提高pps比这难得多。

● 既然我们对pps更感兴趣，我们的实验将会使用短UDP消息（short UDP messages）。更准确的说：32字节的UDP负载（UDP payload）。在以太网层（Ethernet layer）中是74字节。

● 在实验中我们会使用两个物理服务器：接受端（receiver）和发送端（sender）。

● 它们都配有2个6核2GHz的Xeon处理器。如果在每个核心上启用超线程技术（hyperthreading），则可分别模拟24个处理器。核心有一块Solarflare公司的多队列10G网卡（multi-queue 10G network card），已经配置了11个接收队列（receive queue）。更详细的之后讨论。

● 测试程序的源码可以从这里得到：

udpsender， udpreceiver。

准备 Prerequisites

4321端口给UDP数据包。在开始之前，我们必须确保通信不会被iptables干扰。

为了一会儿方便，先定义一些具体的的IP地址：

1.简单方法 The naive approach

一开始先让我们做个最简单的实验。一次简单的发送和接收会传递多少个数据包呢？
发送者的伪代码：

尽管我们可以使用常用的send系统调用，但它并不高效。内核的上下文切换将会有不小的消耗，最好极力避免它。幸运的是，一个方便的系统调用最近被加入到了Linux中：sendmmsg。它允许我们一次发送大量的数据包。让我们来试试1024个数据包。
接受者的伪代码：

类似地，
recvmmsg也是recv系统调用的高效版本。
让我们试一试：

使用这种简单方法，我们可以达到197kpps和350kpps之间。不算太糟。不幸的是，并不稳定。内核会使我们的程序在CPU核心之间shuffle。给CPU固定进程会有些作用：

现在，内核调度程序（kernel scheduler）把进程固定在指定的CPU上了。这改善了处理器缓存本地化（processor cache locality），使数据更稳定，这正是我们想要的。

2.发送更多的数据包 Send more packets

虽然370k pps对简单的程序并不算太糟，但离1Mpps的目标还很远。接受更多必然要发送更多。用2个独立的线程发送试试：

接受端的数量并没有增长。ethtool –S命令可以展示数据包的去向：

通过以上统计，NIC说明成功传递大约350kpps到RX-4号队列。 rx_nodesc_drop_cnt 是一个Solarflare公司特制的计数器，它报告NIC传送到内核时丢失450kpps。有时数据包传送失败的原因很隐晦。在我们的例子里它倒是很显眼：RX-4号队列传送数据包到CPU#4。CPU#4除了读取这350kpps的数据外，已经什么都做不了了。在htop中看看效果：





多队列NIC速成 Crash course to multi-queue NICs

传统地，网卡有一个用于在硬件和内核间传递数据包的RX队列。这个设计有明显的局限性——数据包的传送量不能超过一个CPU的处理上限。为了更好的利用多核系统，NIC开始支持多RX队列。设计很简单：每一个RX队列绑定一个单独的CPU，这样传送数据包给所有的RX队列，NIC就可以利用所有的CPU资源。但有一个问题：给定一个数据包，NIC如何确定推送到哪一个RX队列呢？





不能使用Round-robin均衡，因为它可能会把一个连接中的数据包重排序。一个替代方案是：通过数据包的hash来决定RX队列。hash来自元组（源IP，目的IP，源端口，目的端口）。这能保证一个流中的数据包总是在同一个RX队列中结束，不可能发生某个流中的数据包重排序。

在我们的例子中，hash可以这样使用：

多队列哈希算法 Multi-queue hashing algorithms

哈希算法可以使用ethtool设置。我们的设置如下：

以上的意思是：对IPV4的UDP数据包，NIC将计算哈希（源IP，目的IP）地址。例如：

因忽略了端口参数，这相当受限。大部分NIC允许自定义哈希方法。再使用ethtool选择元组（源IP，目的IP，源端口，目的端口）计算哈希：

不幸的是，我们的NIC不支持——我们只好使用受限的（源IP,目的IP）哈希。

非一致性内存访问性能注意事项 A note on NUMA performance

目前为止，我们所有的数据流都分配给了一个RX队列，并且只匹配一个CPU。让我们以此为基础，来试试多CPU。在我们的配置中，接收端主机有两个单独的进程“仓库“，它们各是一个NUMA节点。

我们将一个单线程接收端固定到4个CPU中的1个。四种情况分别是：

1.在另一个CPU上运行接收端，但在同一个用于RX队列的NUMA节点上。如上文所述，性能大概是360kpps。

2.使用同一个用于RX队列的CPU，性能大约是430kpps。但这很不稳定。如果NIC被数据包淹没了，性能可能会为0。

3.当接收端运行在处理RX队列的CPU的HT部分，性能大概是平时的一半，也就是200kpps。

4.当接收者在CPU和RX队列分别在不同的NUMA节点运行时，我们得到大致330kpps的数值。虽然这个数字不总是一致。

尽管在不同NUMA节点上运行时， 10%的性能损失（penalty）似乎并不是太糟，但真正的问题是在扩展的时候。在一些测试场景中，我只能得到250kpps的结果。在所有跨NUMA的测试中，都很不稳定。跨NUMA节点的性能损失在高吞吐量场景中更常见。一次测试时，接收端运行在一个糟糕的NUMA节点上，我遭遇了4倍的性能损失。

3.多重接收IP Multiple receive IPs

因为哈希算法在我们的NIC上受限，唯一的解决方法是：跨RX队列，把数据包分发到不同的IP地址。下面是如何发送数据包到不同的目的IP：

使用ethtool确保数据包分配给不同的RX队列：

接收部分：

万岁！两个核心全力处理RX队列，第三个运行应用，已达到了650Kpps！

将流量分发到3-4个RX队列就可以进一步增加这个数字，但应用会遇到另一个瓶颈。这次rx_nodesc_drop_cnt没有增长，对应的netstat“接收者错误”：

上面这段话指出，虽然NIC能够传递数据包给内核，但内核不能够将数据包发送给应用。在我们的例子中，只成功发送了440kpps，其余的390kpps+123kpps被丢弃了，因为应用不足以接收他们。

4. [b]多线程接收 Receive from many threads [/b]

我们需要扩展接收端应用的能力。最初的、多线程的接收方法不会再有效了：

接收性能相比单线程程序要低。是因为在UDP接收缓冲区（UDP receive buffer side）出现的锁竞争（lock contention）。因为所有的线程使用同一个socket描述符（socket descriptor），它们在从UDP接收缓冲区获得锁的步骤上花费了不相称的时间（disproportionate amount of time）。

这里详细描述了这个问题。
使用多线程从一个描述符接收数据并不理想。

5. SO_REUSEPORT

幸运的是，最近有一项成果增加到了Linux中：SO_REUSEPORT标志位。当在socket描述符上设置这个标志位时，Linux会允许多个进程绑定在同一个端口上。真实情况是，无论多少进程都将被允许绑定，且负载会被分担。

设置 SO_REUSEPORT 的每个进程都会有一个独立的socket描述符。因此他们得到了一个专属UDP接收缓存（dedicated UDP receive buffer）。这就避免了之前遇到的竞争问题。

这才像样！吞吐量现在不错了！

如果你继续研究，还会有更大的改进空间。即使我们开了4个接收线程，负载也没有被平均分配到上面。

2个线程接收了所有的数据，另外2个没有获得数据包。这应该是哈希冲突造成的，但这次问题出在SO_REUSEPORT 层。

结语 Final words

我又做了一些额外测试，完美的分配RX队列并将所有的接收线程都运行在一个NUMA节点上的话，可以达到1.4Mpps的性能。接收者运行在不同的NUMA节点上，即使性能略有下降，但也完成了1Mpps的目标。

总结一下，如果你想要完美的性能，你需要：

● 保证流量被均分到每一个RX 队列和SO_REUSEPORT进程上。实践中，只要有大量的连接（流）负载，通常它们是能均匀分布的。

● 你需要有足够的空闲CPU才能从内核中获取数据包。

● 为了使性能更棒，RX队列和接收进程应该在一个NUMA节点上。

我们证实了，技术上讲，在Linux机器上接收1Mpps是可能的，应用并没有做任何处理接收数据包的工作——它甚至也不关注流的内容。实际的应用中，为了达到这样的性能，还是需要做大量工作的。

-------------------好久不见的分割线-------------------

如果您发现这篇译文的任何问题，可随时与我们联系。

我们水平有限，但理想高远。我们旨在分享优质的内容。

我们也同样期待理想的您对这个世界的贡献。欢迎任何目的的联系。

我们的邮箱是：weikan@jointforce.com。

我们的QQ是：3272840549。

[转载请保留原文出处、译者和审校者。

可以不保留我们的链接]