socket与Linux TCP_读写socket 要互斥吗-CSDN博客

本文链接：https://blog.csdn.net/dog250/article/details/124992654

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

填满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);
}