TCP 的 send 函数 tcp_sendmsg/tcp_sendpage,要调用 lock_sock(sk)。

TCP 的 recv 函数 tcp_recvmsg,也要调用 lock_sock(sk):
void lock_sock_nested(struct sock *sk, int subclass) { might_sleep();
spin_lock_bh(&sk->sk_lock.slock); if (sk->sk_lock.owned) __lock_sock(sk);
sk->sk_lock.owned = 1; spin_unlock(&sk->sk_lock.slock); /* * The sk_lock has
mutex_lock() semantics here: */ mutex_acquire(&sk->sk_lock.dep_map, subclass,
0, _RET_IP_); local_bh_enable(); }
__lock_sock 的核心即睡眠等锁。

这意味着 TCP socket 的 send 和 recv 互斥。睡眠等锁期间,CPU 时间不属于该 socket。

不光如此,软中断上下文 tcp_v4_rcv 处理 TCP 接收间,无论 send 还是 recv 均会在一个 spinlock 自旋,这意味着软中断
TCP 接收间,send 无法进行,recv 亦无法读取已按序齐整排入 receive queue 的数据。

这就是我常说的,TCP 称全双工传输,但 Linux TCP 实现却是半双工。我并不认为这是高尚的:
Linux TCP并不是全双工的

很多人怼我,说我根本不懂双工的概念,涉及到物理层,信道。我想他们并没有理解我在说什么。再解释也苍白,引用 iperf-2.0.14a 的 manual
来解释 socket 双工:

–full-duplex
run a full duplex test, i.e. traffic in both transmit and receive directions
using the same socket

在我看来,高尚的做法是只保护读写共享的数据,细化锁粒度:

* sk_write_queue:发送队列,socket 进程上下文写入,tcp_write_xmit 进程上下文或软中断上下文摘除。
* tcp_rtx_queue:重传队列,socket 进程上下文或软中间上下文写入,tcp_clean_rtx_queue 软中断上下文摘除。
* sk_receive_queue:接收队列,socket 进程上下文 release_sock 或软中断上下文写入,socket 进程上下文摘除。
保护好这些数据结构,再小心翼翼处理一下其它共享元数据,send/recv/tcp_v4_rcv 即可并行。事情会高尚很多。

迄今为止,我想因为 Linux TCP 单机性能尚未触及瓶颈,拆锁重构工作量成本不小,却没有眼见的收益,社区没人闲着做这事。如今 100 Gbps
网卡越来越多,这些细节早晚会被盯上。

但还有一条路,若 DPDK 可实现好用的 TCP,内核协议栈可能就这么放着永远不动了:

* DPDK 提供高性能版本 TCP。
* Kernel 提供通用完备 TCP。
外说一句,曾经 UDP 也是类似 lock_sock,可能也是因为一把梭哈实现简单,后面随着 UDP 应用逐步推广,可能是 QUIC 加持也可能不是,UDP
的 lock_sock 消失了,锁粒度细化到保护特定的共享 queue,最终,连 queue 都拆成了两个,便于批量处理:

* Linux内核UDP收包为什么效率低?能做什么优化?
* Linux内核UDP收包为什么效率低?能做什么优化?
这也是历史发展的轨迹。

弄蟹!80块钱弄蟹,两大四小。

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

技术
今日推荐
阅读数 7017
阅读数 2018
阅读数 1515
阅读数 1303
阅读数 1303
阅读数 1134
下载桌面版
GitHub
百度网盘(提取码:draw)
Gitee
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:766591547
关注微信