作者：朱河清等
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
深入浅出DPDK试读：
序言
2015年的春天，在北京参加DPDK研讨大会时，有幸结识了本书的部分作者和众多DPDK研发的专业人士。这使我对这个专题的感召力深感诧异。DPDK就像一块磁铁，可以把这么多不同行业的专业人士吸引在一起。同时，大家会上也相约来年的春天，国内的同仁们能在DPDK技术进步中展现出自己独到的贡献。
作为运营商研发队伍的一员，我们无时不刻都能感受到NFV这个话题的灼热度。作为网络演进的大趋势，NFV将在未来为运营商实现网络重构扮演重要的角色。然而，大家都知道，NFV技术的发展之路存在各种屏障，性能问题是一道迈不过去的坎。这个问题的复杂性在于，它涉及I/O、操作系统内核、协议栈和虚拟化等多个层面对网络报文的优化处理技术。虽然IT界已发展出多类小众技术来应对，但这些技术对于普通应用技术人员而言比较陌生，即使对于传统网络的开发者而言，全面掌握这些技术也存在巨大的挑战。长久以来，用户更希望在这个领域有系统性的解决方案，能把相关的技术融会贯通，并系统性地组织在一起，同时也需要更为深入的细节技术支持工作。
DPDK的到来正逢其时，它之所以能脱颖而出，并迅速发展为业界在NFV加速领域的一种标杆技术，在于它不仅是上述技术的集大成者，更重要的是它的开放性和持续迭代能力，这些都得益于DPDK背后这支强大的专业研发团队，而本书的专业功力也可见一斑。
作为运营商的网络研发队伍，我们已关注DPDK近3年，尽管学习过DPDK部分源码和大量社区文档，也组织通过大量的DPDK相关NFV测试验证，但我们仍然觉得迫切需要系统性地介绍现代服务器体系架构，以及虚拟化环境下I/O优化的最新技术。令人倍感欣慰的是，本书作者对DPDK的讲解游刃有余，系统全面的同时又不乏敏锐的产业视角。可以说，深入浅出是本书最大的特点。
形而上者谓之道，形而下者谓之器。书中一方面透彻地讲解了现代处理器体系架构、网络I/O、内核优化和I/O虚拟化的原理与技术发展史，在这个“道用”的基础上，另一方面也清晰地介绍了DPDK细节性的“器用”知识，包括并行处理、队列调度、I/O调优、VNF加速等大量方法与应用，两方面相得益彰。结合DPDK社区的开源代码和动手实践，相信读者仔细学习完本书，必能加快对NFV性能关键技术的领悟。本书的受益对象首先是那些立志跨界转型的NFV研发工程师，也面向高等院校计算机专业希望在体系架构方面有更深发展的在校生，更包括像我们这样关注DPDK应用场景、NFVI集成和测试技术的最终用户。我们衷心感谢作者为业界带来的全新技术指引。这本书就像一粒种子，其中蕴含的知识未来定会在NFV这片沃土上枝繁叶茂，开花结果。
严格地讲，我们的团队只是DPDK用户的用户，我们研究DPDK的目的并非针对DPDK本身，而是为NFV的集成和开发提供一个准确的、可供评估的NFVI性能基准，减少各类网络功能组件在私有的优化过程中存在的不稳定风险。从对DPDK的初步评测来看，结果令人满意甚至超出预期，但我们仍应清醒地认识到，DPDK作为NFV加速技术架构仍有很长的路要走，打造成熟、规范和完善的产业链是近期要解决的重要课题。我们呼吁也乐见有更多的朋友加入DPDK应用推广的行列，众志成城，汇聚成一股SDN时代的创新洪流。欧亮博士 中国电信广州研究院
引言
动机2015年4月，第一届DPDK中国峰会在北京成功召开。来自中国移动、中国电信、阿里巴巴、IBM、Intel、华为以及中兴的专家朋友登台演讲，一起分享了以DPDK为中心的技术主题。表1列出了2015DPDK中国峰会的主题及演讲者。表1 2015DPDK中国峰会主题及演讲者
这次会议吸引了来自各行业、科研单位与高校的200多名开发人员、专家和企业代表参会。会上问答交流非常热烈，会后我们就想，也许是时间写一本介绍DPDK、探讨NFV数据面的技术书籍。现在，很多公司在招聘网络和系统软件人才时，甚至会将DPDK作为一项技能罗列在招聘要求中。DPDK从一个最初的小众技术，经过10年的孕育，慢慢走来，直至今日已经逐渐被越来越多的通信、云基础架构厂商接受。同时，互联网上也出现不少介绍DPDK基础理论的文章和博客，从不同的角度对DPDK技术进行剖析和应用，其中很多观点非常新颖。作为DPDK的中国开发团队人员，我们意识到如果能够提供一本DPDK的书籍，进行一些系统性的梳理，将核心的原理进行深入分析，可以更好地加速DPDK技术的普及，触发更多的软件创新，促进行业的新技术发展。于是，就萌发了写这本书的初衷。当然，我们心里既有创作的激动骄傲，也有些犹豫忐忑，写书不是一件简单的事情，但经过讨论和考量，我们逐渐变得坚定，这是一本集结团队智慧的尝试。我们希望能够把DPDK的技术深入浅出地解释清楚，让更多的从业人员和高校师生了解并使用DPDK，促进DPDK发展日新月异，兴起百家争鸣的局面，这是我们最大的愿景。多核
2005年的夏天，刚加入Intel的我们畅想着CPU多核时代的到来给软件业带来的挑战与机会。如果要充分利用多核处理器，需要软件针对并行化做大量改进，传统软件的并行化程度不高，在多核以前，软件依靠CPU频率提升自动获得更高性能。并行化改进不是一件简单的工作，许多软件需要重新设计，基本很难在短期实现，整个计算机行业都对此纠结了很久。2005年以前，整个CPU的发展历史，是不断提升芯片运算频率核心的做法，软件性能会随着处理器的频率升高，即使软件不做改动，性能也会跟着上一个台阶。但这样的逻辑进入多®核时代已无法实现。首先我们来看看表2所示的Intel多核处理器演进。®表2 Intel多核处理器演进的历史图表
在过去10年里，服务器平台的处理器核心数目扩展了很多。表2参考了英特尔至强系列的处理器的核心技术演进历史，这个系列的处理器主要面向双通道（双路）服务器和相应的硬件平台。与此同时，基于MIPS、Power、ARM架构的处理器也经历着类似或者更加激进的并行化计算的路线图。在处理器飞速发展的同时，服务器平台在硬件技术上提供了支撑。基于PCI Express的高速IO设备、内存访问与带宽的上升相辅相成。此外，价格和经济性优势越发突出，今天一台双路服务器的价格可能和10年前一台高端笔记本电脑的价格类似，但计算能力达到甚至超越了当年的超级计算机。强大的硬件平台为软件优化技术创新蕴蓄了温床。
以太网接口技术也经历了飞速发展。从早期主流的10Mbit/s与100Mbit/s，发展到千兆网（1Gbit/s）。到如今，万兆（10Gbit/s）网卡技术成为数据中心服务器的主流接口技术，近年来，Intel等公司还推出了40Gbit/s、100Gbit/s的超高速网络接口技术。而CPU的运行频率基本停留在10年前的水平，为了迎接超高速网络技术的挑战，软件也需要大幅度创新。
结合硬件技术的发展，DPDK（Data Plane Development Kit），一个以软件优化为主的数据面技术应时而生，它为今天NFV技术的发展提供了绝佳的平台可行性。IXP
提到硬件平台和数据面技术，网络处理器是无法绕过的话题。电信行业通常使用网络处理器或类似芯片技术作为数据面开发平台首选。Intel此前也曾专注此领域，2002年收购了DEC下属的研究部门，在美国马萨诸塞州哈德逊开发了这一系列芯片，诞生了行业闻名的Intel Exchange Architecture Network Processor（IXP4xx、IXP12xx、IXP24xx、IXP28xx）产品线，曾取得行业市场占有率第一的成绩。即使今日，相信很多通信业的朋友，还对这些处理器芯片有些熟悉或者非常了解。IXP内部拥有大量的微引擎（MicroEngine），同时结合了XSCALE作为控制面处理器，众所周知，XSCALE是以ARM芯片为核心技术的一种扩展。
2006年，AMD向Intel发起了一场大战，时至今日结局已然明了，Intel依赖麾下的以色列团队，打出了新一代Core架构，迅速在能效比上完成超车。公司高层同时确立了Tick-Tock的研发节奏，每隔两年推出新一代体系结构，每隔两年推出基于新一代制造工艺的芯片。这一战略基本保证了每年都会推出新产品。当时AMD的处理器技术一度具有领先地位，并触发了Intel在内部研发架构城门失火的状况下不得不进行重组，就在那时Intel的网络处理器业务被进行重估，由于IXP芯片系列的市场容量不够大，Intel的架构师也开始预测，通用处理器多核路线有取代IXP专用处理芯片的潜力。自此，IXP的研发体系开始调整，逐步转向使用Intel CPU多核的硬件平台，客观上讲，这一转型为DPDK的产生创造了机会。时至今日，Intel还保留并发展了基于硬件加速的QuickAssist技术，这和当日的IXP息息相关。由此看来，DPDK算是生于乱世。DPDK的历史
网络处理器能够迅速将数据报文接收入系统，比如将64字节的报文以10Gbit/s的线速也就是14.88Mp/s（百万报文每秒）收入系统，并且交由CPU处理，这在早期Linux和服务器平台上无法实现。以Venky Venkastraen、Walter Gilmore、Mike Lynch为核心的Intel团队开始了可行性研究，并希望借助软件技术来实现，很快他们取得了一定的技术突破，设计了运行在Linux用户态的网卡程序架构。传统上，网卡驱动程序运行在Linux的内核态，以中断方式来唤醒系统处理，这和历史形成有关。早期CPU运行速度远高于外设访问，所以中断处理方式十分有效，但随着芯片技术与高速网络接口技术的一日千里式发展，报文吞吐需要高达10Gbit/s的端口处理能力，市面上已经出现大量的25Gbit/s、40Gbit/s甚至100Gbit/s高速端口，主流处理器的主频仍停留在3GHz以下。高端游戏玩家可以将CPU超频到5GHz，但网络和通信节点的设计基于能效比经济性的考量，网络设备需要日以继夜地运行，运行成本（包含耗电量）在总成本中需要重点考量，系统选型时大多选取2.5GHz以下的芯片，保证合适的性价比。I/O超越CPU的运行速率，是横在行业面前的技术挑战。用轮询来处理高速端口开始成为必然，这构成了DPDK运行的基础。
在理论框架和核心技术取得一定突破后，Intel与6wind进行了合作，交由在法国的软件公司进行部分软件开发和测试，6wind向Intel交付了早期的DPDK软件开发包。2011年开始，6wind、Windriver、Tieto、Radisys先后宣布了对Intel DPDK的商业服务支持。Intel起初只是将DPDK以源代码方式分享给少量客户，作为评估IA平台和硬件性能的软件服务模块，随着时间推移与行业的大幅度接受，2013年Intel将DPDK这一软件以BSD开源方式分享在Intel的网站上，供开发者免费下载。2013年4月，6wind联合其他开发者成立www.dpdk.org的开源社区，DPDK开始走上开源的大道。开源
DPDK在代码开源后，任何开发者都被允许通过www.dpdk.org提交代码。随着开发者社区进一步扩大，Intel持续加大了在开源社区的投入，同时在NFV浪潮下，越来越多的公司和个人开发者加入这一社区，比如Brocade、Cisco、RedHat、VMware、IBM，他们不再只是DPDK的消费者，角色向生产者转变，开始提供代码，对DPDK的代码进行优化和整理。起初DPDK完全专注于Intel的服务器平台技术，专注于利用处理器与芯片组高级特性，支持Intel的网卡产品线系列。
DPDK 2.1版本在2015年8月发布，几乎所有行业主流的网卡设备商都已经加入DPDK社区，提供源代码级别支持。另外，除了支持通用网卡之外，能否将DPDK应用在特别的加速芯片上是一个有趣的话题，有很多工作在进行中，Intel最新提交了用于Crypto设备的接口设计，可以利用类似Intel的QuickAssit的硬件加速单元，实现一个针对数据包加解密与压缩处理的软件接口。
在多架构支持方面，DPDK社区也取得了很大的进展，IBM中国研究院的祝超博士启动了将DPDK移植到Power体系架构的工作，Freescale的中国开发者也参与修改，Tilera与Ezchip的工程师也花了不少精力将DPDK运行在Tile架构下。很快，DPDK从单一的基于Intel平台的软件，逐步演变成一个相对完整的生态系统，覆盖了多个处理器、以太网和硬件加速技术。
在Linux社区融合方面，DPDK也开始和一些主流的Linux社区合作，并得到了越来越多的响应。作为Linux社区最主要的贡献者之一的RedHat尝试在Fedora Linux集成DPDK；接着RedHat Enterprise Linux在安装库里也加入DPDK支持，用户可以自动下载安装DPDK扩展库。RedHat工程师还尝试将DPDK与Container集成测试，并公开发布了运行结果。传统虚拟化的领导者VMware的工程师也加入DPDK社区，负责VMXNET3-PMD模块的维护。Canonical在Ubuntu 15中加入了DPDK的支持。延伸
由于DPDK主体运行在用户态，这种设计理念给Linux或者FreeBSD这类操作系统带来很多创新思路，也在Linux社区引发一些讨论。
DPDK的出现使人们开始思考，Linux的用户态和内核态，谁更适合进行高速网络数据报文处理。从简单数据对比来看，在Intel的通用服务器上，使用单核处理小包收发，纯粹的报文收发，理想模型下能达到大约57Mp/s（每秒百万包）。尽管在真实应用中，不会只收发报文不处理，但这样的性能相对Linux的普通网卡驱动来说已经是遥不可及的高性能。OpenVSwitch是一个很好的例子，作为主流的虚拟交换开源软件，也尝试用DPDK来构建和加速虚拟交换技术，DPDK的支持在OVS2.4中被发布，开辟了在内核态数据通道之外一条新的用户态数据通道。目前，经过20多年的发展，Linux已经累积大量的开源软件，具备丰富的协议和应用支持，无所不能，而数据报文进出Linux系统，基本都是在Linux内核态来完成处理。因为Linux系统丰富强大的功能，相当多的生产系统（现有软件）运行在Linux内核态，这样的好处是大量软件可以重用，研发成本低。但也正因为内核功能强大丰富，其处理效率和性能就必然要做出一些牺牲。使用
在专业的通信网络系统中，高速数据进出速率是衡量系统性能的关键指标之一。大多通信系统是基于Linux的定制系统，在保证实时性的嵌入式开发环境中开发出用户态下的程序完成系统功能。利用DPDK的高速报文吞吐优势，对接运行在Linux用户态的程序，对成本降低和硬件通用化有很大的好处，使得以软件为主体的网络设备成为®可能。对Intel x86通用处理器而言，这是一个巨大的市场机会。
对于通信设备厂商，通用平台和软件驱动的开发方式具有易采购、易升级、稳定性、节约成本的优点。
·易采购：通用服务器作为主流的基础硬件，拥有丰富的采购渠道和供应商，供货量巨大。
·易升级：软件开发模式简单，工具丰富，最大程度上避免系统升级中对硬件的依赖和更新，实现低成本的及时升级。
·稳定性：通用服务器平台已经通过大量功能的验证，产品稳定性毋庸置疑。而且，对于专用的设计平台，系统稳定需要时间累积和大量测试，尤其是当采用新一代平台设计时可能需要硬件更新，这就会带来稳定性的风险。
·节约研发成本和降低复杂性：传统的网络设备因为功能复杂和高可靠性需求，系统切分为多个子系统，每个子系统需要单独设计和选型，独立开发，甚至选用单独的芯片。这样的系统需要构建复杂的开发团队、完善的系统规划、有效的项目管理和组织协调，来确保系统开发进度。而且，由于开发的范围大，各项目之间会产生路径依赖。而基于通用服务器搭建的网络设备可以很好地避免这些问题。版权
DPDK全称是Data Plane Development Kit，从字面解释上看，这是专注于数据面软件开发的套件。本质上，它由一些底层的软件库组成。目前，DPDK使用BSD license，绝大多数软件代码都运行在用户态。少量代码运行在内核态，涉及UIO、VFIO以及XenDom0，KNI这类内核模块只能以GPL发布。BSD给了DPDK的开发者和消费者很大的自由，大家可以自由地修改源代码，并且广泛应用于商业场景。这和GPL对商业应用的限制有很大区别。作为开发者，向DPDK社区提交贡献代码时，需要特别注意license的定义，开发者需要明确license并且申明来源的合法性。社区
参与DPDK社区［Ref1-1］（www.dpdk.org/dev，本书不做详细解读。对于使用DPDK的技术问题，可以参与user@dpdk.org进入讨论。
子模块的维护者名单也会发布到开源社区，便于查阅。在提交代码时，源代码以patch方式发送给dev@dpdk.org。通常情况下，代码维护者会对提交的代码进行仔细检查，包括代码规范、兼容性等，并提供反馈。这个过程全部通过电子邮件组的方式来完成，由于邮件量可能巨大，如果作者没有得到及时回复，请尝试主动联系，提醒代码维护人员关注，这是参与社区非常有效的方式。开发者也可以在第一次提交代码时明确抄送相关的活跃成员和专家，以得到更加及时的反馈和关注。
目前，开源社区的大量工作由很多自愿开发者共同完成，因此需要耐心等待其他开发者来及时参与问答。通过提前研究社区运行方式，可以事半功倍。这对在校学生来说更是一个很好的锻炼机会。及早参与开源社区的软件开发，会在未来选择工作时使你具有更敏锐的产业视角和技术深度。作为长期浸润在通信行业的专业人士，我们强烈推荐那些对软件有强烈兴趣的同学积极参与开源社区的软件开发。贡献
本书由目前DPDK社区中一些比较资深的开发者共同编写，很多作者是第一次将DPDK的核心思想付诸于书面文字。尽管大家已尽最大的努力，但由于水平和能力所限，难免存在一些瑕疵和不足，也由于时间和版面的要求，很多好的想法无法在本书中详细描述。但我们希望通过本书能够帮助读者理解DPDK的核心思想，引领大家进入一个丰富多彩的开源软件的世界。在本书编纂过程中我们得到很多朋友的帮助，必须感谢上海交通大学的金耀辉老师、中国科学技术大学的华蓓和张凯老师、清华大学的陈渝教授、中国电信的欧亮博士，他们给了我们很多中肯的建议；另外还要感谢李训和刘勇，他们提供了大量的资料和素材，帮助我们验证了大量的DPDK实例；还要感谢我们的同事杨涛、喻德、陈志辉、谢华伟、戴启华、常存银、刘长鹏、Jim St Leger、MJay、Patrick Lu，他们热心地帮助勘定稿件；最后还要特别感谢英特尔公司网络产品事业部的领导周晓梅和周林给整个写作团队提供的极大支持。正是这些热心朋友、同事和领导的支持，坚定了我们的信心，并帮助我们顺利完成此书。最后我们衷心希望本书读者能够有所收获。
作者介绍
（按姓名排序）About the Authers曹水：黑龙江省佳木斯人，2001年毕业于复旦大学计算机系，硕士。现为英特尔软件经理，从事嵌入式开发和软件行业超过15年，现主要负责DPDK软件测试工作。
陈静：湖北省沙市人，2006年毕业于华中科技大学，硕士。现为英特尔软件开发工程师，主要从事DPDK网卡驱动的开发和性能调优工作。
何少鹏：江西省萍乡人，毕业于上海交通大学，硕士。现为英特尔DPDK软件工程师，开发网络设备相关软件超过十年，也有数年从事互联网应用和SDN硬件设计工作。
胡雪焜：江西省南昌人，毕业于中国科学技术大学计算机系，硕士。现为英特尔网络通信平台部门应用工程师，主要研究底层虚拟化技术和基于IA架构的数据面性能优化，以及对网络演进的影响，具有丰富的SDN/NFV商业实践经验。
梁存铭：英特尔资深软件工程师，在计算机网络领域具有丰富的实践开发经验，提交过多项美国专利。作为DPDK早期贡献者之一，在PCIe高性能加速、I/O虚拟化、IA指令优化、改善闲时效率、协议栈优化等方面有较深入的研究。
刘继江：黑龙江省七台河人，毕业于青岛海洋大学自动化系，现主要从事DPDK网卡驱动程序和虚拟化研发，和overlay网络的性能优化工作。
陆文卓：安徽省淮南人，2004年毕业于南京大学计算机系，硕士。现为英特尔中国研发中心软件工程师。在无线通信、有线网络方面均有超过十年的从业经验。
欧阳长春：2006年毕业于华中科技大学计算机系，硕士。目前在阿里云任开发专家，从事网络虚拟化开发及优化，在数据报文加速、深度报文检测、网络虚拟化方面具有丰富开发经验。
仇大玉：江苏省南京人，2012年毕业于东南大学，硕士。现为英特尔亚太研发有限公司软件工程师，主要从事DPDK软件开发和测试工作。
陶喆：上海交通大学学士，上海大学硕士。先后在思科和英特尔从事网络相关的设备、协议栈和虚拟化的开发工作。曾获CCIE R&S认证。
万群：江西省南昌人，毕业于西安交通大学计算机系，硕士。现为英特尔上海研发中心研发工程师。从事测试领域的研究及实践近十年，对测试方法及项目管理有相当丰富的经验。
王志宏：四川省绵阳人，2011年毕业于华东师范大学，硕士。现为英特尔亚太研发中心高级软件工程师，主要工作方向为DPDK虚拟化中的性能分析与优化。
吴菁菁：江苏省扬州人，2007年毕业于西安交通大学电信系，硕士。现为英特尔软件工程师，主要从事DPDK软件开发工作。
许茜：浙江省杭州市人，毕业于浙江大学信电系，硕士，现为英特尔网络处理事业部软件测试人员，主要负责DPDK相关的虚拟化测试和性能测试。
杨子夜：2009年毕业于复旦大学软件学院，硕士。现为英特尔高级软件工程师，从事存储软件开发和优化工作，在虚拟化、存储、云安全等领域拥有5个相关专利以及20项申请。
张合林：湖南省湘潭人，2004年毕业于东华大学，工学硕士。现主要从事DPDK网卡驱动程序研发及性能优化工作。
张帆：湖南省长沙人，爱尔兰利莫里克大学计算机网络信息学博士。现为英特尔公司爱尔兰分部网络软件工程师，湖南省湘潭大学兼职教授。近年专著有《Comparative Performance and Energy Consumption Analysis of Different AES Implementations on a Wireless Sensor Network Node》等。发表SCI/EI检索国际期刊及会议论文3篇。目前主要从事英特尔DPDK在SDN应用方面的扩展研究工作。
朱河清：江苏省靖江人，毕业于电子科技大学数据通信与计算机网络专业，硕士，现为英特尔DPDK与Hyperscan软件经理，在英特尔、阿尔卡特、华为、朗讯有15年通信网络设备研发与开源软件开发经验。
Venky Venkatesan：毕业于印度孟买大学，现为英特尔网络产品集团高级主任工程师（Sr PE），DPDK初始架构师，在美国Oregon负责报文处理与加速的系统架构与软件创新工作。第一部分 DPDK基础篇
第1章 认识DPDK
第2章 Cache和内存
第3章 并行计算
第4章 同步互斥机制
第5章 报文转发
第6章 PCIe与包处理I/O
第7章 网卡性能优化
第8章 流分类与多队列
第9章 硬件加速与功能卸载
软件正在统治整个世界。——马克·安德森
本书的开始部分会重点介绍DPDK诞生的背景、基本概念、核心算法，并结合实例讲解各种基于IA平台的数据面优化技术，包括相关的网卡加速技术。希望可以帮助初次接触DPDK的读者全面了解DPDK，为后面的阅读打下基础。
DPDK基础篇共包括9章，其中前5章主要从软件优化的角度阐述如何利用DPDK来提升性能，包括cache优化、并行计算、同步互斥、转发算法等。后面4章则针对PCIe设备和高速网卡详细介绍如何优化网卡性能，提高网络带宽吞吐率。
第1章介绍了DPDK的技术演进历程，面临及需要解决的问题，以及如何从系统的角度看待DPDK的技术，最后结合几个编程实例帮助读者了解DPDK基本的编程模式。
第2章则系统地介绍内存和cache的相关基本知识，分析了各种IA平台上的cache技术的特点和优势，并介绍了一个DPDK的重要技术“大页”的使用。
第3章和第4章则围绕多核的使用，着重介绍如何使用多线程，最大限度地进行指令和数据的并行执行。为了解决多线程访问竞争的问题，还引入了几种常见的DPDK锁机制。
第5章详细讲述了DPDK的数据报文转发模型，帮助读者了解DPDK的工作模式。
从第6章开始，本书内容逐步从CPU转移到网卡I/O。其中，第6章将会从CPU与PCIe总线架构的角度，带领读者领略CPU与网卡DMA协同工作的整个交互过程。
第7章则专注于网卡的性能优化，详细介绍了DPDK如何在软件设计、硬件平台选择和配置上实现高效的网络报文处理。
第8章介绍了目前高速网卡中一个非常通用的技术“多队列与流分类”，解释了DPDK如果利用这个技术实现更高效的IO处理。
第9章介绍了目前以网卡为主的硬件卸载与智能化发展趋势，帮助读者了解如何将DPDK与网卡的硬件卸载技术结合，减少CPU的开销，实现高协同化的软硬件设计。第1章 认识DPDK
什么是DPDK？对于用户来说，它可能是一个性能出色的包数据处理加速软件库；对于开发者来说，它可能是一个实践包处理新想法的创新工场；对于性能调优者来说，它可能又是一个绝佳的成果分享平台。当下火热的网络功能虚拟化，则将DPDK放在一个重要的基石位置。虽然很难用短短几语就勾勒出DPDK的完整轮廓，但随着认识的深入，我们相信你一定能够认可它传播的那些最佳实践方法，从而将这些理念带到更广泛的多核数据包处理的生产实践中去。
DPDK最初的动机很简单，就是证明IA多核处理器能够支撑高性能数据包处理。随着早期目标的达成和更多通用处理器体系的加入，DPDK逐渐成为通用多核处理器高性能数据包处理的业界标杆。1.1 主流包处理硬件平台
DPDK用软件的方式在通用多核处理器上演绎着数据包处理的新篇章，而对于数据包处理，多核处理器显然不是唯一的平台。支撑包处理的主流硬件平台大致可分为三个方向。
·硬件加速器
·网络处理器
·多核处理器
根据处理内容、复杂度、成本、量产规模等因素的不同，这些平台在各自特定的领域都有一定的优势。硬件加速器对于本身规模化的固化功能具有高性能低成本的特点，网络处理器提供了包处理逻辑软件可编程的能力，在获得灵活性的同时兼顾了高性能的硬件包处理，多核处理器在更为复杂多变的高层包处理上拥有优势，随着包处理的开源生态系统逐渐丰富，以及近年来性能的不断提升，其为软件定义的包处理提供了快速迭代的平台。参见［Ref1-2］。
随着现代处理器的创新与发展（如异构化），开始集成新的加速处理与高速IO单元，它们互相之间不断地融合。在一些多核处理器中，已能看到硬件加速单元的身影。从软件包处理的角度，可以卸载部分功能到那些硬件加速单元进一步提升性能瓶颈；从硬件包处理的流水线来看，多核上运行的软件完成了难以固化的上层多变逻辑的任务；二者相得益彰。1.1.1 硬件加速器
硬件加速器被广泛应用于包处理领域，ASIC和FPGA是其中最广为采用的器件。
ASIC（Application-Specific Integrated Circuit）是一种应特定用户要求和特定电子系统的需要而设计、制造的集成电路。ASIC的优点是面向特定用户的需求，在批量生产时与通用集成电路相比体积更小、功耗更低、可靠性提高、性能提高、保密性增强、成本降低等。但ASIC的缺点也很明显，它的灵活性和扩展性不够、开发费用高、开发周期长。
为了弥补本身的一些缺点，ASIC越来越多地按照加速引擎的思路来构建，结合通用处理器的特点，融合成片上系统（SoC）提供异构处理能力，使得ASIC带上了智能（Smart）的标签。
FPGA（Field-Programmable Gate Array）即现场可编程门阵列。它作为ASIC领域中的一种半定制电路而出现，与ASIC的区别是用户不需要介入芯片的布局布线和工艺问题，而且可以随时改变其逻辑功能，使用灵活。FPGA以并行运算为主，其开发相对于传统PC、单片机的开发有很大不同，以硬件描述语言（Verilog或VHDL）来实现。相比于PC或单片机（无论是冯·诺依曼结构还是哈佛结构）的顺序操作有很大区别。
全可编程FPGA概念的提出，使FPGA朝着进一步软化的方向持续发展，其并行化整数运算的能力将进一步在通用计算定制化领域得到挖掘，近年来在数据中心中取得了很大进展，比如应用于机器学习场合。我们预计FPGA在包处理的应用场景将会从通信领域（CT）越来越多地走向数据中心和云计算领域。1.1.2 网络处理器
网络处理器（Network Processer Unit，NPU）是专门为处理数据包而设计的可编程通用处理器，采用多内核并行处理结构，其常被应用于通信领域的各种任务，比如包处理、协议分析、路由查找、声音/数据的汇聚、防火墙、QoS等。其通用性表现在执行逻辑由运行时加载的软件决定，用户使用专用指令集即微码（microcode）进行开发。其硬件体系结构大多采用高速的接口技术和总线规范，具有较高的I/O能力，使得包处理能力得到很大提升。除了这些特点外，NPU一般还包含多种不同性能的存储结构，对数据进行分类存储以适应不同的应用目的。NPU中也越来越多地集成进了一些专用硬件协处理器，可进一步提高片内系统性能。
图1-1是NP-5处理器架构框图，以EZCHIP公司的NP-5处理器架构为例，TOP部分为可编程部分，根据需要通过编写微码快速实现业务相关的包处理逻辑。NPU拥有高性能和高可编程性等诸多优点，但其成本和特定领域的特性限制了它的市场规模（一般应用于专用通信设备）。而不同厂商不同架构的NPU遵循的微码规范不尽相同，开发人员的成长以及生态系统的构建都比较困难。虽然一些NPU的微码也开始支持由高级语言（例如C）编译生成，但由于结构化语言本身原语并未面向包处理，使得转换后的效率并不理想。图1-1 NP-5处理器架构框图
随着SDN对于可编程网络，特别是可编程数据面的要求，网络处理器也可能会迎来新的发展机遇，但依然需要解决好不同架构的底层抽象以及上层业务的语义抽象。1.1.3 多核处理器
现代CPU性能的扩展主要通过多核的方式进行演进。这样利用通用处理器同样可以在一定程度上并行地处理网络负载。由于多核处理器在逻辑负载复杂的协议及应用层面上的处理优势，以及越来越强劲的数据面的支持能力，它在多种业务领域得到广泛的采用。再加上多年来围绕CPU已经建立起的大量成熟软件生态，多核处理器发展的活力和热度也是其他形态很难比拟的。图1-2是Intel双路服务器平台框图，描述了一个典型的双路服务器平台的多个模块，CPU、芯片组C612、内存和以太网控制器XL710构成了主要的数据处理通道。基于PCIe总线的I/O接口提供了大量的系统接口，为服务器平台引入了差异化的设计。
当前的多核处理器也正在走向SoC化，针对网络的SoC往往集成内存控制器、网络控制器，甚至是一些硬件加速处理引擎。
这里列出了一些主流厂商的多核处理器的SoC平台。
·IA multi-core Xeon
·Tilear-TILE-Gx
·Cavium Network-OCTEON&OCTEON II
·Freescale-QorIQ
·NetLogic Microsystem-XLP图1-2 Intel双路服务器平台框图
图1-3的Cavium OCTEON处理器框图以Cavium OCTEON多核处理器为例，它集成多个CPU核以及众多加速单元和网络接口，组成了一个片上系统（SoC）。在这些SoC上，对于可固化的处理（例如，流分类，QoS）交由加速单元完成，而对于灵活的业务逻辑则由众多的通用处理器完成，这种方式有效地融合了软硬件各自的优势。随着软件（例如，DPDK）在I/O性能提升上的不断创新，将多核处理器的竞争力提升到一个前所未有的高度，网络负载与虚拟化的融合又催生了NFV的潮流。图1-3 Cavium OCTEON处理器框图
更多内容请参考相关Cavium和Ezchip的信息（［Ref1-3］和［Ref1-4］）。1.2 初识DPDK
本书介绍DPDK，主要以IA（Intel Architecture）多核处理器为目标平台。在IA上，网络数据包处理远早于DPDK而存在。从商业版的Windows到开源的Linux操作系统，所有跨主机通信几乎都会涉及网络协议栈以及底层网卡驱动对于数据包的处理。然而，低速网络与高速网络处理对系统的要求完全不一样。1.2.1 IA不适合进行数据包处理吗
以Linux为例，传统网络设备驱动包处理的动作可以概括如下：
·数据包到达网卡设备。
·网卡设备依据配置进行DMA操作。
·网卡发送中断，唤醒处理器。
·驱动软件填充读写缓冲区数据结构。
·数据报文达到内核协议栈，进行高层处理。
·如果最终应用在用户态，数据从内核搬移到用户态。
·如果最终应用在内核态，在内核继续进行。
随着网络接口带宽从千兆向万兆迈进，原先每个报文就会触发一个中断，中断带来的开销变得突出，大量数据到来会触发频繁的中断开销，导致系统无法承受，因此有人在Linux内核中引入了NAPI机制，其策略是系统被中断唤醒后，尽量使用轮询的方式一次处理多个数据包，直到网络再次空闲重新转入中断等待。NAPI策略用于高吞吐的场景，效率提升明显。
一个二层以太网包经过网络设备驱动的处理后，最终大多要交给用户态的应用，图1-4的典型网络协议层次OSI与TCP/IP模型，是一个基础的网络模型与层次，左侧是OSI定义的7层模型，右侧是TCP/IP的具体实现。网络包进入计算机大多需要经过协议处理，在Linux系统中TCP/IP由Linux内核处理。即使在不需要协议处理的场景下，大多数场景下也需要把包从内核的缓冲区复制到用户缓冲区，系统调用以及数据包复制的开销，会直接影响用户态应用从设备直接获得包的能力。而对于多样的网络功能节点来说，TCP/IP协议栈并不是数据转发节点所必需的。图1-4 典型网络协议层次OSI与TCP/IP模型
以无线网为例，图1-5的无线4G/LTE数据面网络协议展示了从基站、基站控制器到无线核心网关的协议层次，可以看到大量处理是在网络二、三、四层进行的。如何让Linux这样的面向控制面原生设计的操作系统在包处理上减少不必要的开销一直是一大热点。有个著名的高性能网络I/O框架Netmap，它就是采用共享数据包池的方式，减少内核到用户空间的包复制。图1-5 无线4G/LTE数据面网络协议
NAPI与Netmap两方面的努力其实已经明显改善了传统Linux系统上的包处理能力，那是否还有空间去做得更好呢？作为分时操作系统，Linux要将CPU的执行时间合理地调度给需要运行的任务。相对于公平分时，不可避免的就是适时调度。早些年CPU核数比较少，为了每个任务都得到响应处理，进行充分分时，用效率换响应，是一个理想的策略。现今CPU核数越来越多，性能越来越强，为了追求极端的高性能高效率，分时就不一定总是上佳的策略。以Netmap为例，即便其减少了内核到用户空间的内存复制，但内核驱动的收发包处理和用户态线程依旧由操作系统调度执行，除去任务切换本身的开销，由切换导致的后续cache替换（不同任务内存热点不同），对性能也会产生负面的影响。
如果再往实时性方面考虑，传统上，事件从中断发生到应用感知，也是要经过长长的软件处理路径。所以，在2010年前采用IA处理器的用户会得出这样一个结论，那就是IA不适合做包处理。
真的是这样么？在IA硬件基础上，包处理能力到底能做到多好，有没有更好的方法评估和优化包处理性能，怎样的软件设计方法能最充分地释放多核IA的包处理能力，这些问题都是在DPDK出现之前，实实在在地摆在Intel工程师面前的原始挑战。1.2.2 DPDK最佳实践
如今，DPDK应该已经很好地回答了IA多核处理器是否可以应对高性能数据包处理这个问题。而解决好这样一个问题，也不是用了什么凭空产生的特殊技术，更多的是从工程优化角度的迭代和最佳实践的融合。如果要简单地盘点一下这些技术，大致可以归纳如下。
轮询，这一点很直接，可避免中断上下文切换的开销。之前提到Linux也采用该方法改进对大吞吐数据的处理，效果很好。在第7章，我们会详细讨论轮询与中断的权衡。
用户态驱动，在这种工作方式下，既规避了不必要的内存拷贝又避免了系统调用。一个间接的影响在于，用户态驱动不受限于内核现有的数据格式和行为定义。对mbuf头格式的重定义、对网卡DMA操作的重新优化可以获得更好的性能。而用户态驱动也便于快速地迭代优化，甚至对不同场景进行不同的优化组合。在第6章中，我们将探讨用户态网卡收发包优化。
亲和性与独占，DPDK工作在用户态，线程的调度仍然依赖内核。利用线程的CPU亲和绑定的方式，特定任务可以被指定只在某个核上工作。好处是可避免线程在不同核间频繁切换，核间线程切换容易导致因cache miss和cache write back造成的大量性能损失。如果更进一步地限定某些核不参与Linux系统调度，就可能使线程独占该核，保证更多cache hit的同时，也避免了同一个核内的多任务切换开销。在第3章，我们会再展开讨论。
降低访存开销，网络数据包处理是一种典型的I/O密集型（I/O bound）工作负载。无论是CPU指令还是DMA，对于内存子系统（Cache+DRAM）都会访问频繁。利用一些已知的高效方法来减少访存的开销能够有效地提升性能。比如利用内存大页能有效降低TLB miss，比如利用内存多通道的交错访问能有效提高内存访问的有效带宽，再比如利用对于内存非对称性的感知可以避免额外的访存延迟。而cache更是几乎所有优化的核心地带，这些有意思而且对性能有直接影响的部分，将在第2章进行更细致的介绍。
软件调优，调优本身并不能说是最佳实践。这里其实指代的是一系列调优实践，比如结构的cache line对齐，比如数据在多核间访问避免跨cache line共享，比如适时地预取数据，再如多元数据批量操作。这些具体的优化策略散布在DPDK各个角落。在第2章、第6章、第7章都会具体涉及。
利用IA新硬件技术，IA的最新指令集以及其他新功能一直是®DPDK致力挖掘数据包处理性能的源泉。拿Intel DDIO技术来讲，这个cache子系统对DMA访存的硬件创新直接助推了性能跨越式的增长。有效利用SIMD（Single Instruction Multiple Data）并结合超标量技术（Superscalar）对数据层面或者对指令层面进行深度并行化，在性能的进一步提升上也行之有效。另外一些指令（比如cmpxchg），本身就是lockless数据结构的基石，而crc32指令对与4Byte Key的哈希计算也是改善明显。这些内容，在第2章、第4章、第5章、第6章都会有涉及。
充分挖掘网卡的潜能，经过DPDK I/O加速的数据包通过PCIe网卡进入系统内存，PCIe外设到系统内存之间的带宽利用效率、数据传送方式（coalesce操作）等都是直接影响I/O性能的因素。在现代网卡中，往往还支持一些分流（如RSS，FDIR等）和卸载（如Chksum，TSO等）功能。DPDK充分利用这些硬件加速特性，帮助应用更好地获得直接的性能提升。这些内容将从第6章~第9章一一展开。
除了这些基础的最佳实践，本书还会用比较多的篇幅带领大家进入DPDK I/O虚拟化的世界。在那里，我们依然从I/O的视角，介绍业界广泛使用的两种主流方式，SR-IOV和Virtio，帮助大家理解I/O硬件虚拟化的支撑技术以及I/O软件半虚拟化的技术演进和革新。从第10章到第14章，我们会围绕着这一主题逐步展开。
随着DPDK不断丰满成熟，也将自身逐步拓展到更多的平台和场景。从Linux到FreeBSD，从物理机到虚拟机，从加速网络I/O到加速存储I/O，DPDK在不同纬度发芽生长。在NFV大潮下，无论是NFVI（例如，virtual switch）还是VNF，DPDK都用坚实有力的性能来提供基础设施保障。这些内容将在第10章~第15章一一介绍。
当然，在开始后续所有章节之前，让我们概览一下DPDK的软件整体框架。1.2.3 DPDK框架简介
DPDK为IA上的高速包处理而设计。图1-6所示的DPDK主要模块分解展示了以基础软件库的形式，为上层应用的开发提供一个高性能的基础I/O开发包。它大量利用了有助于包处理的软硬件特性，如大页、缓存行对齐、线程绑定、预取、NUMA、IA最新指令的利用、Intel DDIO、内存交叉访问等。
核心库Core Libs，提供系统抽象、大页内存、缓存池、定时器及无锁环等基础组件。
PMD库，提供全用户态的驱动，以便通过轮询和线程绑定得到极高的网络吞吐，支持各种本地和虚拟的网卡。
Classify库，支持精确匹配（Exact Match）、最长匹配（LPM）和通配符匹配（ACL），提供常用包处理的查表操作。
QoS库，提供网络服务质量相关组件，如限速（Meter）和调度（Sched）。图1-6 DPDK主要模块分解
除了这些组件，DPDK还提供了几个平台特性，比如节能考虑的运行时频率调整（POWER），与Linux kernel stack建立快速通道的KNI（Kernel Network Interface）。而Packet Framework和DISTRIB为搭建更复杂的多核流水线处理模型提供了基础的组件。1.2.4 寻找性能优化的天花板
性能优化不是无止境的，所谓天花板可以认为是理论极限，性能优化能做到的就是无限接近这个理论极限。而理论极限也不是单纬度的，当某个纬度接近极限时，可能在另一个纬度会有其他的发现。
我们讨论数据包处理，那首先就看看数据包转发速率是否有天花板。其实包转发的天花板就是理论物理线路上能够传送的最大速率，即线速。那数据包经过网络接口进入内存，会经过I/O总线（例如，PCIe bus），I/O总线也有天花板，实际事务传输不可能超过总线最大带宽。CPU从cache里加载/存储cache line有没有天花板呢，当然也有，比如Haswell处理器能在一个周期加载64字节和保存32字节。同样内存控制器也有内存读写带宽。这些不同纬度的边界把工作负载包裹起来，而优化就是在这个边界里吹皮球，不断地去接近甚至触碰这样的边界。
由于天花板是理论上的，因此对于前面介绍的一些可量化的天花板，总是能够指导并反映性能优化的优劣。而有些天花板可能很难量化，比如在某个特定频率的CPU下每个包所消耗的周期最小能做到多少。对于这样的天花板，可能只能用不断尝试实践的方式，当然不同的方法可能带来不同程度的突破，总的增益越来越少时，就可能是接近天花板的时候。
那DPDK在IA上提供网络处理能力有多优秀呢？它是否已经能触及一些系统的天花板？在这些天花板中，最难触碰的是哪一个呢？要真正理解这一点，首先要明白在IA上包处理终极挑战的问题是什么，在这之前我们需要先来回顾一下衡量包处理能力的一些常见能力指标。1.3 解读数据包处理能力
不管什么样的硬件平台，对于包处理都有最基本的性能诉求。一般常被提到的有吞吐、延迟、丢包率、抖动等。对于转发，常会以包转发率（pps，每秒包转发率）而不是比特率（bit/s，每秒比特转发率）来衡量转发能力，这跟包在网络中传输的方式有关。不同大小的包对存储转发的能力要求不尽相同。让我们先来温习一下有效带宽和包转发率概念。
线速（Wire Speed）是线缆中流过的帧理论上支持的最大帧数。
我们用以太网（Ethernet）为例，一般所说的接口带宽，1Gbit/s、10Gbit/s、25Gbit/s、40Gbit/s、100Gbit/s，代表以太接口线路上所能承载的最高传输比特率，其单位是bit/s（bit per second，位/秒）。实际上，不可能每个比特都传输有效数据。以太网每个帧之间会有帧间距（Inter-Packet Gap，IPG），默认帧间距大小为12字节。每个帧还有7个字节的前导（Preamble），和1个字节的帧首定界符（Start Frame Delimiter，SFD）。具体帧格式如图1-7所示，有效内容主要是以太网的目的地址、源地址、以太网类型、负载。报文尾部是校验码。图1-7 以太帧格式
所以，通常意义上的满速带宽能跑有效数据的吞吐可以由如下公式得到理论帧转发率：
而这个最大理论帧转发率的倒数表示了线速情况下先后两个包到达的时间间隔。
按照这个公式，将不同包长按照特定的速率计算可得到一个以太帧转发率，如表1-1所示。如果仔细观察，可以发现在相同带宽速率下，包长越小的包，转发率越高，帧间延迟也越小。表1-1 帧转发率
满足什么条件才能达到无阻塞转发的理论上限呢？如果我们把处理一个数据包的整个生命周期看做是工厂的生产流水线，那么就要保证在这个流水线上，不能有任何一级流水处理的延迟超过此时间间隔。理解了这一点，对照表1-1，就很容易发现，对任何一个数据包处理流水线来说，越小的数据包，挑战总是越大。这样的红线对任何一个硬件平台，对任何一个在硬件平台上设计整体流水线的设计师来说都是无法逃避并需要积极面对的。1.4 探索IA处理器上最艰巨的任务
在通用处理器上处理包的最大挑战是什么？为什么以往通用处理器很少在数据面中扮演重要的角色？如果我们带着这些问题来看数据面上的负载，就会有一个比较直观的理解。这里拿40Gbit/s的速率作为考察包转发能力的样本。如图1-8所示，曲线为不同大小的包的最大理论转发能力。图1-8 线速情况下的报文的指令成本
分别截取64B和1024B数据包长，图1-8所示的线速情况下的报文的指令成本能明显地说明不同报文大小给系统带来的巨大差异。就如我们在包转发率那一节中理解的，对于越小的包，相邻包到达的时间间隔就越小，16.8ns vs 208.8ns。假设CPU的主频率是2GHz，要达到理论最大的转发能力，对于64B和1024B软件分别允许消耗33和417个时钟周期。在存储转发（store-forward）模型下，报文收发以及查表都需要访存。那就对比一下访存的时钟周期，一次LLC命中需要大约40个时钟周期，如果LLC未命中，一次内存的读就需要70ns。换句话说，对于64B大小的包，即使每次都能命中LLC，40个时钟周期依然离33有距离。显然，小包处理时延对于通用CPU系统架构的挑战是巨大的。
那是否说明IA就完全不适合高性能的网络负载呢？答案是否定的。证明这样的结论我们从两个方面入手，一个是IA平台实际能提供的最大能力，另一个是这个能力是否足以应对一定领域的高性能网络负载。
DPDK的出现充分释放了IA平台对包处理的吞吐能力。我们知道，随着吞吐率的上升，中断触发的开销是不能忍受的，DPDK通过一系列软件优化方法（大页利用，cache对齐，线程绑定，NUMA感知，内存通道交叉访问，无锁化数据结构，预取，SIMD指令利用等）利用IA平台硬件特性，提供完整的底层开发支持库。使得单核三层转发可以轻松地突破小包30Mpps，随着CPU封装的核数越来越多，支持的PCIe通道数越来越多，整系统的三层转发吞吐在2路CPU的Xeon E5-2658v3上可以达到300Mpps。这已经是一个相当可观的转发吞吐能力了。
虽然这个能力不足以覆盖网络中所有端到端的设备场景，但无论在核心网接入侧，还是在数据中心网络中，都已经可以覆盖相当多的场景。
随着数据面可软化的发生，数据面的设计、开发、验证乃至部署会发生一系列的变化。首先，可以采用通用服务器平台，降低专门硬件设计成本；其次，基于C语言的开发，就程序员数量以及整个生态都要比专门硬件开发更丰富；另外，灵活可编程的数据面部署也给网络功能虚拟化（NFV）带来了可能，更会进一步推进软件定义网络（SDN）的全面展开。1.5 软件包处理的潜力——再识DPDK
DPDK很好地将IA上包处理的性能提升到一个高度，这个高度已经达到很多网络应用场景的最低要求，使得满足要求的场景下对于网络业务软化产生积极的作用。1.5.1 DPDK加速网络节点
在理解了IA上包处理面临的根本性挑战后，我们会对DPDK所取得的性能提升感到异常兴奋。更令人兴奋的是，按照DPDK所倡导的方法，随着处理器的每一代更新，在IA上的性能提升以很高的斜率不断发酵。当千兆、万兆接口全速转发已不再是问题时，DPDK已将目标伸向百万兆的接口。
DPDK软件包内有一个最基本的三层转发实例（l3fwd），可用于测试双路服务器整系统的吞吐能力，实验表明可以达到220Gbit/s的数据报文吞吐能力。值得注意的是，除了通过硬件或者软件提升性能之外，如今DPDK整系统报文吞吐能力上限已经不再受限于CPU的核数，当前瓶颈在于PCIe（IO总线）的LANE数。换句话说，系统性能的整体I/O天花板不再是CPU，而是系统所提供的所有PCIe LANE的带宽，能插入多少个高速以太网接口卡。
在这样的性能基础上，网络节点的软化就成为可能。对于网络节点上运转的不同形态的网络功能，一旦软化并适配到一个通用的硬件平台，随之一个自然的诉求可能就是软硬件解耦。解耦正是网络功能虚拟化（NFV）的一个核心思想，而硬件解耦的多个网络功能在单一通用节点上的隔离共生问题，是另一个核心思想虚拟化诠释的。当然
试读结束[说明：试读内容隐藏了图片]