fpcc的专栏

epoll的应用，不管是库还是自己开发，基本上都是各种线程（池）应用紧密的绑定在一起。那么如何处理各种事件的实时动作以及数据和命令的快速分发解析，都是一个非常重要的问题。再加上实际场景各种情况都有可能发生，这就需要开发者能把程序设计的尽量弹性容错性高。针对epoll的缺点，增加适当的限流和控制机制，确保程序的整体的安全性。学习别人的应用，最重要是学会其设计的思想和技术实现手段。融会贯通，方能真正的把知识学到自己的头脑里，自己大脑的东西才是自己的。

虽然在现代的高并发网络通信中，几乎已经看不到select模式的身影，但这并不代表着它的作用很小。正如前面反复所讲，最合适的才是最好的。一个并发量不大，安全要求又高的场景下，可能一个普通程序员用Select模式就能搞定。但非要上一些epoll之类的“高端大气上档次”的模型，未必是一件好事情。开发者习惯的东西未必是一个全面的知识，select模式既可以用在服务端也可以用在客户端，这估计让许多初学者可能跌了一下眼镜。虽然大多是在讲服务端编程时学习select模型，但这不代表着他只能应用在服务端。

网络服务端编程是复杂的，要先从宏观上把网络通信的相关机制搞清楚。这样才能更好的在开发过程中明白一些细节的掌控，而不至于迷失在细节当中。这个系列会从顶层一点点的抽丝剥茧的把相关背景和技术栈分析展开，并对它们的相对关系进行分析说明。某些具体的细节如果不必要就不展开了，请大家自行查阅相关书籍或者资料。

c++编程的应用场景在前面分析过，一个重要的方向就是网络编程。一般来说，开发者说的服务端编程在c++方向上简单的可以认为是网络编程。首先需要说明的，本系列不对网络编程的相关基础知识展开详细的说明，因为这种知识在书本上太多了。网络上各种资料更是满开飞，没有必要拷贝来拷贝去的。特别是一些协议等的解析说明，如果不遇到特定的问题不会深入分析说明。那么最应该明白的网络编程是什么？那么就得明白网络是如何而来。网络，从名字上很好理解，一张把“经络”连接起来的大网。

学习理论知识十分的枯燥，特别对工作后的人，不论是从记忆力还是注意力，已经从单纯的学习转向了为了生活而打拼。此时对一些理论性的东西往往感到没有什么意义。但还是需要强调的是，计算机技术是一门非常强的理论和实践高度结合的技术学科。理论和实践缺一不可，新技术的突破往往是开发应用瓶颈的突破口，不需要到处再打补丁；同样，丰富的实践场景可以推动技术的完善和创新。思维不要僵化，要与时俱进。

eBPF的发展史，就是一部需求推进的发展史。所以说，技术不落地，发展的速度就会受限。反过来，强劲的落地需求，推动着技术不断的完善和快速发展。学习也是如此，如果只是为了学习新技术而学习，无法在实际工作中应用，那么技术学习了往往也会被忘记。而如果在实际的场景中应用到，那么对技术的理解会越来越深越来越通晓。这样，在后面的工作中会应用的如鱼得水。甚至有可能反过来，深入技术内部进行完善和修改。

创新是技术的灵魂。不断重复的技术其实就是一种落后的表现。做为一个开发者，加入创新技术的大军可能是很小概率的事件，但不代表对新技术的不敏感。对于开发者来说，新技术的优秀重点在于落地。不能落地的新技术，还不如老的技术。

在上文中介绍了XDP技术，XDP技术的基本原理已经明白，但有一个问题，一个技术如何落地，如何在实际中应用？这就需要有一个承载其的具体的形式。举一个例子，网络编程一般使用Socket方式，那么能不能够在这种方式里使用XDP技术呢？答案是肯定的。Linux在内核中提供了AF_XDP套接字编程，这就意味着，大部分的编程方式仍然可以以原来的套接字编程为主。这样的好处显而易见，对开发者和维护者来说，都是相对要容易理解和支持。AF_XDP类似于AF_NET（TCP/IP等）等一样，是一个协议族，大家有没有记得在TCP

XDP：eXpress Data Path，快速数据面，听名字是不是很高大上。其实它就是一个快速处理Rx数据包的数据面技术。为什么现在对数据处理如此敏感？原因非常简单，随着网络的不断覆盖社会的各个层面，海量的数据不断出现，而处理这些数据就要求一个字，快。无论是Linux亦或是Windows，它们都产生于早期的计算机系统，对快速的网络数据处理，大多天生就带有一些不足，这也导致了很多的问题。一般来说，操作系统的特点就是要有相当大的通用性，而这种通用性往往也是性能的瓶颈，这个瓶颈自然也包括网络数据通信。

UDP其实在普通的网络应用中，基本用来做一些辅助的工作，如果地址发现、广播简单消息等等。但由于它的占用资源少，在一些场景下就能发挥很大作用。包括在前文提到的QUIC其实都借鉴了UDP的一些特点。所以是不是觉得，很多技术其实并不是完全隔离的，它们会不断的整合、独立再如此循环。所以以后别的公司会不会也会也一个类似于DPDK的框架呢？拭目以待！

基础建设有一个重要的问题，一旦被统一如果不是出现致命性的问题，很难被推翻重建。因为重建的成本太高了，特别是积久年深的基础设施，即使出现致命性问题，重建的成本都会让人绝望。前些年出现的国际上的一些大银行想重新改写ATM和银行交易的代码的惨痛教训估计人们都看到了。这也从一个侧面体现了，新技术想打败老技术不是说短时间就能打败的，有的甚至是几代人的努力都无法完成。所以学习新技术的时候儿不要总盯着他的优势，能不能被大规模的快速应用，也是一个重要之处。DPDK有不少的优势，但这种优势在哪儿？

DPDK的应用还是有些复杂，不过从费效比看还是相当不错的。特别是在某些大型网络通信应用中，使用DPDK的优势还是很明显的。至于普通的网络编程还是老实的使用系统自带的Socket会更简单方便。在后面会对网络通信中使用DPDK进行具体的TCP/UDP应用分别分析说明。要善于利用技术而不是让技术成为一种思想上的拖累。

虽然侯教师说“源码面前，了无秘密”。可对于大的框架型软件来说，阅读代码确实相当吃力，特别是国内的编程水平和编程风格和国外的还有很大的不同，特别是一些具体的处理手段，有些高明之处不是一下两下就能看明白的。还有就是可能应用的具体的技术和国内也有不同，这就导致相关的代码阅读对于一些硬上的同学们非常有难度。但还是那个字，干！

不同的版本的DPDK可能源码会有些不同，请注意版本即可。重点是把DPDK的相关应用熟悉，在此基础上才能更好的对DPDK的框架有所了解。由应用到内部的实现，可能会更好的理解DPDK的设计理念和相关技术特点。

代码分析比较枯燥，但这又是必不可少的一关，不过不行。古人不是说过，做学问就像翻山，一山方出一山拦。只要坚持下去，就会闯出层峦叠嶂的知识万山。

将整个转发的流程相关内容搞清楚后，再去和代码匹配学习，就会发现学习起来相对容易了很多。其实还是推荐大家多看一下DPDK的官方文档，这样会更准确更清晰。但看官方文档有时对小白确实不是一个很友好的入门的方法。这就需要看一看别人学习和实践的心得了。仁者见仁吧，目的只有一个，学会并能熟练使用DPDK。

通过前面的分析，对DPDK中对报文处理的过程有了一个初步的认知。从一个更高层次来看，传统的网络通信一般会通过上层应用、操作系统、网卡驱动和硬件四层。再往下，基本就不属于于计算机控制的系统了。早期的应用，基本上这四个层次都比较单纯，所以也没啥复杂的管理方式，你来我往，你应我答这事就成了。可世风不古，上层应用的快速发展，使得底层的压力骤增。软件和硬件的发展是相互影响的，软件新需求的提出，硬件会在一个阶段后满足，即使无法通过正常的技术迭代满足，也可以使用其它方式。

总之，要想把一个系统优化，从整体上来看，一定不能在某个环节有明显的短板，这和计算机的木桶原理异曲同工。不但如此，这诸多环节中的处理协调也要尽量保持一致，而不能是生产者疯狂的生产，完全不顾消费者的处理。这也是DPDK提供三种处理模式的原因，因场景而异，不能一言而论。能否把DPDK用好，除了软件给力，整体的运维也要跟上。

如果一条通信链路要想达到最优的效果，一定是整体上每个环节都要有最佳的节奏协调控制而不一定是每个环节都是最优。这个在计算机的数据处理上就更是明显。一般来说，IO的速度是最低的，至少在可见的时光里要想超越CPU和内存还是很难的。以网卡通信为例，网卡本身就IO传输，然后通过总线传输进入内存，内存进缓存，缓存到CPU，然后再原路一个反馈。学过计算机的一般都知道，这里面涉及到的几个部分，数据的处理速度那是有着量层级上的差异的。所以在处理问题上有三条思路：一是把短板补齐，也就是那个慢把哪个速度提起来。

学习这种功能知识点，最重要的是把握整体逻辑和处理流程。算法和框架可以先放到一边，待了解清楚整体流程后，再深入到其中进行学习，能更好的理解和掌握相关的知识体系。学习要有学习方法，要有清晰的思路。万不可一上来就陷入细节，出力甚多却所得甚少。

其实，正如前面的分析，解决问题的思路其实就是基础知识的检查过程。在这次解决问题的过程中，数次发现和基础知识理解对不上，所以否定了自己的想法（比如析构函数的顺序）。只要按照标准和规则来，解决问题一定是水到渠成的。不要总想着弯道超车，没有大量的基础知识做底子，超车也是运气的结果。这次解决这个问题，正是一次比较多面的对基础知识的一次综合运用，收获颇丰。

DPDK的设计精髓在分析的流程中，逐渐变得越来越清晰。还是那句话，重点是借鉴DPDK的设计思想和具体实现方法为我所用。拿来主义，好的，就得要拿来，不但拿来，还要消化吸收。intel能发起这个项目，也正是因为自身有这方面的需求。而国内的开发者也可以从这个角度来学习并从中有所启发，搞好自己的项目。

锁的机制在不同的层次上有着不同的表述和表现形式，在不同的语言上可能又会衍生出不同的形式。这就需要开发者去仔细的分析其真正使用的哪种锁，从而能更好的对其进行应用。可以试着看一下Mutex在内核中是如何实现的(futex机制)，其实就明白了上面的话的意思。底层建设一直是重要的环节，侯捷老师说过：勿在浮沙筑高台。

在前面介绍了DPDK中的上层对并行的支持，特别是对多核的支持。但是，大家都知道，再怎么好的设计和架构，再优秀的编码，最终都要落到硬件和固件对整个上层应用的支持。单纯的硬件好处理，一个核不够多个核，在可能的情况下把CPU的频率增加，加大缓存等等。在现有水平的范围内，这些都是可以比较容易做到的。但是另外一个，就是在CPU上如何最终运行指令（也可以叫做固件设计），这个就需要设计人员动脑子了。

这里没有更细节展开谈IO模型和同步异步以及阻塞非阻塞的问题，这些基础的问题，不明白的需要去查阅相关资料。这篇文章只是一个开始，以后有机会的话，会将整个网络开发进行整体的分析说明和具体应用。技术的进步一定是向前发展的，开发者们一定睁开眼睛，瞭望世界，不要固守一隅，夜郎自大。

需要引起重视的是，并不能简单的认为多核、亲和性等技术就一定会带来整体效能的提升，这仍然需要在实际场景下的判定。任务的并行，也不是简单的多个人干不同的工作，大量的应用场景中仍然需要并行任务间的合作，这就极大的限制了并行任务的线性扩展。而在DPDK中采用的一系列技术，正是通过降低并行任务中的冲突并尽量减少不可并行的部分来保证并行任务的最大化。即使如此，大家仍然需要占在网络通信这个具体的场景中进行分析，来汲取其中的可借鉴部分。

DPDK的内存机制基本告一段落，那么高效的另外一个重点就是并行。以目前的计算机资源的使用来看，没有一个高效的并行框架基本上是无法达到榨干资源的可能的。就如资本一样，不浪费每一个资源，每一个资源的每一部分，是计算机开发者的终极目标。整体上要推进资源的技术进步，在无法短时间内实现技术进步的前提下，组合应用各种技术把对资源的利用达到极致，这就是计算机技术的宏观的目的。DPDK就是这其中一个典型的代表，所以，这个并行的机制，就不得直面对待。

DPDK中的环形队列只要掌握了其基本的内存管理知识和应用场景，就会很容易的掌握其中的内在的设计逻辑。从此处再推代码，互相印证，则可事半功倍。千万不要一开始就陷入代码的海洋，看似用功很多，则收效甚微。甚至学习不久就被劝退。整体把握，细节推敲，接口调配，三者共同推进，则学习别人的代码就会变得简单很多。

读比较大的框架的源码，有三个主要问题：一是宏观上流程怎么搞清楚，这个非常重要，否则就会陷入局部理解，它可以对自己的设计架构和思想理念产生影响；二是细节如何实现，它会直接影响阅读者对代码的理解和一些技术及技巧的学习应用；三是如何在细节模块实现与宏观流程的挂接上，也即分层和API连接设计上，这体现了另外的一种思想，即设计思想转化成实践思想的一个过程。

DPDK框架中对内存的管理基本上已经针对自己的应用场景做到了尽量有上佳的表现。但是，不断DPDK在演进，它依赖的内核和相关库也都在演进，甚至硬件也在演进，故而其对内存管理的演进是必然的。这也从新老版本中体现出来了。一根杆子捅到底，接下来，将会继续分析DPDK对相关内存管理（分配使用和回收等）相关的细节和流程。

随着计算机技术发展，特别是应用技术的快速发展。应用场景对计算机的处理速度几乎已经到了疯狂的地步。说句大白话，再快的CPU也嫌慢。没办法，CPU和IO等技术基本目前都处在了瓶颈之处，大幅度提高，短时间内看不到希望。但是不可以在某些部分进行优化。而DIDO就是这么一项技术。DIDO，Data Direct I/O，数据直通IO，网上和书上说得比较玄乎，其实就是一句话，缩短数据传输路径，减少数据拷贝次数。它的结果当然是提高敢吞吐量，减少了延迟。

其实从上面分析来看，不管采用何种手段，目的只有一个，流水线作业要尽量保证流水不停不乱。这样，就可以高效率的生产和处理数据。这种数据处理型的软件框架，最重视的就是这些，只要数据保持了流水按照意图前进，就达到了设计目的。毕竟，只要有了外在的干预，这个干预时间对CPU来说就是一个超长的时间周期，那么效率已经就不再乎了。而在没有干预的情况下，就必须保证数据最大的流水。比如下载网络数据，在线观看视频，在线视频会议等等。

在可预见的将来，计算机的内存管理仍然是一件很重要的事。所以学习一些内存管理的算法和相关的技巧是十分必要的，不可忽视的是，内存池的使用，是用空间换了时间，用浪费一部分内存换取了内存碎片的降低。编程人的眼中，永远是平衡两个字，这个平衡不是简单的平均，而从整体考虑的平衡。在数据层不平衡，在应用反向不平衡，整体就平衡了。好好理解和思考就会明白，内存做为基础的开发应用资源，是多么的重要。

从基础入手，继续分层剥离，越来越清晰的逼近DPDK的内部。

至少在现阶段，内存管理是所有程序都脱离不开的，所以GC是当前一个研究的热门。很多语言Go，Java，Python等都有自己的GC。其实GC就是一种更强大的内存管理，如果有机会接触就会发现，DPDK中的内存管理在它们面前是小弟弟，不过话又说回来，应用的场景不同，DPDK肯定会是有自己独到的一面，最主要的当然是大内存。学习别人的框架，在初期当然是通盘吃透。但这样做太沉重，到了后期，重点是学习别人的特质，而不永远通盘全吃。正所谓：“独观其大略”。

DPDK中，在用户空间（UIO）中，由于其本身的限制（其使用的为igb_uio），只能使用PA的IOVA模式，这也就限定了UIO中的应用；PA的IOVA模式的优势在于在内核空间的应用中并且对于所有硬件都可以使用，它的缺点就是如果对内存操作对权限有要求时，就麻烦了。既然是IO操作，理论上讲，这块就和传统的驱动的功能类似。当然，在DPDK中，PMD（软件轮询模式驱动程序）及一些相关软件并不需要PCI来操作驱动，它们通过标准的内核基础架构来操作硬件，这样就可以忽略到上面提到的IOVA，换句话说，这个就无所谓了。

越来越发现，学计算机和做饭的精髓殊途同归啊。做饭讲究火候（其实就是一种平衡状态），而写程序也讲究火候（资源的平衡利用），为了速度都可以提前处理资源（把菜提前切好，肉啥的处理），使用更先进的工具，使用更好的技术等等。也难怪好多网络小说把厨师写成各种高手，计算机是不是也应该出一个从厨师到神牛的系列。可惜的是，计算机是从国外发展起来的，国外的饮食和国内比起来基本都是渣渣，估计这种愿望实现有点难啊。扯回来，学习别人的经验，最终是把别人的优秀设计思想和开发理念掌握，而不能光为了学习而学习。

一般来说，做为软件平台或者框架，要么直接应用OS（或者一些公认的标准库）的内存管理，简单方便，但可能不太尽如人意；要么就得自己搞一套内存管理系统。而自己搞内存管理系统一般又有两类，一种是在原来OS内存管理系统的前提下，再抽象一层，为自己的框架所用，另外一种就比较狠了，直接修改底层（OS或者标准库）的内存管理系统。正常情况下，绝大数应用的开发都是第一大类，没人愿意搞内存管理。底层的框架或者一些大的平台软件愿意自己处理一下内存管理，但多数是再抽象一层。

虽然说起网络很多人都觉得明白，没啥，可较起真来，又发现一头雾水，啥SDN啊，NFV啊，这些都不明所以，实话实说，这个东西可不是一天两天就能搞明白，真正想搞网络的。还是要认真的从概念开始，先混个脸熟，然后再一步步的深入进去，中学时体育老师说：“不怕慢，就怕站”。学习是一个长跑，慢慢坚持努力！

virtio做为半虚拟化的应用标准，在DPDK中最典型的应用其实就是virtio-user，在前面的vhost-user一样，都是把工作放到了用户态。也就是说，virtio-user把设备驱动搬到了用户态，在virtio-net(网络半虚拟化)中，这样做能够更好的提高应用效率。而在DPDK中把这种驱动称之为virtio-pmd，而DKDK中的virtio-user既可以创建virtio设备并与后端的vhost完成初始化配置，又可以在没有KVM/QUEM的参与的非虚拟环境下使用相关的virtio设备。