TCP Segment Offload(TSO)的实现原理浅析

简介:
早上太燥热,突然想起三周前有人跟我交流了TSO的问题,我也描述了其原理,这个原理说来也是特别简单,无非就是靠网卡硬件来分段,计算 checksum,从而解放CPU周期。其实只要说一个就够了,既然靠硬件来分段,那么只能由硬件来计算checksum了,因为你根本就不知道硬件的分 段细节,所以你也没法在分段前计算好每一个段的checksum....
       TSO的原理几乎每个人都知道,事实上它是怎么实现的这个问题也不难,难的是细节。在做完了正事之后,我想把这个原理展现出来,当然可能和实际的实现有超级大的出入,不管怎样,它是一个原理框图,仔细观察,应该也能自己实现一个比我这个更好的TSO了。
       这个设计是一个数字逻辑,时序电路的范畴,而这个领域十分地高大上,并不是普通的软件程序员能hold住的,像我这样的半瓶子也一样。所以我依然是按照老 样子,试图直接给出一个结果,而不是要求听书的人事先做一些准备,往往在人们做这些准备工作的时候,就已经厌倦放弃了。
       基础知识不难,就是一些门电路,与门,非门,比较器,译码器,触发器之类的,这些东西随便找一本计算机组成原理,都很齐全。关键是怎么组合它们,这是另一 个领域的编程。此时,我想起了15年前我的高中物理老湿刘丹青在讲电路的时候说过的一句话:让电流流一下。这句话在科班人看来完全不符合电路设计的基本原 则,他们可能更倾向于首先建模,然后分析,然后使用描述语言VHDL写出代码,最后再给出电路,我觉得这适合于设计本身,但是不适合于对一个门外汉讲述其 精彩。对于一个门外汉来讲,他唯一所知道的就是,让电流流一下,然后冲过这个门,冲过那个管,好了,高电平变成低电平了....在我看来,就是这么回事。
       在一张白纸上,画出一堆的门电路,然后随性随意组合它们,慢慢的,我突然发现,这个电路就是TSO的框架了。我记得上周帮人固化了路由转发表,然而那种固 化行为可能会因为成本过高而被pass掉,毕竟如今的软实现已经够用了吧。所以只有核心传输网才需要这种固化的转发表,然而TSO却是服务器领域的首推, 服务器太多了,远比核心转发设备多,它们的CPU需要减负,确实,CPU去计算一些固定模式的东西,有点浪费,它应该花更多的精力去处理一些不可控的东 西。所以TCP分段这种事情自然而然就由网卡代劳了。你,我,他,我们都遇到过TSO,但是我们只会开启,关闭它,如果你想知道它到底是怎么 Offload的,请看下图,让电流流一流:

wKiom1WzK0exrDQsAAZR4khvYXY659.jpg
TCP分段和IP分片的区别很大,这个事你一定要明白。然后才可以看懂上面的图。
       以上的解析只是一个特例,事实上,所有的硬件加速机制无非都是一样的机制。当我在看Intel千兆/万兆网卡的手册时,我想到在芯片的内部,这种电路的元 件几乎是海量的,实现了RSS,硬件hash分类等。这就是我所谓的江河泛滥,沿着沟壑瞬间吞噬大地,我们该如何挖沟填壑,这不是本文的目的,本文只是描 述了这种可能性。这也是这种专用电路和通用CPU之间的本质区别。CPU存在着一个指令集,这意味着它是关注于外部如何调用的,而专用电路的关注点在于内 部的执行逻辑,它几乎不对外提供任何接口,唯一的就是设置几个寄存器的值,比如MTU,数据包长度,数据包头长度等,其它的执行逻辑,外部无权过问。这是 串行编程和并行执行的本质区别。
       对于指令系统,也有一些要说的。在内部控制逻辑上,有一个统一的指令分发系统,实际上就是发射出一系列的0和1的组合,这个组合中的0和1作用于各种门电 路,这些门电路接受了这些不同的输入后,产生不同的输出,然后再作为另外的门电路的输入,造成不同的输出,如此反复...难道事实不是这样子吗?你很难否 则定。
       让电流流一流,如果你觉得比较抽象,那就观察洪水泛滥的过程吧,大河决堤的地点不同,造成的灾难也不同,关键在于决堤处的地势以及其所连接的各种地形,这 一切都是同时发生的,和电流一样,水流在经过一个弯道或者一道拱桥的时候,也会有一些延时和分流,这就可以类比电路中的各种门。
       吃饭了,吃饭了,真烦!



 本文转自 dog250 51CTO博客,原文链接:http://blog.51cto.com/dog250/1678286


相关文章
|
网络协议 算法
简述TCP报文首部字段及其作用
TCP报文首部字段及其作用
1317 0
|
7月前
|
运维 网络协议 Linux
聊聊 IP packet 的 TTL 与 tcp segment 的 MSL
聊聊 IP packet 的 TTL 与 tcp segment 的 MSL
|
网络协议 安全 Unix
TCP 选项和最大分片大小 (MSS)
本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查,并已被互联网工程指导小组 (IESG) 批准出版。并非所有 IESG 批准的文件都适用于任何级别的互联网标准;请参阅 RFC 5741 的第 2 节。
403 0
TCP 选项和最大分片大小 (MSS)
|
网络协议 算法
TCP 重传机制
TCP 重传机制
227 0
|
网络协议 算法
TCP/IP 校验和简析
TCP/IP 校验和简析
518 0
|
网络协议 算法 安全
深入浅出 BPF TCP 拥塞算法实现原理
深入浅出 BPF TCP 拥塞算法实现原理
449 0
|
域名解析 缓存 网络协议
一文详解 TCP与UDP区别
计算机与其他网络设备相互通信,通信的双方在发送和接收数据包时必须基于相同的规则(例如:如何找到通信目标、如何发起通信、如何结束通信等规则都需要事先确定),我们将这种规则称为协议(Protocol)。TCP/IP协议簇是 Internet 的基础,其是一系列网络协议的总称,例如:TCP、UDP、IP、FTP、HTTP、ICMP、SMTP等都属于TCP/IP协议族内的协议。
344 0
|
SQL 网络协议 关系型数据库
TCP性能和发送接收Buffer的关系
# 前言 本文希望解析清楚,当我们在代码中写下 socket.setSendBufferSize 和 sysctl 看到的rmem/wmem系统参数以及最终我们在TCP常常谈到的接收发送窗口的关系,以及他们怎样影响TCP传输的性能。 先明确一下:**文章标题中所说的Buffer指的是sysctl中的 rmem或者wmem,如果是代码中指定的话对应着SO_SNDBUF或者SO_RCVB
5468 0
|
网络协议 Java 存储
TCP/IP的底层队列
自从上次学习了TCP/IP的拥塞控制算法后,我越发想要更加深入的了解TCP/IP的一些底层原理,搜索了很多网络上的资料,看到了陶辉大神关于高性能网络编程的专栏,收益颇多。今天就总结一下,并且加上自己的一些思考
|
算法 网络协议 缓存