昨晚读了一篇Paper：
https://penberg.org/parakernel-hotos19.pdf
大意是说，随着IO设备的进化，它们的存取/传输速率已经超过了CPU到内存的存储/传输速率，再也不再是慢速 外设 了，所以，对这些快速设备的管理和操作要发生改变才能适应，从这个意义上讲，几乎一成不变的Linux kernel在很多方面确实阻滞了性能的优化。
这可能是现如今人们纷纷转向DPDK/netmap或者XDP的本质原因了。怎么说呢？周末回上海前，发一篇感想。
在人们的印象中，一台标准的计算机包含三大件：
- CPU，即中央处理器。
- 内存，悬挂在类似叫做北桥的芯片上。
- 外设，慢速IO设备，悬挂在类似叫做南桥的芯片上。
这也是我们在《计算机组成原理》这门课中学到的。其实这就是现实中的计算机，就这样子，如果按照抽象的冯诺伊曼计算机来看，计算机是不包含外设的，它只有CPU和内存，强调存储和执行，是为 存储执行计算机。
有了现实中的计算机组成后，下一步就是设计操作系统来管理这些东西，事实上，几乎任何操作系统都可以按照这堆东西划分为不同的模块：
- 进程管理，管理CPU分时和调度。
- 内存管理，管理内存分配。
- 文件系统，管理文件组织。
- 网络协议栈，管理网络IO。
- 磁盘驱动，…
- …
其实一开始从名字上将除CPU，内存之外的物件叫做 外设 (某种意义上磁盘也是)，并且将其连接到相对慢速的桥片上，背后的假设就是 相对于CPU和内存，这些IO设备是慢速的。
于是操作系统为了管理这些慢速设备，不得不设计出复杂的机制来进行速率的适配，数据的缓存等，无论是Unix/Linux还是Windows，均是在这个假设下设计出来的。
但是，事情在悄悄地起变化，外设也逐渐高速化，智能化，变得和CPU差不多了，越来越多的外设自带了存储芯片，俨然另一组CPU/内存挂在同一块主板上…
这个时候，操作系统应该作为一个协调者更合适，而不再适合继续作为管理者了，但是那些旧时代复杂的管理机制依然存在。以网络协议栈为例：
- 各类链表在多CPU环境下的同步开销。
- 不可睡眠的软中断路径过长。
- sk_buff的分配和释放。
- 内存拷贝的开销。
- 上下文切换造成的cache miss。
- …
显然这些机制在10Mbps/100Mbps网卡的慢速时代是没有任何问题的，那个时候 应用程序大部分时间在等网卡送上来数据。 现在到了1000Mbps/10Gbps/40Gbps网卡的时代，竟然反过来了，数据被很快地收入，却全部堵在内核里。
于是，各种优化措施应着需求而来：
- 网卡RSS，多队列。
- 中断线程化。
- 分割锁粒度。
- Busypoll。
- …
但却都是见招拆招，治标不治本。问题的根源不是这些机制需要优化，而是这些机制需要推倒重构。 蒸汽机车刚出来的时候，马车夫为了保持竞争优势，不是去换一匹昂贵的快马，而是卖掉马去买一台蒸汽机装上。 基本就是这个意思。
重构的思路很显然有两个：
- upload方法：别让应用程序等内核了，让应用程序自己去网卡直接拉数据。
- offload方法：别让内核处理网络逻辑了，让网卡自己处理。
总之，绕过内核就对了。
人们肯定知道如何处理这种高速的网络流，但是内核代码是写死的，版本迭代周期漫长，很难重构，那么如何让懂行的人自己的代码处理高速流就是唯一要解决的问题，很显然就有upload和offload两种方法了。
- DPDK让用户态程序直接处理网络流，bypass掉内核，使用独立的CPU专门干这个事。
- XDP让灌入网卡的eBPF程序直接处理网络流，bypass掉内核，使用网卡NPU专门干这个事。
如此一来，内核协议栈就不再参与数据平面的事了，留下来专门处理诸如路由协议，远程登录等控制平面和管理平面的数据流，妥妥的。
自2012年开始我就一直在关注Linux网络协议栈转发平面的性能优化，到2015年已经有很多想法落地，但都是基于Linux内核协议栈的优化，那个时候还没有智能网卡，DPDK也不火爆，能做的只是优化协议栈，当时除了华为等大厂也很少有做这块工作的，像BAT这种互联网公司开始迭代的第一代云网络也都是从内核协议栈起步的，即便如此也很少有人专门做这个。
…
时光流逝，不禁感慨，到了2016年，2017年至今，几乎相关公司招聘网络方面研发人员的任何JD上都会要求类似DPDK/eBPF，从而几乎人人的简历上都会写上相关的经验，我显然已经落后于时代，或者说前些年太过超前，结果被后来的历史车轮碾成了碎片。
时代发生了变化。
…
不变的则是拥抱变化。
来源：oschina
链接：https://my.oschina.net/u/3208144/blog/4699757