[问答]

从内核协议栈转向DPDK/netmap或者XDP的本质原因是什么？

问答对人有帮助，内容完整，我也想知道答案 0 从内核协议栈转向DPDK/netmap或者XDP的本质原因是什么？ 0
2021-10-25 07:43:12　　评论淘帖0 邀请回答您可以邀请以下用户，快速回答问题 × elecfans 该类别下有 7 个回答。邀请回答 heks 该类别下有 7 个回答。邀请回答 ZQW发烧友该类别下有 6 个回答。邀请回答安立路该类别下有 6 个回答。邀请回答国名英雄XXX 该类别下有 6 个回答。邀请回答飞雪9366 该类别下有 6 个回答。邀请回答冰箱洗衣机该类别下有 6 个回答。邀请回答 chm5 该类别下有 6 个回答。邀请回答 lifei639156 该类别下有 6 个回答。邀请回答 szj0213 该类别下有 6 个回答。邀请回答 60user103 该类别下有 6 个回答。邀请回答细水爱长流该类别下有 6 个回答。邀请回答 dsgfa 该类别下有 6 个回答。邀请回答深海零下一度1 该类别下有 6 个回答。邀请回答 mingodong 该类别下有 6 个回答。邀请回答 h1654155199.5148 该类别下有 6 个回答。邀请回答 hzp_bbs1 该类别下有 5 个回答。邀请回答 zhhx1985 该类别下有 5 个回答。邀请回答 getian2001 该类别下有 5 个回答。邀请回答 jenny042 该类别下有 5 个回答。邀请回答举报王英相关推荐 • 请问fido5100芯片内核集成了协议栈吗？ 2804 • cc2530开发节电设备如何修改协议栈的参数？ 2531 • Cortex M系列内核中断中操作io失效的原因是什么？如何解决？ 571 • 如何去简化Simplified TCP/IP协议栈？ 1268 • 如何使用ZigBee协议栈？ 1911 • 什么是BLE协议栈？ 741 • 什么是诊断协议栈？ 1030 • 内核oops的根本原因是什么？我们如何调试内核oops？ 297 • 请问devicenet协议栈谁有啊？ 1858 • 协议栈介绍--TCP/IP 4487 1个回答

答案对人有帮助，有参考价值 0 昨晚读了一篇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网络协议栈转发平面的性能优化，那个时代所谓的网络优化几乎都是基于Linux内核协议栈的优化，在还没有智能网卡，DPDK也不火爆的时代，能做的只是优化协议栈，当时除了华为等大厂也很少有做这块工作的，像BAT这种互联网公司开始迭代的第一代云网络也都是从内核协议栈起步的，即便如此也很少有人专门做这块。互联网应用在云计算的大环境下开始大爆发，互联网流量也开始指数级暴涨，数据中心开始成为网络的核心，拥有通用处理器和万兆网卡生态的Intel率先研发并大规模推广DPDK显然只是时间问题，这是时代的产物。时光流逝，不禁感慨，到了2016年，2017年至今，几乎相关公司招聘网络方面研发人员的任何JD上都会要求类似DPDK/eBPF，从而几乎人人的简历上都会写上相关的经验，显然，时代发生了变化。不变的态度则是拥抱变化。

2021-10-25 14:32:40 评论举报李长鹰