江苏龙网

  1. 主页 > 生活百科 > >

初学者也能看懂的DPDK解析

DPDK

原文转载于：https://www.cnblogs.com/qcloud1001/p/9585724.html

初学者也能看懂的DPDK解析

文章插图
【初学者也能看懂的DPDK解析】 
一、网络IO的处境和趋势
从我们用户的使用就可以感受到网速一直在提升 ， 而网络技术的发展也从1GE/10GE/25GE/40GE/100GE的演变 ， 从中可以得出单机的网络IO能力必须跟上时代的发展 。
1. 传统的电信领域
IP层及以下 ， 例如路由器、交换机、防火墙、基站等设备都是采用硬件解决方案 。基于专用网络处理器（NP） ， 有基于FPGA ， 更有基于ASIC的 。但是基于硬件的劣势非常明显 ， 发生Bug不易修复 ， 不易调试维护 ， 并且网络技术一直在发展 ， 例如2G/3G/4G/5G等移动技术的革新 ， 这些属于业务的逻辑基于硬件实现太痛苦 ， 不能快速迭代 。传统领域面临的挑战是急需一套软件架构的高性能网络IO开发框架 。
2. 云的发展
私有云的出现通过网络功能虚拟化（NFV）共享硬件成为趋势 ， NFV的定义是通过标准的服务器、标准交换机实现各种传统的或新的网络功能 。急需一套基于常用系统和标准服务器的高性能网络IO开发框架 。
3. 单机性能的飙升
网卡从1G到100G的发展 ， CPU从单核到多核到多CPU的发展 ， 服务器的单机能力通过横行扩展达到新的高点 。但是软件开发却无法跟上节奏 ， 单机处理能力没能和硬件门当户对 ， 如何开发出与时并进高吞吐量的服务 ， 单机百万千万并发能力 。即使有业务对QPS要求不高 ， 主要是CPU密集型 ， 但是现在大数据分析、人工智能等应用都需要在分布式服务器之间传输大量数据完成作业 。这点应该是我们互联网后台开发最应关注 ， 也最关联的 。
二、linux + x86网络IO瓶颈
在数年前曾经写过《网卡工作原理及高并发下的调优》一文 ， 描述了Linux的收发报文流程 。根据经验 ， 在C1（8核）上跑应用每1W包处理需要消耗1%软中断CPU ， 这意味着单机的上限是100万PPS（Packet Per Second） 。从TGW（Netfilter版）的性能100万PPS ， AliLVS优化了也只到150万PPS ， 并且他们使用的服务器的配置还是比较好的 。假设 ， 我们要跑满10GE网卡 ， 每个包64字节 ， 这就需要2000万PPS（注：以太网万兆网卡速度上限是1488万PPS ， 因为最小帧大小为84B《Bandwidth, Packets Per Second, and Other Network Performance Metrics》） ， 100G是2亿PPS ， 即每个包的处理耗时不能超过50纳秒 。而一次Cache Miss ， 不管是TLB、数据Cache、指令Cache发生Miss ， 回内存读取大约65纳秒 ， NUMA体系下跨Node通讯大约40纳秒 。所以 ， 即使不加上业务逻辑 ， 即使纯收发包都如此艰难 。我们要控制Cache的命中率 ， 我们要了解计算机体系结构 ， 不能发生跨Node通讯 。
从这些数据 ， 我希望可以直接感受一下这里的挑战有多大 ， 理想和现实 ， 我们需要从中平衡 。问题都有这些
1.传统的收发报文方式都必须采用硬中断来做通讯 ， 每次硬中断大约消耗100微秒 ， 这还不算因为终止上下文所带来的Cache Miss 。
2.数据必须从内核态用户态之间切换拷贝带来大量CPU消耗 ， 全局锁竞争 。
3.收发包都有系统调用的开销 。
4.内核工作在多核上 ， 为可全局一致 ， 即使采用Lock Free ， 也避免不了锁总线、内存屏障带来的性能损耗 。
5.从网卡到业务进程 ， 经过的路径太长 ， 有些其实未必要的 ， 例如netfilter框架 ， 这些都带来一定的消耗 ， 而且容易Cache Miss 。
三、DPDK的基本原理
从前面的分析可以得知IO实现的方式、内核的瓶颈 ， 以及数据流过内核存在不可控因素 ， 这些都是在内核中实现 ， 内核是导致瓶颈的原因所在 ， 要解决问题需要绕过内核 。所以主流解决方案都是旁路网卡IO ， 绕过内核直接在用户态收发包来解决内核的瓶颈 。
Linux社区也提供了旁路机制Netmap ， 官方数据10G网卡1400万PPS ， 但是Netmap没广泛使用 。其原因有几个：
1.Netmap需要驱动的支持 ， 即需要网卡厂商认可这个方案 。


推荐阅读


上一篇：茶厂和茶店储存茶叶的方法

下一篇：铁壶使用注意事项,使用铁壶时有几点需要注意