socket与Linux TCP

Posted 2022-05-27 dog250

继续填满长肥管道，接上回：

填满TCP长肥管道

修正了TCP流控rwnd算法后，吞吐就与RTT和rcvbuff解耦了，它的值就是横截面：

buffer的目的是平滑到达和处理之间的gap而不再作为“要被填满的批量搜集站”，好处至少两点：

• 解决了rcvbuffer的bufferbloat，就平滑了主机处理延时抖动。
• 数据读取速率直接取决于CPU而不是rcvbuffer的配置。

但关于这个buffer，又有另一个问题。这个问题可能就是损失那2Gbps(理论25Gbps，实际23Gbps)的祸首。

之前说过，Linux TCP非全双工，socket读写不能(多CPU)并行，ACK和触发发送不能并行，除了这些，软中断Data收和进程socket收也不能并行。

换句话说软中断和socket无法同时将数据放入receive queue和从中取走数据。

无论TCP软中断处理还是socket收，都直接lock或own整个socket，造成软中断和socket进程的串行处理。具体参考Linux内核协议栈的backlog实现。

lock或own整个socket显然粒度太粗，需要lock的只是TCP连接的元数据。

Linux UDP之前也有这个问题，但UDP本身无状态，也就元数据需要保护，针对Linux UDP的优化一气呵成，可参见2019年的一篇文章：

Linux内核UDP收包为什么效率低？能做什么优化？

给出一个UDP双队列优化后的图示：

Linux TCP也需要类似的双队列buffer，两个队列原子转移，深入细致地管理这个双队列buffer，目的是软中断往buffer放数据的同时，socket可在另一个CPU上从buffer取数据。

这才真正实现TCP协议栈到进程并行流式交接，buffer作为平滑适配器而不是批量搜集站，这是真正的排队系统，socket就像网络中继转发节点，将数据从TCP转交给进程。

如昨天文中所说，进程不一定是最后一站，可能还要落盘，IO库，文件系统，磁盘buffer也依然要如是转交。
话回正途，Linux TCP拆解这个socket lock范围很难，我尝试将receiveve queue独立出来，但socket读也要独立才行，最终失败。

退而求其次，在socket读频率和每次读取的数量之间找一个平衡点。SO_LOWAT正好做这事，但iperf工具不支持该sockopt，可以用LD_PRELOAD来做，也可以用stap：

#!/usr/local/bin/stap -g

%
#include <net/tcp.h>
%

function alter_lowat(skk:long)
%
	struct sock *sk = (struct sock *)STAP_ARG_skk;

	if (inet_sk(sk)->inet_num == 5001 && sk->sk_rcvlowat == 1) 
		sk->sk_rcvlowat = 65500*2;
		STAP_PRINTF("%d\\n", sk->sk_rcvlowat);
	
%

probe kernel.function("tcp_data_ready")

	alter_lowat($sk);

意思是buffer里至少攒够了65500*2字节数据后才wakeup进程。保持相同的速率，CPU利用率下降20%。

此外就是调节系统调度器了，我们追求的目标是软中断将n字节放入receive queue和socket从receive queue中读n字节这两件事交替进行，但这几乎做不到：

• GRO/LRO必须开启，ACK过多会抑制发送。
• GRO/LRO无法确定数据包长度。
• Linux软中断无法精确控制pacing。
• wakeup收包进程无法保证它立即运行。

不过25Gbps尚未touch到CPU瓶颈，若100Gbps打进主机，恐怕上述问题就必须考虑了，由于Linux内核本身是一个复杂的控制面，跑100Gbps注定会吃力，任何wakeup模式因调度延时不确定而不能信任，busy poll模式就更加适合。不过这些都是后话。

终于还是避不开TCP单机性能的损失，核心问题不是调度系统调优，如果真去那般做，可能路子本身就是错的，内核本是一个控制面，内核协议栈跑数据面尚且还好因为尚未touch到CPU瓶颈，但随着带宽持续演进，早晚会touch到CPU瓶颈。作一短文，备忘。

浙江温州皮鞋湿，下雨进水不会胖。

开发者涨薪指南 48位大咖的思考法则、工作方式、逻辑体系