DPDK在国产申威处理器平台上的应用与研究

明 旭 何慧文 陈 磊

(北京中科网威信息技术有限公司 北京 100094)(mingx@netpower.com.cn)

1 申威处理器与DPDK

处理器不自主，整个信息产业就是建筑在沙滩上的城堡.发展真正自主可控的处理器，对中国这样一个正在崛起的大国而言，不仅意味着可以拥有更加安全可靠的信息基础设施，更意味着在信息经济时代掌控着事关国家经济安全的重大技术话语权.

申威处理器是经过10多年的磨砺，凝结了无数科研人员的心血，独立自主发展起来的国产处理器.10多年来，申威处理器从无到有，核心微结构持续升级，生产工艺不断改进，先后研发了core1,core2,core2a,core3这4代处理器微结构，生产工艺也从最早的0.13 μm提高到了现在的28 nm.全部采用申威26010众核处理器的“太湖之光”超级计算机，这2年来大放异彩，连续4次登顶世界超算TOP500，在“太湖之光”上运行的应用更是史无前例地连续2年获得戈登贝尔奖[1].申威处理器在超算领域取得的巨大成就说明，和10多年前相比，申威处理器的性能、稳定性都实现了跨越式的提升，已经初步具备与当今国际先进处理器相抗衡的能力[2].

在网络安全领域，围绕申威多核处理器的自主可控安全生态从无到有，日渐发展，现在已经初具规模，已经有十几家公司采用申威处理器推出了防火墙、网闸、入侵检测、漏洞扫描、数据库审计等各类网安产品[3].但这些产品与采用X86处理器的同类产品相比还是存在一些差距，主要体现在产品的性能上，其中的主要原因有2点：1)申威处理器单核性能与X86处理器相比还有50%左右的差距；2)X86等处理器的生态，经过几十年发展，通过不断的尝试和探索，在与网安产品密切相关的网络数据包处理技术方面，发展出了一系列较为成熟、高效的模型和框架，如：新浪的fastsocket，PowerPC的DPAA，Intel的DPDK.

1.1 网络数据包处理框架与DPDK

在多核多线程处理器平台上进行网络数据包的处理，使用传统的Linux内核协议栈会存在严重的性能瓶颈.对于如何提高网络数据包处理的性能，业界有着比较统一的认识和建议：

1) 尽量不要让不同的线程访问临界资源，因为互斥上锁会降低系统的执行效率；理想情况是让每个线程只访问自己的资源和数据结构.

2) 线程数能少则少，因为线程在各个CPU核心上的调度会造成一定的切换开销，并且造成Cache命中率的降低.

3) 优化数据包的进出路径，尽可能减少数据的拷贝，特别是内核态和用户态之间的数据拷贝.

在具体实践中，综合上述建议，有2个主要的优化策略可供选择：1)依照上述建议不断优化Linux内核协议栈[3]，代表项目如新浪的FastSocket.FastSocket对协议栈的优化主要体现在单核处理性能的提升，相比传统协议栈能够提升20%～45%的性能；另外，在多核性能优化上也有着一定的性能提升.2)采用全新的架构设计，使数据处理的路径绕过内核协议栈，代表项目如Intel的DPDK.

DPDK(Intel data plane development kit)是Intel提供的数据平面开发工具集[4]，为IA(Intel architecture)处理器架构下用户空间高效的数据包处理提供库函数和驱动的支持.不同于Linux系统以通用性设计为目的，DPDK专注于网络数据包的处理，针对X86处理器和网卡作了一系列的深度优化，从而提升数据包吞吐量[5].

DPDK不使用原有的内核协议栈，所有的应用需要使用DPDK提供的函数进行重新开发.但与使用内核协议栈相比，DPDK的优势除了减少中断次数和数据拷贝次数外，还使得相关应用获得了协议栈的控制权，能够通过定制降低协议栈复杂度.理论上，使用DPDK方案，应用的网络数据包处理性能可以达到采用传统Linux协议栈方案10倍以上.

1.2 DPDK应用在申威处理器平台的意义

在处理器微架构设计上，国产申威处理器与国际主流商用处理器已经基本保持了一致, 如超标量、乱序执行、大容量Cache、双访存流水线等.而且由于申威处理器采用的指令集架构自身的特点，相比采用CISC架构的X86处理器，可以高效集成更多的处理器核心；但由于生产工艺相对不高，特别是处理器的访存能力仍需进一步提升，使得申威处理器的单核性能仍存在相当的差距.

DPDK的出现给国产申威处理器在网络应用上扬长避短带来了重大机会.首先，DPDK使用大页缓存技术、内存池和无锁环形缓存管理等技术来提高内存访问效率；同时，利用PMD支持，提供应用空间下驱动程序的支持，减少了报文的内存间拷贝.这些技术都使得申威处理器访存能力不足的问题得到了相当程度的弥补.另外，DPDK广泛采用处理器核亲和技术，把各项处理作业分配到特定的处理器核上分别处理，从而发挥各个处理器核的潜能.这又使得申威处理器核多的优势得到较为充分地发挥.

结合申威处理器的自身特点，将DPDK高效地移植到申威处理器平台上，可以大幅提高申威处理器平台的网络处理能力，在网络数据包处理方面进一步缩小和X86等处理器之间的差距，可以为在申威处理器平台上实现多种高速网络应用提供有效的技术支撑,从而拓宽国产申威处理器在网络设备、网络安全设备、存储设备、高性能服务器等产品领域的应用，同时也可以为DPDK向其他自主国产处理器上的移植提供有价值的参考.

2 DPDK概览

从字面解释上看，DPDK是专注于数据平面软件开发的套件；本质上，它是一组可以从用户空间调用的软件库，提供了一种开销更小的方法来代替传统的Linux系统调用，使得应用程序可以绕过内核直接和底层硬件交互.

网络数据包不再通过内核，而是直接走DPDK的专有路径，从网卡直接到达用户空间，交由用户处理，从而将繁重的数据包过滤、数据包转发工作从内核态转至用户态.

另外，DPDK实现了多核“无锁”并行结构，使多处理器核心可以高效并行工作，并充分发挥速度越来越快的IO接口的能力，从而最大限度上提高网络数据包处理效率.

使用DPDK，将不能再用原来的Linux内核协议栈，而且所有的应用都需要基于DPDK提供的函数库进行重构.但由于网卡等设备的驱动程序都运行在用户层，不容易崩溃，调试方便，可以大幅降低高性能网络数据处理程序开发、调试的难度[6].

2.1 DPDK架构

从总体架构图(图1)我们可以看出，DPDK将全部功能都从内核态搬到了用户态[7].

1) EAL(environment abstraction layer)即环境抽象层，为应用提供了一个通用接口，隐藏了与底层库与设备打交道的相关细节.EAL实现了DPDK运行的初始化工作，包括基于大页表的内存分配、多核亲和性设置、原子操作和锁操作，将PCI设备地址映射到用户空间，方便应用程序访问.

2) Buffer Manager API通过预先从EAL上分配固定大小的多个内存对象，避免了在运行过程中动态进行内存分配和回收来提高效率，常常用作数据包缓冲来使用.

3) Queue Manager API以高效的方式实现了无锁的FIFO环形队列，适合与一个生产者多个消费者、一个消费者多个生产者模型来避免等待，并且支持批量无锁的操作.

4) Flow Classification API通过Intel SSE基于多元组实现了高效的hash算法，以便快速地将数据包进行分类处理.该API一般用于路由查找过程中的最长前缀匹配，应用中根据Flow五元组来标记不同用户的场景也可以使用.

5) PMD则实现了Intel 1GbE，10GbE和40GbE网卡下基于轮询收发包的工作模式，大大加速网卡收发包性能.

图1 DPDK总体架构图

2.2 DPDK关键技术

DPDK之所以可以提供高性能的数据处理能力，在于它从驱动、内存、线程、Cache等各个方面所做的综合性的深度优化，这些优化主要包括：

1) 使用大页内存，降低Cache miss，提高命中率，进而提升处理器访问内存的速度；

2) 使用PMD技术，将报文直接拷贝到用户态进行处理；

3) 通过CPU亲和性绑定网卡和线程到固定的CPU核，减少处理器核间任务切换的开销；

4) 使用无锁队列，减少资源竞争.

下面简要介绍DPDK的这几项关键技术[8]：

1) 使用大页内存(hugepage)提高内存访问效率.

TLB(translation look-side buffer) Cache是CPU中单独的一块高速缓存，为了实现虚拟地址到物理地址的转换，Linux首先要查找TLB Cache来进行快速映射.如果在查找时TLB没有命中，就会触发一次缺页中断，处理器就需要到内存中去访问多级页表，才能最终得到物理地址，从而导致极大的处理器开销.

Linux默认页大小为4 KB，在程序使用大内存时，需要大量的页表表项才能保证不出现TLB不命中的情况.而TLB Cache的大小是很有限的，一般只能容纳100条页表表项，只有使用hugepage才能确保TLB Cache的全命中.

为此，DPDK缺省提供了2 MB和1 GB这2种方式的hugepage支持.测试表明使用大页表比使用4 KB的页表性能提高10%～15%

2) 使用PMD(poll mode drivers)，将网络数据包处理工作全部迁移到用户态，并以全轮询的模式进行处理.

NAPI明显改善了传统Linux系统的包处理能力，但由于收发包仍然以系统中断为基础，首先是从中断发生到应用感知，还要经过很长的软件处理路径；另外，数据包在内核态和用户态之间的拷贝也难以避免.总之，对内核协议栈进行改良的NAPI等机制还是不能充分发挥底层硬件的能力，不能真正释放出其网络数据包处理的能力.

DPDK针对Intel网卡实现了基于全轮询方式的PMD驱动，该驱动由API、用户空间运行的驱动程序构成，使用无中断方式直接操作网卡的接收和发送队列.PMD驱动从网卡上接收到数据包后，会直接通过DMA方式传输到预分配的内存中，同时更新无锁环形队列中的数据包指针，不断轮询的应用程序很快就能感知收到数据包，并在预分配的内存地址上直接处理数据包，这个过程非常简洁.

另外，由于整个处理过程都在用户空间完成，自然规避了报文在核心态和用户态之间的拷贝[9].

目前PMD驱动支持Intel的大部分1 G,10 G和40 G的网卡.

3) 利用Linux亲和性支持，避免线程在不同核间的切换.

在单个处理器核上，多线程可以提高各应用的并发运行程度，从而提高CPU的整体利用率；但线程的创建和销毁都有开销，还会引入上下文切换、访存冲突、Cache失效等诸多消耗性能的因素.在CPU多核时代，可以通过仔细规划线程在CPU不同核上的分布，达到既保持应用的高速并发运行，又减少线程切换开销的目的[10].

DPDK就利用了Linux线程的CPU亲和性，将特定任务绑定到只在某个CPU核上运行，从而避免线程在不同核间的频繁切换，减少Cache miss和Cache write back等性能损失.

DPDK运行在用户态，但线程的调度仍然依赖内核.作为更进一步的优化，DPDK使用了限定某些核不参与Linux系统调度的技术手段，使特定的任务线程(如网络收发包线程)可以独占CPU核.这对网络数据包的全轮询处理起到了重要的支撑作用.

4) 提供无锁环形缓冲区管理和缓存池，提高内存访问效率.

当前的多核处理器特别是服务器处理器通常提供4个、8个甚至更多的CPU核，在诸多高并发应用中，多个CPU核之间访问内存等资源时产生的锁竞争有时会比数据拷贝、上下文切换更加伤害系统的性能.因此，在多核环境下，如果能够把重要的数据结构从锁的保护下迁移到无锁机制中，可以极大地提升应用软件的性能.

DPDK基于无锁环形缓冲的原理，实现了一套无锁环形缓冲区队列管理API，支持单生产者入列单生产者出列、多生产者入列多生产者出列的操作，很大程度上提高了内存访问的效率[11].

另外，DPDK提供的缓存池，可以将多个收发包集中到一个Cache line，进一步提升了Cache利用率.

3 DPDK移植申威处器平台难点要点分析

DPDK是Intel专门为X86处理器定制的，将DPDK移植到申威处理器平台上肯定会面临诸多的技术挑战.为此，我们对申威处理器及其指令集以及DPDK本身都进行了较为深入的技术预研，从而在移植可行性、移植难度、所需资源上给后续的工程化研制提供评估基础.

本节首先介绍我们在先期研究中发现的移植上可能存在的一些技术难点，然后介绍我们应对这些难点的策略，最后，介绍我们在预研中总结出的，基于国产申威处理器进行高性能网络数据处理功能(包括但不限于DPDK)的研发的一些要点，希望能让在国产申威处理器上研发各类网络产品的同行有所借鉴.

第4节将介绍我们基于SW411硬件平台，初步移植DPDK并搭建的防火墙原型机，主要用于验证在类似DPDK的全用户态轮询模式下，网络数据包收发系统的性能是否会有质的提升，从而为使用基于非X86架构的国产处理器研发高性能的网络产品和网络安全产品提供一定的实践支撑.

3.1 移植难点

通过预研，我们认为将DPDK移植到申威平台上的技术难点主要有3个：

1) DPDK无协议栈

DPDK不能再使用原有的内核协议栈，相关功能都需要依照DPDK提供的函数库进行重构开发.理论上，需要在用户态实现Linux内核协议栈的大部分功能，这可能会导致所需的时间成本和人力成本难以接受[12].

2) 申威没有专门的CAS指令

在X86处理器上运行的DPDK大量使用CAS(compare and swap)指令，为在多核间实现高效的数据同步发挥了极其重要的作用.基于RISC架构的申威自主指令集采用的是LoadStore型指令系统，没有专门的CAS指令.这为移植工作带来了很大的麻烦和风险.

3) 申威SIMD支持与Intel SIMD指令集不完全兼容

SIMD(Single Instruction Multiple Data)意为单指令多数据[13]，以特定宽度(如64 b)为一个数据单元，多数据指的就是多个可以独立操作的数据单元，SIMD指的就是单个指令可以同时作用到多个数据单元.

实现SIMD需要处理器硬件的支持，处理器需要集成专门的SIMD寄存器.Intel处理器提供了128 b的XMM寄存器或者256 b的YMM寄存器,也称为SIMD扩展部件.

申威处理器也提供SIMD支持，但申威指令集中的SIMD指令与Intel的SIMD指令对应性不强，移植中有大量相关代码需要手工修改，对移植工作是一个重大挑战.

3.2 难点解决策略

针对预研中发现的几个难点，我们结合以往的研发经验，反复尝试，基本都找到了比较满意的解决途径.

1) 构建“慢速路径+快速路径”的处理构架

针对DPDK无协议栈的问题，通用解决办法一般有2种：1)自己开发;2)使用开源协议栈与DPDK适配.自己开发工作量太大，而我们评估了几个开源协议栈，其成熟度和稳定性都和Linux协议栈相去甚远，而且适配的工作量也不小.

为此，我们结合网络数据包处理的特点，设计了一个稳定、高效的框架，其基本原理在于：路由的确定、过滤规则的匹配在一个会话流的第1个数据包就可以决定[14].因此，可以基于DPDK构建一个“慢速路径+快速路径”的处理框架，在网络会话的建立、撤销等阶段，仍将数据包交由Linux内核协议栈处理；会话成功建立后的后续数据包直接交由基于DPDK的上层应用处理.这样，只有极少量的数据包在“耗时”的慢速路径上流转，大部分数据包将通过在快速路径上建立的流表快速转发.

其原理图如图2所示：

图2 DPDK+Linux协议栈的快速、慢速处理结构

构建“慢速路径+快速路径”的处理构架的主要难点在于，要在用户态下实现与内核协议栈相匹配的、用于会话控制、会话状态记录的数据结构，并让相关的会话记录和会话状态的改变保持实时的同步.另外,对于数据包7层以上协议数据的分析，要尽量保证在会话流起始的一个或者几个数据包中完成判断[15].

2) 高效模拟CAS指令

在申威指令集不提供CAS指令的情况下，用申威指令模拟实现一个功能完全一致的CAS函数，可以最大程度上减少代码移植的工作量.

在实际移植工作中我们反复实验，最终确定了用11条申威汇编指令组成的最优CAS模拟，经过实际测试，效果令人满意，不但功能满足要求，性能表现也足够优异.

3) 封装申威SIMD

SIMD技术广泛应用于通用处理器，为提升程序性能提供了硬件支持.实际工程经验显示，如能充分发掘程序中的并行性，进行基于SIMD的优化，可以使应用的性能得到50%～70%的提升.DPDK中就大量使用了SIMD进行各类并行化数据处理.

申威指令集也提供了对SIMD的支持，而且出于超算的需要，技术上成熟、高效——通过使用申威的SIMD扩展指令系统，可以完成256 b的8倍字整数数据的单指令存取，将8～64 b的待运算数据合并为一个256 b的超长数据，然后使用一条指令完成传统多条指令才能完成的运算.

但申威指令集与Intel的SIMD指令集对应性不强，移植中有大量相关代码需要手工修改，如不采取相关技术手段会导致移植工作繁琐杂乱，并且给代码以后的升级维护造成障碍.

我们仍然采用了和模拟CAS指令相类似的技术手段，通过一系列细致的分析和编程工作，对申威SIMD指令进行了较为彻底的封装，使DPDK的代码无需任何修改即可直接在申威处理器上运行，让程序员从繁冗复杂的移植编码工作中解脱出来，提高了移植工作的效率，并使得整个移植后的系统具备了较为良好的可扩展性.

3.3 技术要点

DPDK的本质是网络数据处理的“最优工程实践经验”的总结，在移植工作中只知道照搬照抄是很难体会其思想内涵的.在本节内容中，我们尝试不局限于DPDK，总结了几点我们对基于国产申威处理器进行高性能网络数据处理功能研发的一些“实践经验”，希望能让在国产申威处理器上研发各类网络产品的同行有所借鉴.

1) 网卡的多队列机制和申威CPU多核的紧密结合

当前主流的千兆、万兆网卡芯片都提供了内置的负载均衡算法，能够将高速的网络数据流分为多个数据队列，这些数据队列以内存硬件通道的形式展现在CPU的面前，CPU可以让自己不同的核去访问不同的通道，核之间对队列的数据读写不会相互影响[16].

申威处理器相比X86处理器，可以高效集成更多的处理器核心，配以网卡的多队列机制，理论上可以获得更高的并发处理能力.

但是，如果对PCI-E总线的访问不能做到高效，会导致并行数据流处理带来的性能优势部分损失.

这就需要深入理解和分析申威处理器的PCI-E总线接口芯片的工作原理，理解申威处理器PCI-E事务的基本数据包交换单元TLP(transaction layer packet)和网卡数据包之间的关系.在此基础上，可以通过调整网卡驱动对数据包的封装，使之与TLP更匹配，从而做到网卡芯片与申威多核之间的紧密结合[17].

另外，减少MMIO的访问频度也是提升PCI-E并行传输能力的关键点.

2) 内存的高效访问

多个CPU核访问同一段内存池甚至同一个环形缓存区时，因为每次读写时都要进行Compare-and-Set操作来保证期间数据未被其他核心修改，所以存取效率较低.需要研究的是在应用软件中，通过包括DPDK支持在内的手段，尽量让每个核只访问自己的数据，从而使其所要处理的数据尽可能缓存在自己的Cache中.另外，尽量对环形缓存区进行块读写操作，以减少访问环形缓存区的次数[15].

3) 收发包批处理

收发包是一个相对复杂的软件运算过程，其中主要包含缓存的分配与释放、描述符的解析与构造，涉及多个数据结构的读、写访问[18].

只要涉及比较多的数据访问，就应尽量让数据访问都能在处理器缓存中完成( Cache hit)，这是实现高性能网络数据包处理的重要手段.反之，Cache miss会导致内存访问，引人大量延迟，是性能杀手.

对收发包实现批处理是一项细致但物有所值的工作，其基本原理是把收发包复杂的处理过程进行分解，打散成不同的相对较小的处理阶段，把相邻的数据访问、相似的数据运算集中处理.这样就能尽可能减少对内存或者低一级的处理器缓存的访问次数，用更少的访问次数来完成更多次收发包运算所需要数据的读或者写.在这方面，我们还需要有更多的实践经验积累[19].

4) 针对小包的Cache预取机制优化

申威处理器的Cache line为128 B，Intel平台的Cache line为64 B；对于64 B小包来说，一次Cache预取在Intel平台下刚好完全使用，而申威会浪费一半的Cache资源.为了高效使用申威处理器的Cache，需要重新设定频繁访问的数据结构的Cache align(Cache对齐)为128 B，并修正数据包内存池，以便让2个64 B小包连续存储.这样在进行数据包预取时，一个预取指令可以缓存2个小包，同时避免了宝贵的Cache资源的浪费，大大提升了申威处理器对小包的处理能力[20].

4 原型机简介

我们研制的原型机主要用来验证影响网络数据包处理的核心问题——性能，在基于申威处理器的DPDK框架下是否可以得到大幅提升.原型机在整体结构和应用逻辑上的设计应该尽量简洁，以方便发现整个系统在DPDK框架下的处理逻辑的性能瓶颈，从而针对相关瓶颈进行性能优化.

原型机的成果可用于快速评估SW-DPDK在申威平台上的应用效果，相关测试参数和软件构架可以指引后续更复杂的防火墙、路由器、VPN等其他商用安全产品研发的可行性分析与架构设计.

4.1 设计方案

以DPDK平台为基础开发平台，搭建调度模块、配置模块、规则匹配模块(含静态路由匹配)、流匹配模块、收包模块、发包模块和日志模块.

图3给出了这些模块的逻辑关系：

图3 模块的逻辑关系图

1) 调度模块负责加载运行其他模块；

2) 由人工(或者从存储数据中)输入ACL规则、静态路由规则，这些规则通过规则逻辑进入规则匹配模块；

3) 人工操作(添加、删除、修改)的ACL规则、静态路由规则会被日志模块记录；

4) 流匹配模块是根据收到的数据包和ACL规则、静态路由规则动态构建的；

5) 流匹配情况、规则匹配情况会被日志模块记录；

6) 收到数据包后先进行流匹配再进行规则匹配，允许通过的数据包会通过发模块发出.

4.2 实施过程

原型机的研发工作分为移植、优化和应用3个阶段：

1) 移植阶段：

① 在SW411环境下重新编译DPDK代码；

② 初步优化汇编指令代码，包括O3,RTC,CAS锁等；

③ 实现转发Demo：只做转发，不做查表处理等工作，并初步测试、评估DPDK的能力.

2) 优化阶段

① 在转发Demo基础上进行系列的匹配和优化工作，主要包括：内存访问到chip的并行、尽量保证Cache的对齐和一致、申威处理器的SIMD功能应用、按照core分配内存、队列HASH锁等；

② 深度优化：交叉内存、Cache、SIMD；

③ 结构设计：网卡多队列、多核并行.

3) 应用阶段

① 面向逻辑处理完善系统功能，包括多核并行的表优化，使用SIMD进行查表等；

② 提供基于申威DPDK的防火墙原型机，进行性能对比测试.

4.3 性能对比

测试对象：SW411平台通用型设备、基于DPDK技术加速的防火墙原型机.

测试条件：1对千兆口，100条流平均分配到多个处理器核，60 s时长，采用桥模式，默认全通配置，初始值100%.

测试标准：RFC2544吞吐、时延.

测试结果如表1所示.

测试结论：在基于SW411处理器的硬件平台上应用DPDK框架后，64 B小包吞吐率提升12倍以上，1 518 B大包时延降低95%左右.因为已达到线速，小包吞吐率应该仍有进一步提升的空间，这将有赖于支持万兆的原型机进行验证.

表1 通用型设备和基于DPDK技术加速的防火墙原型机性能对比表

5 结束语

经过10多年的持续发展，国产申威处理器在性能、稳定性方面都取得了长足的进步，已经基本具备了与当今国际先进处理器相抗衡的能力.在网络安全领域，已经有很多公司采用申威处理器推出了各类产品，但由于申威处理器单核性能的不足，以及缺少先进网络数据包处理模型和框架的支撑，这些产品与采用X86处理器的同类产品相比，在产品性能等方面还存在一些差距.

DPDK等用户态网络数据包处理器框架的出现给国产申威处理器在网络安全等产品的应用上带来了扬长避短的机会，将DPDK之类的框架移植到申威平台上可以发挥申威处理器的多核优势.

本文分析了将DPDK移植到申威处理器平台上存在的难点，并提出了应对这些难点的解决策略和关键技术.进一步，我们总结了几点在国产申威处理器平台上进行高性能网络产品研发的实践经验.最后，介绍了我们基于申威411芯片，在移植DPDK的基础上研发的防火墙原型机，验证了在DPDK的全用户态轮询模式下，网络数据包收发系统的性能取得的巨大提升，64 B小包的吞吐率从原始的7.2%提升到了100%线速.

最后，在此次移植工作的基础上，我们对未来基于申威处理器平台和用户态数据包处理框架的网络安全产品的研发作如下预测和展望：

1) 申威处理器的持续发展将使DPDK等框架发挥更大潜力

申威1621处理器是基于增强版的第三代“申威64”核心的国产高性能多核处理器，单芯片集成了16个64 b RISC结构的申威处理器核心.在指令集和微结构方面，申威1621处理器也提供更多的功能支持，如预取指令支持、NUMA支持和虚拟化支持等.

我们初步评估，在申威1621的指令优化和16核支撑下，DPDK等框架的潜能可以得到进一步的发挥，将可以实现线速的万兆防火墙产品.

2) DPDK等框架会促进申威处理器指令集与微架构的进一步提升

由于各种原因，申威处理器一直比较注重与超算相关的浮点运算等能力的提升，对网络数据包处理能力的重视程度不高.有助于充分发挥申威多核优势的DPDK等框架的出现，会提升申威多核服务器处理器对高性能网络数据包处理领域的关注度.可以预见，申威处理器在指令集和微架构优化等关键技术上将会加大这方面的支持.我们非常期待CAS无锁指令、类DDIO支持等功能在下一代申威服务器处理器中的出现.

3) 基于申威处理器和先进网络数据包处理器框架的自主可控网络安全生态建设将大有可为DPDK等先进数据包处理框架与申威处理器的结合，使得多种以网络数据包处理为基础支撑的自主可控网络安全产品，如自主可控防火墙、自主可控VPN、自主可控IDSIPS、自主可控加密机等，可以在申威处理器平台上达到较高的性能水平，满足对使用非自主可控处理器的安全产品实施自主可控替代的要求，从而推动自主可控安全产品在军队、军工、政府重要部门的应用，进一步推进我国自主可控安全生态的建设.

[1]贾迅, 胡向东, 尹飞. 申威处理器硬件数据预取技术的实现[J]. 计算机工程与科学, 2015, 37(11)

[2]陈左宁,王广益, 胡苏太, 等. 大数据安全与自主可控[J]. 科学通报, 2015, 60(5/6): 427-432

[3]沈昌祥. 可信计算专题综述[J]. 计算机安全, 2006 (6): 2-4

[4]DPDK: Data plane development kit[OL]. [2017-12-15]. http://dpdk.org/

[5]Casoni M, Grazia C A, Patriciello N. On the performance of Linux Container with Netmap/VALE for networks virtualization[C] //Proc of the 19th IEEE Int Conf on Networks (ICON). Piscataway, NJ: IEEE, 2013: 1-6

[6]Stevens W R. TCP/IP详解(卷1)——协议[M]. 北京: 机械工业出版社, 2011

[7]Rizzo L. Netmap: A novel framework for fast packet I/O[C] //Proc of the 2012 USENIX Conf on Annual Technical Conf. Berkeley, CA: USENIX Association, 2012: 9-9

[8]Wright G R, Stevens W R, et al. TCP/IP详解(卷2)——实现[M]. 北京: 人民邮电出版社, 2010

[9]刘军卫. 用户态驱动框架的研究与实现[D]. 合肥: 中国科学技术大学, 2011

[10]卡耐基梅陇大学并行实验室[OL]. [2017-12-15]. http://www.pdl.cmu.edu/

[11]DPDK技术白皮书[M]. 广州: 中国电信股份有限公司广州研究院. 2015年10月

[12]Morari A, Gioiosa R, Wisniewski R W, et al. Evaluating the impact of TLB misses on future HPC systems[C] //Proc of the 26th IEEE Int Parallel and Distributed Processing Symp. Los Alamitos, CA: IEEE Computer Society, 2012: 1010-1021

[13]Koka P, Mccracken M O, Schwetman H D, et al. Combining a remote TLB lookup and a subsequent Cache miss into a single coherence operation: US, US9003163[P]. 2015-04-07

[14]蒋苑青. 多处理器系统的线程调度策略研究[D]. 成都: 电子科技大学, 2012

[15]肖月振, 华蓓, 基于多核处理器的无锁零拷贝数据包转发框架[J]. 计算机工程, 2013, 39(12): 35-39

[16]周伟明. 多核计算与程序设计[M]. 武汉: 华中科技大学出版社, 2009

[17]童浩, 陈兴蜀, 严宏. 改进及优化Linux网络协议栈[J]. 电子科技大学学报, 2007, 36(S3): 1493-1496

[18]刘宝辰. 高性能数据包捕获系统的研究与实现[D]. 上海: 上海交通大学, 2013

[19]Rizzo L, Lettieri G, Maffione V. Speeding up packet I/O in virtual machines[C] //Proc of Architectures for Networking and Communications Systems. Piscataway, NJ: IEEE, 2013: 47-58

[20]Rizzo L, Carbone M, Catalli G. Transparent acceleration of software packet forwarding using netmap[C] //Proc of IEEE INFOCOM 2012. Piscataway, NJ: IEEE, 2012: 2471-2479