很高兴来到这里和大家讨论NFV的现状和未来。今天的内容很多，那么长时间现在留下来的应该是无论体力还是劳力，你们都是认真的人。

今天主要有四个议题，一个是说为什么要有网络功能虚拟化，另外一个是讨论一下在网络功能虚拟化的场景下面，我们怎么样应对这些挑战，我们怎样部署底层的IO网络。

我主要是想通过两个底层的两个开源项目，一个是OVS，另外一个是？？（英文），怎么样部署这两个软件项目的。最后想讨论一下关于DPDK。

在网络功能虚拟化出来之前，服务提供商或者电信的运营商，它向设备提供商够专用的硬件或者软件，在软件和硬件之上，部署自己的业务，但是一般来讲，其实这里面有几个问题，第一个是说无论是硬件也好，软件也好，都是因为某种功能而特殊的进行了设计和优化的，所以说它的研发成本会很贵。另外因为它是为特殊目的而服务的，所以它的客户也不是那么广，所以会造成它的成本很高，卖给服务提供商，你的价格会很高昂。运营商购买这个设备了之后，部署的这个软件是和设备商仅仅紧密耦合的，这个耦合性非常高。如果要换一个服务提供商，或者一个设备提供商，你的设备可能要改。当你企业的业务需要扩容的时候，你重新需要部署网络，部署一些布线，服务器，你的扩容，你的运维成本也会很高。

基于这三个问题，我们提出了一个NFV的解决方案，核心应该是只有两点，一个是用市面上可以买得到的通用的服务去替代专用的硬件设备，另外用开源项目的软件去替代专用的一些软件，这样有两个好处，一个是这个硬件和软件完全耦合了，你的设备运营商不会依赖于设备的提供商的一些软件接后。你的采购成本会大大降低，从开源项目和通用的服务器。它的运营成本的问题，NFV主要是通过资源的持化，包括网络功能的持化，还有存储功能的持化，通过虚拟化的方式可以灵活部署自己的业务，使你的运营成本也会降下来。

在网络功能虚拟化的环境下面，对我们底层的数据面提供了什么样的需求呢？我想大概不外乎几点，一个虚拟化，一个是高性能的网络，易于编成，有很强的灵活性，可以快速的进行热迁移，这个是对我们数据面提供的一些要求。在几年以前，我们是怎么样的一种方式呢？我们写一个应用程序，通过内核的网络，把这个数据包文发送到网卡上面去，再送到网络上面去，这传统的方式。所以又有了右边两种的编程模式。通过网络，把网络设备，主要是网卡，通过虚拟化，通过把网络功能切片的方式，虚拟化采用SRV的技术，把VS部署到虚拟机里面去，一种用传统的SOCKET的方式，还有一个轮训驱动的方式，有比较不好的缺点，编程灵活性不是太好。

综上所述，我们有一个比较好的编程模型，我在虚拟机和底层的网卡之间家属一个虚拟的交换机，所有的报文只要进出网络都要经过这个交换机，通过软件交换机的方式可以对它灵活的进行编程，而且实现一些差异化的服务，或者说做一些流量监控，防火墙等等。在虚拟机里面它不能再使用SRV的方式，可以解决之前的一些问题。事实上这种方案和SRV相比，你的性能也好，延时也好，其实大大降低了，是通过网卡，不是通过SRV的方式，主要是通过软件虚拟出来的一个网卡，所以是CPU来做的，所以你的性能不是很好。我并不是说右边的这种方案是一个完美的方案，像张总说的没有最好的方案，只有最适合的方案。每个方案的部署，它都有自己的需求，只有把这些需求转换成对技术的需求，才会是一个最好的方案。

OS现在有两种版本，把DPDK？？（英文）做一个后端，从而获得有一个比较好的性能，这个OVS怎么样运用到NFV的场景下面，怎么预设进去呢？它里面有两个？？（英文），可以很容易的？？（英文）。

FD最早是和思科，和因特尔最早提倡开源的项目，很多厂家都积极的加入到里面，也包含了很多的子项目，这些子项目也是独立运行，其实它主要的目的就是打造一个四成到七成协议上面很好的工具，好的库，并且实现高性能的高处理。中间有一个大块，叫？？（英文），把网卡的功能进行抽象的一种VPI，当用户程序使用这种VPI的时候，你不需要关心这个问题，因为它有一个统一的接口。

？？（英文）的驱动中断的一种程序，从收到中断到用户真正拿到这个数据包，执行度是非常长的，并且有各种各样的？？（英文），这种的编成方式不是那么好，是采用一种轮训的方式采用数据报文的。在左边有？？，主要的方式是体归了很多关于？？，关于？？的一些API，之所以有这些API的作用，因为我们是打造一个快速报文处理的一个包，而这些小的库完全实现了很多的优化，比如说？？的一种方式。下面还有流分类，包括一些？？的实现，包括右边还有一些关于硬件加隐秘设备的一些指示，DPDK不仅仅只有我刚才介绍的那么多，实际上有很多的库，其他的一些功能，其实大家可以去发掘。

这个是关于？？的一个知识，其实很简单，为了支持？？，我们创建了一个？？的？？，叫？？，它虚拟化作为一个？？网卡，从而？？可以使用。

这里谈一下DPDK的性能。我们经常聊到DPDK的时候一定会说DPDK性能到底是什么样的，这个是因特尔主机的转发能力的示意图，竖轴是每秒钟可以处理多少个报文。从2010年到2015年，我们从55兆到现在提高了六到七倍。另外一方面是各种的优化才能达到这么好的性能。

哪里可以下载到DPDK？一个就是在DPDK？？，这上面可以下载到最新的原代码，可以下载到所有的文档。从OS的？？里面，？？它们自己都已经集成了DPDK的版本，问题是这里面的DPDK版本不是那么新，如果想要获得最新的还是到DPDK.？？去下载。他们提供的这些DPDK的版本肯定是当前的OS版本上面跑的比较稳定的，他们经过一些测试的，所以说这算一个好处吧。

我这里想通过一个问题来引发DPDK采用了哪些性能优化的技术。这个问题是什么呢？想象一下，如果我们说我们的主机能够达到40GD限速转发能力，我有个主机接收到网络包问，每秒钟有40G的流量，收到了之后同样有能力在这一秒以内把这40G的流量再转发出去，40G的流量换算成报文是多少个呢？差不多每秒有60个包，平均每17纳秒就会有一个报文到达主机，纳秒是秒，毫秒，微妙，纳秒。现在有一个服务器，主屏是2G，差不多每33个使用周期就要处理一个网络报文，33个使用周期是什么概念呢？我们大家都知道？？是离CPU最近的一个部件，L2是1个工作周期，L3差不多36-40个使用周期。再考虑到我处理网络报文的时候我是要读？？写？？，大概是100多个使用周期到几百个使用周期不等，我实行最简单的报文处理，CPU把和网络报文读进来，什么也不做，仅仅把它读进来，把它转发出去，大概涉及到多少个内存图形呢？至少应该有6-10次左右，驱动怎么写呢？通盘的考虑这个问题，要处理一个网络报文，仅仅内容就需要1000个以上了，但是我们的要求是说你只有33个？？去考虑内存。你还要进行上下文的切换。所有的东西加起来把我们的任务变的不可能完成一样的。

在这个？？下面，我们首先第一个不能采用传统的？？的推动使用？？的方式来处理报文。我们的渠道有三大块，第一个内存读写的言词，第二个是？？第三个是有进成上下文切换。我们看看有哪些优化的技术去把这个时间找回来。第一个是DDIO，当你P3设备发送数据到主机的时候，它不是直接送到？？的，它是？？和？？各送一份，如果CPU要处理这些网络报文不需要到？？去拿了，已经放到？？，最多也只需要30级的？？就可以拿到这个网络报文了。

另外一个方式，我可以写一个好的驱动程序，在处理当前报文的时候可以提前知道下一个网络报文要处理的时候，那些数据结构或者相应数据报文在哪里，可以通过一些软件和硬件的方式，把内存结构从？？那边读到？？里面，可能还不够，还通过一些指定的？？的方式直接读到？？，从而使我们的CPU以最小的代价访问这些内存结构体。

除此之外，我们用了其他的方式，我们知道我们这个CPU其实上是有？？的，一般是译码，然后读数据，然后计算，回写结果，事实上从你取数据，到真正能够计算，这里面有？？的，有很长的时间间隙的，在这个时间段可以采用一些优化技术，比如说我在上一次要访问的数据结构的时候，就把下次需要的数据结构直接放到？？里面来，避免了等待的时间。我们还使用了一些？？指令，这个指令是一个SIM（音）的指令，通过一条指令能够同时处理多个报文。还涉及到一些？？的对齐，？？等等。

怎么样保证不被？？的？？能够进行筛选和切换呢？现在有一个？？的技术，可以把一个软件的现成绑定到某一个？？上面执行，避免被进程调输这样？？的问题。关于？？我们也有其他的一些优化的方法，我们常规都是4K为页码，？？会变的越来越多。当你访问这个内存很大的时候，他们总会有一定几率出现？？，我们怎么样解决问题呢？我们使用一个大页，什么是大冶的方式？我们可以说见效在？？当中安全的数量，从而避免？？的？？。

之所以提出这个优化方法的目的，一个是跟大家解释一下DPDK怎么样获得？？，另外一个，DPDK好像飞的很慢，大家在自己的程序例找找打造一个快速的高效的解决方案。