简述

有幸全程参与了基于DPDK¹下一代高性能CloudXNS²服务器开发，从未知到慢慢熟悉，其中也走了些弯路也 踩过一些坑，一路走来有些感受与心得体会，在此进行梳理下，以对这一阶段做下些小的总结，也可以与同僚们进行交流学习。

背景

上一代XNS服务器是基于Linux内核进行开发，单机性能达到数百万级别QPS³，相对于BIND⁴来说已经高了很多,平常处理正常毫无压力，但在 受大量DDOS攻击时服务质量大大降低,虽然我们采用了远端清洗与近地防御的安措施，与受攻击时调度其他应急服务器来抗，但增加了服务器与 人工干预成本。为了更好的抗DDOS攻击与服务更多的用户，需求单机处理千万级别的替代方案呼之欲出。

目标设定

1. 单机处理能力千万级别。
2. 性能，性能，性能。(重要的事重复三遍)
3. 稳定压倒一切。(此话不是我说的)
4. 社区活跃，已有商用案例。

需求调研

　　按照上述的目标设定需求，要达到单机处理千万级别的只能采用轮询而非中断方式，在市面上的可实现技术方案有DPDK/pf_ring/netmap等. 其中DPDK为Intel公司主推，并有BAT之类的大型公司进行商用，而且也比较适合处理UDP类型协议。经过权衡之下，我们决定采用DPDK进行 下一代XNS的替代方案。

优点

• 性能高
• 用户态开发
• 死后易重启

缺点

• 无网络协议栈
• 开发困难，周期长
• 参考资料相对还匮乏

DPDK核心思想

组织结构

　　DPDK 的组成架构如下图所示,相关技术原理概述如下:

　　在最底部的内核态(Linux Kernel)DPDK 有两个模块:KNI 与 IGB_UIO。 其中,KNI 提供给用户一个使用 Linux 内核态的协议栈,以及传统的 Linux 网络工具(如ethtool, ifconfig)。IGB_UIO(igb_uio.ko 和 kni.ko. IGB_UIO)则借助了 UIO 技术,在初始化过程中将网卡硬件寄存器映射到用户态。

　　DPDK 的上层用户态由很多库组成,主要包括核心部件库(Core Libraries)、平台相关模块(Platform)、网卡轮询模式驱动模块(PMD-Natives& Virtual)、QoS 库、报文转发分类算法(Classify)等几大类,用户应用程序可以使用这些库进行二次开发.

用户态模式下的PMD Driver

• 去除了中断影响，减少了操作系统内核的开销，消除了IO吞吐瓶颈；
• 避免了内核态和用户态的报文拷贝；用户态下软件崩溃，不会影响系统的稳定性；
• Intel提供的PMD驱动，充分利用指令和网卡的性能；

HugePage和m_buf管理

• 提供2M和1G的巨页，减少了TLB Miss，TLB Miss严重影响报文转发性能；
• 高效的m_buf管理，能够灵活的组织报文，包括多buffer接收，分片/重组，都能够轻松应对；

Ring

• 无锁化的消息队列，实际验证，性能充足；

82599 SR-IOV NIC

• 实现虚拟化下高速吞吐；

Vector Instance /向量指令

• 明显的降低内存等待开销，提升CPU的流水线效率。

项目规划

　　为了使DPDK更好的在我司使用与发扬光大，我大致规划了初期、中期与长期三步走策略实现目标。

初期目标

实现一个最简单的DNS demo.

需求：

• 网络可达。
• Dig示例域名可正确响应。
  

中期目标

实现一个高性能高并发的DNS服务

需求:

• 单机性能提高5倍以上。
• 形成完整DNS产品服务(XNS、public DNS)。
• 平台与服务逻辑分离。

长期目标

实现高性能高并发的网络加速平台与应用体系

需求：

• 平台具有可移植性。
• 可透明承载多种业务(UDP/TCP)服务。
• 平台与服务物理分离。
• 可承载其他高级语言与虚拟化。
  

开发初试

　　为了验证其的可行性，我们对它进行了最小原型开发，实现了一个最简单的DNS服务程序，使其网络可达，dig能正确响应。

　　由于刚开始对DPDK一无所知，为了网络可达首先要面对的问题是服务器IP在哪儿配置的问题(这也许是一些初学者会面对的幼稚问题)，还好已有前辈 在QQ大致网上了解一些原理与其源码示例，采用其源码examples目录下l3fwd为基础进行最小原型开发demo。

　　为了使网络可达，我们做了如下开发：

1. 先在simpleDNS服务端中临时配置一个服务IP进行过滤.
2. 在DNS客户端通过手工配置ARP表使得客户端ping/dig操作的请求包可达服务端，
3. 在simpleDNS服务端做解析请求包，如果是DNS请求构造响应包，其他类型如ARP/ICMP请求则通过KNI入接口ingress()重入Linux内核由 其来处理后再通过KNI的egress()接口响应给客户端。

经过上述编码调试后，最简单的原型验证通过了，为下面的全面开发提供了参考依据。

架构设计

　　由于此项目是在基于DPDK进行二次开发，我一般对开源项目的使用原则是：

应使开源项目融入到项目工程中，而不是项目工程融入到开源项目中

因此我对它们进行分3层设计与实现：

• 内核层 主要为Linux内核本身与插入igb_uio.ko与rte_kni.ko.
• 平台层
  • 分为DPDK原生库与fastNP扩展库，分别在不同目录进行隔离。
  • DPDK源码树本身，没有任务的修改，是为了更好的升级、开发与维护。
  • 对DPDK某些接口进行二次封装与业务所需的公共库，一般各种业务应用调用。
• 业务层 业务应用的各种实现，可直接调用fastNP平台层与DPDK原生层的API。

全面开发

源码组织管理

为了所有源码可以一键编译、一键打包，编写一套符合所需的Makefile进行源码管理。

fastNP扩展库开发

　　扩展库源码不在DPDK源码目录中，需要很好的理解DPDK下面mk/目录下的各种Makefile原理， 使其的各种编译选项与属性能够传递到扩展库中。

扩展库主要实现如下部分功能：

1. 基础数据结构库。 如：高效双链表、用户态RCU接口等。
2. 轻量级用户态协议栈 目前主要实现轻量级简易型UDP协议栈，以实现二三层转发为主。
3. HOOK挂载与处理机制 仿造了Linux netfilter框架实现5个点钩子挂载与处理。
4. 高性能日志库 参考了目录主流高性能日志与线程安全，实现了一个数百万行打印的高性能日志系统。 等等…

业务层开发

第一个应用主要是把原有内核版本的KANS源码移植到用户态的SANSD中。

控制查看命令开发

为了方便对平台与业务层的查看与控制，我们基于Libcmdline库开发了sansctl命令，可支持命令补全等。

发包工具开发

为了能进行千万级别的高性能测试，基于pktgen-dpdk进行开发使其可以构造DNS请求与控制发送速率功能的spktgen，主界面如下图：

抓包工具开发

由于现有tcpdump不能抓取DPDK接管的网卡数据，也在其基础上开发可在DPDK下抓包的spktdump，以便调试与定位。

其他开发

从略。

踩过的坑

架构模式选择

　　DPDK提供了两种模式可供选择：Run-to-completion与pipeline模式。在官网文档与DPDK开发者大会中都提到了这两种模式， 但都没说哪种模式更好，要看场景而定。我们在最初设计时，不仅考虑DNS服务器还考虑以后负载均衡设备的使用，选择了 可支持这两种模式。

在测试性能时，发现某种情况下不同模式都有优缺点，经常在这两种模式中来回切换测试，造成了一些干扰与浪费了点时间。

编译选项一致

在测试性能时一定使用-O3选项并且编译选项需与DPDK本身app编译选项一致。否则会影响很大的性能。

DPDK本身app编译选项可以在编译目录下的.XXX.o.cmd文件查看到。

变量percore化

　　所用的全局变量尽量percore化，这样可以防止cache miss。例如统计部分要用percore化，计算或显示时再把他们加到一起， 这个也影响不小的性能。

代码逻辑简化

　　由于业务层代码是从内核版本中移植过来的，老早功能就通过了，但性能一直上不来，后来经过代码review发现很多影响性能点， 又重新优化或精简了下代码逻辑，去掉了不少冗余代码。

RCU锁占用性能

扩大RCU临界区

域名压缩占用性能

应答区中的域名不压缩。

master lcore不要作为收发处理

如果master lcore作为收发处理，如有数据下方或打印统计时将严重丢包，大大影响收发性能。

有待完善

DPDK

缺少配置文件

　　现在DPDK代码与核数越来越多,依然使用命令行参数的方式进行启动，可配置与阅读性比较差，应该有自己的配置文件进行解析即可。 尤其是网卡、队列、逻辑核配置序列太难配置了，尤其是使用核数比较多的情况。

例如：(0,0,2),(0,1,4),(0,2,6),(0,3,8),(0,4,10),(0,5,12),(0,6,14),(0,7,16),(0,8,18),(0,9,20),(0,10,22),(0,11,24),(0,12,26),(0,13,28)

不知道各位同学知不道有什么国际规范的缩写方式配置,请麻烦告知一下，OK？

pktgen-dpdk驱动bug

　　当使用pktgen-dpdk进行测试时，频繁的启停可能会使万兆光纤网卡处于DOWN状态，重启命令或reboot系统都不管用，必须对服务器 进行冷重启才行，这对测试比较浪费时间或者远程调试操作堪忧。

examples下编码质量参差不齐

　　DPDK库本身的编码质量还是比较规范统一的，而其examples下的示例代码编码质量参差不齐。

fastNP本身

• BOND与多网卡有待支持。
• 邻居发现与路由功能有待支持。
• TCP协议栈有待支持。
• 虚拟化功能有待支持。
• 更高级语言功能有待支持。
• Libc与系统调用劫持功能有待支持。

总结

经过这一段时间的开发，使得我对DPDK、内存、CPU、用户态网卡驱动有了更深的了解，使得性能达到了万兆网卡线速水平，单机抗攻击能力为1300万QPS，收发平衡能力为1000万QPS的预期目标， 总之DPDK框架代码写得还是挺不错的，值得仔细研究，现在我只是对它怎么使用与部分源码有了一定的认识，很多精华部分有待深入剖析。

Footnotes