大家好，今天我的演讲相对比较特别一点，我想从四个方面来演绎今天这样一个演讲，首先，是一个概述，在这个里面我会讲为什么我们需要做NFV的性能优化。第二个是性能优化方向的探索，也就是我今天的第一个主题，上下求索，我会探寻一下我们怎样来做这样一个性能的优化。第三部分是介绍一下赛特斯2016年在性能优化方面的成果以及我们是怎么做的。最后说一下未来的工作。

首先进入第一个环节，我们为什么要做性能优化？NFV从它单声道现在，我们度过了好几个时期，大家一开始都非常热捧，认为NFV是万能的，逐渐的大家慢慢理性回归，认识到NFV的一些不足，也开始把它和传统的网络设备做对比。

简单对比一下两者的优势，NFV有几个优势，底层平台是通用的，第二有更短的产品研发周期，第三它在部署网络运维和对运营商的业务运营上会有自己独到的优势。
传统设备客观的讲，现在它还是有巨大的性能优化，同时，它具有运营商级别的稳定性，以及在大转发流量下的成本优势。当然，这个成本优势从某些意义上也是性能优势所带来的。

对于稳定性来说，我想云平台是有一些手段在三个9的稳定性下去部分的关注到运营商的需求。但性能始终是NFV走向落地的一个障碍，所以我今天的主题也正是在此。

有句话说得好，问题越大，难度越大，机会也就越大。我们做NFV的性能优化可以带来三个好处，首先是功能，现在普通来说NFV的网源被定义成为适合处理小流量、大绘画的业务，有了这个突破，这个领域可以得到很大的拓宽。第二是运营商最关心的成本问题，当你可以用同样的硬件解决更大的数据流量时，你相对的就会更有竞争力。第三是NFV会带来一个产业门槛的降低，降低厂商的垄断，营造一个正向的百花齐放的良性竞争的生态圈，可以让更多企业参与进来，并达成自己的目的。

第二部分，我们已经确定了要做NFV的性能优化，怎么来做？当我们不知道怎么做的时候，我们不妨回到原点，不管是什么优化，它的目的都是在单位的时间中处理更多的报文，所以这就是我现在要分享的这样一个共识的第一行，我称之为报文处理效率，这是一个非常朴素的公式，在分子分母同时乘上两个系数，当然因为性能优化跟它关系最密切的就是这个CPU，所以我乘的是CPU系数。我引入了两个参数，一个是报文从处理到出去的软件指令指数，第二个是CPU制定用多少得周期处理这些指令。进行简单的组合排列，就会得到下面一排结果，首先报文数量除以软件指令数就等于一个报文要处理的整个流程执行指令数的倒数。第二个指令数，我称之为CPU的处理效率，这个参数有的朋友可能会很奇怪，每一个CPU周期可以执行一个软件指令，但通用的处理方式需要先导入指令，再进行计算，所以这个指令必然小于1，而且是传统设备不会面临的问题。传统设备的值无限趋向于1，每一个CPU的周期都在执行业务指令。所以，它可以用更低的频率实现更高的效能。最后一个没什么好说的，CPU的周期除以时间，就等于CPU主频。这个公式不是我发明的，但是我觉得非常契合今天的主题，分别代表了软件、硬件和软硬结合的优化。

最左边，每一个报文所要执行的软件指令数，代表软件优化的方向，右边CPU的主频代表了硬件优化方向，中间也是我今天想着重讲的，是X86平台做转发要面临的最大问题。
我们找到了这三个方向就开始上下求索，首先向下求索来找寻硬件的解决方案，包括网卡上支持更多的报文硬件分类，更大的寄存器，充分利用带宽，以及网卡更高的稳定性。内存上我们需要更高效的读写速度，尽量使用多路内存，减少错误率和容错率，尽量是容量比较小、但是速度比较快的内存。同时，CPU是今天的主角，更高的主频、更高的合数。

纯软件方案有五个方向，第一个是编译，比如英特尔提供的ICC，第二是一个简单的算法，第三是汇编语言，需要用来写非常精干的语句，但绝对不是主要方向，当然在调试过程中具有非常重要的地位，内存方面需要合理分配内存。

最后上下求索就是指在通用硬件转发中非常关键的一点，寻求软件的执行与硬件架构的契合点，这是由通用硬件的一些属性决定的，我这儿以X86为例，一级缓存和二级缓存是每个核独享的，三级缓存是核间共享的，我把每个缓存访问所耽搁的时间，我们追求在处理相同的软件指令的时候，使用更少的CPU周期，可以看到，英特尔的CPU设计是用更低的设计来适应应用的发展，我们的解决方案是尽量让它处于一个稳定的状态。我们在处理报文的时候需要查的表项尽量放在三级缓存中，让我们的通用设备的CPU运行在一个更加稳定的状态。

我们大概探索了一下需要怎样来做，后面引出今天我们优化的主要对象，赛特斯的主要产品就是虚拟化的宽带网络结入服务器。之所以选择这样一个设备，首先它是一个业务非常综合的设备，城域网的业务汇聚节点，有二层业务也有三层业务，有大量的ACR，有非常繁琐的功能在这个设备上实现。同时，它也有性能的要求，我这里列出了优化之前赛特斯性能的指标，在64K的用户绘画下，4544不丢包大概是128GB的样子。右边是我们的一些环境，左边是最后的结果，我们达到了120G的线速转发能力，加上用户双向绘画的先素之后，我们达到了80GB的先素转发能力。作为我来说，我觉得还是比较振奋人心的。

在这之前我想分享一下对这件事情的理解，我在写这段PPT的时候，就想到了我们南京东南大学的校训，叫止于至善。我今天讲赛特斯的成果也会分部分来讲，也就是明明德、亲民和止于至善。明明德意味着让大家都明白转发过程中的一些原则。我总结了几条原则，第一条大家都知道，工欲善其事，必先利其器，我们需要一非常好的软硬件调试环节。

第二点，DPDK的特点与局限，现在已经成为一个被使用最广泛的开发包或者工具，或者中间件，DPDK事实上做了三件事情，针对网卡内存和CPU，对于网卡它绕开了操作系统内核的驱动，把网卡数据直接交给应用来处理。CPU方面我们通过绑定核的方式，和一些指令的优化，来实现性能的优化。

事实上我的理解，这三点都是为了弥补标准X86的不足，简单的讲，硬件设备没有这个问题，硬件设备的网卡天生不存在带中段式的驱动。硬件设备的CPU同样也不需要去绑定，它需要做一件非常专注的事情。所以，我们了解DPDK是一个伟大的工具，但是绝对不能迷信它所带来的结果。

第三个明明德我想讲的是向量转发。报文的处理是一个非常有示范性的事情，很多的报文处理事实上都是类似的。我总结这么一个过程，当然这个过程比较理想化，我有一批报文，同样要处理头上的三个头，这三个头是要改变内容的。同样改变这三个头可能要读三种不同的表象来做逻辑的判断，同时改变三个头的指令也是不同的。这三个东西都存在于CPU的缓存中，性能就会提升。

大家试想一下，如果一个包一个包这么做的话，效率非常低，这样一个过程下来，你需要反复的把缓存的东西擦掉，所以把一批报文更可能的一次性的处理完，尽量使缓存和CPU处于稳定态，这是对性能非常有帮助的思路。

今年有一个非常火的开源项目，FDIO思科公司分享的，最核心的理念也就是向量转发。

第四个是DoComlete与Pipe line模型，CPU之间可以通过缓存来过渡，这个方式有两个最大的不好，第一，拉长了处理的时间，本身有带来了你要在这个设备中缓存住更多的报文，这个事情本身是一个风险非常大的事情，所谓的夜长梦多。第二个不好的就是它在处理报文的过程中，频度是不一样的，会造成最后会发生矛盾，缓存失衡，性能急剧下降。所以，综合之后我们选择了DoComlete的模式。

最后就是大家都知道的代码编写的坑和雷，我就不一一介绍了，数据结构自查，避免过大的结构体等等。

第二个主题是亲民，我这儿取创新发展的意思，赛特斯在做性能优化的时候有一些创新的地方，第一个是业务表象的处理，业务报文的直观体现是各种各样的表，我在流程中查表做处理再转发，一张表有可能会被很多的业务节点使用。我们在处理它的时候有两个原则，第一个是分割，对不同的业务、对于同一个表象，我们有不同的业务入口，我称之为业务快，同时读写严格分开，右边的边界入口和左边的业务入口完全不一样。

第二个叫预存和预取，做一个业务的时候，我们预先知道它使用哪些数据，并提前从原始数据表中读到业务快。当然，最关键的我也画了，TIB是不能丢失的。

第二个是无锁化，也是类似刚刚的场景，无锁化是一个很漫长的过程，有一些锁是可以避免的，比如在这个场景下，我们在一个业务表象的入口中，用表象的一定程度上的不实时性来换取更高的效率，当一个数据老化了，它需要去释放的时候，如果正在使用快照是不会被释放的。

第三点，是业务节点的合适编排，传统设备的业务是非常复杂的，在我们的场景里，我们尽量要把业务快拆卸成更小的子系统，一方面利用不同的业务流程复用这些业务块，第二也是代表了业务块在选入的过程中可以有更多的选择。最典型的一个案例就是上下行流量的分离，我们会走过不同的业务节点。

第四个是流表和软转发，大家都很清楚，但是我想提的就是流表是一个双刃剑，并不是说什么东西都下沉到流表就好的。流表会引入一些锁的问题，会导致内存空间的不可控，因为流表都比较大。

最后是内存和缓存的合理规划，必须要精确计算每一块内存，什么放在应用程序空间，应该以什么样的布局进行排布。

之后的工作我把它总结成止于至善，赛特斯之后还会有很多的工作，比如说业务全程无锁化，还有现在比较流行的P4和转发面标准化，大容量的ACL和层次化QOS、CPU集成FPGA的尝试等等，赛特斯本身非常开放，也希望有很多的伙伴一起加入这个领域共同做研究和发展。

最后，感谢在今年的工作中给我们支持的企业和伙伴们，谢谢大家！