如何每秒接收一百万个数据包(2015)

2020-06-06 10:34:11

上周,在一次随意的谈话中,我无意中听到一位同事说:Linux网络堆栈太慢了!您不能指望每个内核每秒处理的数据包超过5万个!

这让我开始思考。虽然我同意每个内核50kpps可能是任何实际应用程序的极限,但是Linux网络堆栈能做什么呢?让我们重新表述一下,让它变得更有趣:

在Linux上,编写每秒接收100万个UDP数据包的程序有多难?

希望回答这个问题能给我们上一堂关于现代网络堆栈设计的好课。

测量每秒数据包数(PPS)比测量每秒字节数(Bps)有趣得多。您可以通过更好的流水线和发送更长的数据包来实现高bps。提高PPS的难度要大得多。

由于我们对PPS很感兴趣,我们的实验将使用短UDP消息。准确地说:32字节的UDP有效负载。这意味着以太网层上有74个字节。

它们都有两个6核2 GHz Xeon处理器。在启用超线程(HT)的情况下,每个机箱上最多有24个处理器。这些盒子配备了Solarflare的多队列10G网卡,配置了11个接收队列。稍后再讲。

让我们的UDP数据包使用端口4321。在开始之前,我们必须确保流量不会受到iptables的干扰:

接收器$iptables-i输入1-p UDP--dport 4321-j ACCET接收器$iptables-t RAW-I预处理1-p udp--dport 4321-j NOTRACK。

接收方$for i in`seq 1 20`;do\IP addr add 192.168.254.$i/24 dev eth2;\donesender$IP addr add 192.168.254.30/24 dev eth3。

首先,让我们做一个最简单的实验。一次简单的发送和接收将发送多少个数据包?

FD=SOCKET.Socket(SOCKET.AF_INET,SOCKET.SOCK_DGRAM)fd.bind((";0.0.0.0";,65400))#选择源端口以降低nondeterminismfd.connect((";192.168.254.1";,4321)),而TRUE:fd.sendmmsg([";\x00";*32]*1024)。

虽然我们可以使用通常的“发送系统调用”,但它的效率不会很高。上下文切换到内核是有代价的,最好避免。幸运的是,Linux最近添加了一个方便的syscall:sendmmsg。它允许我们一次发送许多数据包。让我们一次处理1024个包吧。

发送方$./udpsender 192.168.254.1:4321接收方$./udproceiver1 0.0.0.0:4321 0.352M PPS 10.730MiB/90.010Mb 0.284M PPS 8.655MiB/72.603Mb 0.262M PPS 7.991MiB/67.033Mb 0.199M PPS 6.081MiB/51.013Mb 0.195M PPS 5.956MiB/49.966Mb。

使用幼稚的方法,我们可以在197K到350K PPS之间完成。还不算太糟。不幸的是,有相当多的可变性。它是由内核在内核之间混洗我们的程序造成的。将进程固定到CPU将有所帮助:

发送方$taskset-c 1./udpsender 192.168.254.1:4321接收方$taskset-c 1./udproceiver1 0.0.0.0:4321 0.362M PPS 11.058MiB/92.760Mb 0.374M PPS 11.411MiB/95.723Mb 0.369M PPS 11.252MiB/94.389 Mb 0.370M PPS 11.289MiB/94.696Mb 0.365

现在,内核调度器将进程保留在定义的CPU上。这提高了处理器缓存的局部性,并使数字更加一致,这正是我们想要的。

虽然37万PPS对于一个幼稚的程序来说是不错的,但它离1Mpps的目标还有相当大的距离。要接收更多,首先我们必须发送更多数据包。从两个线程独立发送怎么样:

发送方$taskset-c 1,2./udpsender\192.168.254.1:4321 192.168.254.1:4321接收方$taskset-c 1./udproceiver1 0.0.0.0:4321 0.349M PPS 10.651MiB/89.343Mb 0.354M PPS 10.815MiB/90.724Mb 0.354M PPS 10.806MiB/90.646Mb 0.354M PPS 10.811M。

接收方的人数并没有增加。ethtool-S将揭示数据包的实际去向:

接收者$WATCH';sudo ethtool-S eth2|grep rx';rx_nodesc_drop_cnt:451.3k/s rx-0.rx_Packets:8.0/s rx-1.rx_Packets:0.0/s rx-2.rx_Packets:0.0/s rx-3.rx_Packets:0.5/s Rx-4.rx_Packets:355.2k/s Rx-5.rx_Packets:0.0/s Rx-6.rx_Packets:0.0/s Rx-7.rx_Packets:0.5/s RX-。.rx_Packets:0.0/s Rx-9.rx_Packets:0.0/s Rx-10.rx_Packets:0.0/s。

通过这些统计信息,NIC报告它已成功将大约350kpps传输到4号RX队列。rx_nodesc_drop_cnt是一个特定于Solarflare的计数器,表示NIC无法将450kpps传输到内核。

有时候,包裹没有送到的原因并不明显。不过,在我们的例子中,情况非常清楚:RX队列#4将数据包发送到CPU#4。而CPU#4不能再做任何工作-它完全忙于读取350kpps。下面是它在HTOP中的样子:

过去,网卡只有一个RX队列,用于在硬件和内核之间传递数据包。这种设计有一个明显的限制--它不可能传送超过单个CPU所能处理的更多的数据包。

为了利用多核系统,NIC开始支持多个RX队列。设计很简单:每个RX队列都固定在单独的CPU上,因此,通过将数据包传输到所有RX队列,NIC可以利用所有CPU。但这也提出了一个问题:给定一个数据包,网卡如何决定将其推送到哪个RX队列?

循环平衡是不可接受的,因为它可能会导致单个连接内的数据包重新排序。另一种选择是使用来自分组的散列来决定RX队列号。散列通常从元组(源IP、DST IP、源端口、DST端口)计算。这保证了单个流的分组将始终在完全相同的RX队列上结束,并且单个流中的分组的重新排序不会发生。

Receiver$ethtool-n eth2 rx-flow-hash udp4UDP over IPv4 FLOWS使用以下字段计算哈希流密钥:IP Saip DA。

这表示为:对于IPv4 UDP数据包,NIC将散列(源IP、DST IP)地址。即:

这相当有限,因为它忽略端口号。许多NIC允许自定义散列。同样,使用ethtool,我们可以选择要散列的元组(src ip、dst ip、src port、dst port):

接收方$ethtool-N eth2 rx-flow-hash udp4 sdfn无法更改RX网络流散列选项:不支持操作。

不幸的是,我们的NIC不支持它-我们只能使用(src IP,dst IP)散列。

到目前为止,我们的所有数据包流到一个RX队列,并且只命中一个CPU。让我们以此为契机,对不同CPU的性能进行基准测试。在我们的设置中,接收主机有两个独立的处理器组,每个处理器组是一个不同的NUMA节点。

我们可以将单线程接收器固定到我们设置的四个有趣的CPU中的一个。这四个选项是:

在另一个CPU上运行Receiver,但在与RX队列相同的NUMA节点上运行。我们在上面看到的性能大约是360kpps。

当接收器与RX队列在完全相同的CPU上时,我们可以达到~430kpps。但它创造了高度的可变性。如果NIC因数据包而不堪重负,则性能会降至零。

当接收器在处理RX队列的CPU的HT上运行时,在200kpps左右的性能是通常的一半。

当接收器位于与RX队列不同的NUMA节点上的CPU上时,我们可以获得约33万PPS。不过,这些数字并不太一致。

虽然在不同的NUMA节点上运行10%的损失听起来并不太糟糕,但随着规模的扩大,问题只会变得更严重。在一些测试中,我每个内核只能挤出250kpps。在所有的交叉NUMA测试中,可变性都很差。跨NUMA节点的性能损失在吞吐量较高时更为明显。在其中一个测试中,当在坏的NUMA节点上运行接收器时,我得到了4倍的惩罚。

由于我们NIC上的散列算法非常有限,因此跨RX队列分发数据包的唯一方法是使用多个IP地址。以下是如何将数据包发送到不同的目的IP:

接收者$WATCH';sudo ethtool-S eth2|grep rx';rx-0.rx_Packets:8.0/s Rx-1.rx_Packets:0.0/s Rx-2.rx_Packets:0.0/s Rx-3.rx_Packets:0.0/s Rx-3.rx_Packets:355.2k/s Rx-4.rx_Packets:0.5/s Rx-5.rx_Packets:297.0k/s Rx-6.rx_Packets:0.0/s Rx-7.rx_Packets:0.5/s Rx-8.rx_Packets:0.0/s RX-9。.rx_Packets:0.0/s rx-10.rx_Packets:0.0/s

Receiver$taskset-c 1./udproceiver1 0.0.0.0:4321 0.609M PPS 18.599MiB/156.019Mb 0.657M PPS 20.039MiB/168.102Mb 0.649M PPS 19.803MiB/166.120Mb。

万岁!当两个内核忙于处理RX队列,第三个内核运行应用程序时,有可能获得~650K PPS!

我们可以通过将流量发送到三个或四个RX队列来进一步增加这个数字,但很快应用程序将达到另一个限制。这次rx_nodesc_drop_cnt没有增长,但netstat";接收器错误是:

接收方$watch';netstat-s--udp';udp:437.0k/s数据包接收到0.0/s未知端口接收的数据包。386.9k/s数据包接收错误0.0/s数据包发送接收错误:123.8k/s SndbufErrors:0 InCsumErrors:0。

这意味着,虽然NIC能够将数据包传送到内核,但内核无法将数据包传送到应用程序。在我们的示例中,它只能提供440kpps,其余的390kpps+123kpps由于应用程序接收速度不够快而被丢弃。

我们需要横向扩展接收器应用程序。天真的方法,从许多帖子接收,不能很好地发挥作用:

发送方$taskset-c 1,2./udpsender 192.168.254.1:4321 192.168.254.2:4321接收方$taskset-c 1,2./udproceiver1 0.0.0.0:4321 2 0.495M PPS 15.108MiB/126.733Mb 0.480M PPS 14.636MiB/122.775Mb 0.461M PPS 14.071MiB/118.038Mb 0.486M PPS 14.8MiB。

与单线程程序相比,接收性能较低。这是由UDP接收缓冲区端的锁定争用引起的。由于两个线程使用相同的套接字描述符,因此它们花费不成比例的时间争夺UDP接收缓冲区周围的锁。这篇文章更详细地描述了这个问题。

幸运的是,Linux最近添加了一个解决方法:SO_REUSEPORT标志。当在套接字描述符上设置此标志时,Linux将允许许多进程绑定到同一端口。事实上,将允许绑定任意数量的进程,并且负载将分散在它们之间。

使用SO_REUSEPORT,每个进程都将有一个单独的套接字描述符。因此,每个都将拥有一个专用的UDP接收缓冲区。这避免了以前遇到的争用问题:

Receiver$TASKSET-c 1,2,3,4./udproceiver1 0.0.0.0:4321 4 1 1.114M PPS 34.007MiB/285.271Mb 1.147M PPS 34.990MiB/293.518Mb 1.126M PPS 34.374MiB/288.354 Mb。

更多的调查将揭示进一步改进的空间。尽管我们启动了四个接收线程,但负载并未在它们之间均匀分布:

两个线程接收了所有工作,另外两个线程根本没有收到任何数据包。这是由散列冲突引起的,但这一次是在SO_REUSEPORT层。

我已经做了一些进一步的测试,在单个NUMA节点上使用完全对齐的RX队列和接收器线程,可以获得1.4Mpps。在不同的NUMA节点上运行Receiver会导致数字下降,最多只能达到1Mpps。

确保流量均匀分布在多个RX队列和SO_REUSEPORT进程中。实际上,只要有大量的连接(或流),负载通常是均匀分布的。

您需要有足够的空闲CPU容量才能实际从内核拾取数据包。

为了使事情变得更加困难,RX队列和接收器进程都应该位于单个NUMA节点上。

虽然我们已经展示了在Linux机器上接收1Mpps在技术上是可能的,但应用程序并没有对接收到的数据包进行任何实际处理-它甚至没有查看流量的内容。在没有更多工作的情况下,不要指望任何实际应用程序都会有这样的性能。

对这种低级别、高性能的数据包争论感兴趣吗?CloudFlare正在伦敦、旧金山和新加坡招聘。

Linux技术谈深度潜水