dpdk

云网络架构 阿里云操作系统叫飞天，云网络平台称为洛神。作为飞天系统的核心组件，洛神平台支撑了超大规模租户、超大规模虚拟机的高性能云网络。 洛神平台由很多网络设备组成，在架构上主要可以分为两类：虚拟交换机AVS和各种网关设备。AVS负责ECS的虚拟网络接入，网关设备提供了丰富的网络功能和服务。 早期的洛神平台中，AVS和网关设备都是在x86物理机上基于kernel架构实现的，转发性能不高。随着DPDK技术的成熟，在洛神1.0架构中，AVS和网关设备基于DPDK进行了重构，使转发性能有显著提升，网关设备单物理机能提供100G+的转发能力。此外，我们也基于DPDK开发了一套高性能的通用转发平台NetFrame，包含了收发包、协议栈等通用的网络基础特性，屏蔽了DPDK版本和底层硬件差异，并做了大量的算法库优化和性能调优，使各网关产品能更专注于业 来源： oschina 链接： https://my.oschina.net/u/4392850/blog/4279689

锐文科技的xNIC系列智能网卡为自主研发，具有自主知识产权的国产智能网卡。锐文在对国产CPU飞腾的适配与支持上做了大量的工作，也得到了飞腾CPU厂家的大力支持。锐文测试过的飞腾CPU服务器厂商有飞腾自制的测试服务器，长城服务器和宝德服务器。 测试平台搭建使用第三方测试工具，测试平台搭建如图1所示 图1:基于飞腾CPU服务器的测试平台 飞腾CPU（ARM）服务器硬件配置： 服务器 192.168.xxx.xxx 操作系统 Kylin 4.0.2 或者centos 7.5.1804 CPU 国产飞腾FT2000+处理器(64个Core，2.0GHz) 系统内存 默认64GB DDR4 EEC 内存或者128G或者256G 双口万兆网卡 锐文xNIC-200/400 智能网卡 硬盘 250G SSD 在DPDK下，1-4队列性能测试数据（单口收发）测试带宽数据如图2所示。 图2: 基于飞腾CPU服务器的带宽测试报告（单口收发） 在DPDK下，1-4队列性能测试数据（双口收发）测试带宽数据如图3所示。 图3: 基于飞腾CPU服务器的带宽测试报告（双口收发) 如有对国产CPU及国产服务器网络适配及加速的需求， 欢迎联系sales@raymax.net 。 来源： oschina 链接： https://my.oschina.net/u/4390740/blog/4460915

虚拟机硬件配置： CPU: 4Core 内存: 4G 关机状态下新增两块网卡 修改虚拟机配置： 修改文件：DPDK-FWD.vmx hpet0.present = "true" numa.vcpu.maxPerVirtualNode = "1" ethernet1.virtualDev = "vmxnet3" #e1000e只支持网卡单队列，vmxnet3支持网卡对队列，DPDK_18_05_1也支持此网卡 ethernet1.wakeOnPcktRcv = "true" ethernet2.virtualDev = "vmxnet3" ethernet2.wakeOnPcktRcv = "true" Linux版本需求: Linux发行版本: CentOS Linux release 7.3.1611 (Core) Linux内核版本：3.10.0-514.el7.x86_64 设置hugepage及隔离CPU： 文件：/boot/grub2/grub.cfg 在linux16 /vmlinuz-3.10.0-514.el7.x86_64 root=/dev/mapper/cl-root ro crashkernel=auto rd.lvm.lv=cl/root rd.lvm.lv=cl/swap rhgb quiet LANG=en_US.UTF-8这一行后添加隔离命令：

目录 文章目录 目录 参考文献 OvS 架构 OvS-DPDK 架构 OvS-DPDK 在 VNF 中的应用 参考文献 https://networkbuilders.intel.com/docs/open-vswitch-enables-sdn-and-nfv-transformation-paper.pdf OvS 架构 openvswitch.ko ：在内核态负责 “快速路径” 的数据转发。转发靠流表来完成，每一个流表都包含很多的匹配项（match fields）和相应的动作（actions）。 match fields：定义了能够标识一个数据包的头部字段。 actions：定义了能够对这个数据包操作的动作，比如：添加或去除 VLAN 标签、修改数据包的某个头部字段，以及控制数据包从端口的进出等等。 ovs-vswitchd ：在用户态负责 “慢速路径” 的数据转发。 ofproto：OpenFlow 交换机实现。 netdev：和网络设备（包括物理的和虚拟的）交互的抽象接口层。 dpif：用户空间数据转发路径的实现。 OvS-DPDK 架构 上图中的深色模块就是引入 DPDK 的相关模块。 ofproto-dpif ：实现了 ofproto 模块 API，直接操作 dpif 层。 dpif-netdev ：用户空间中 “快速路径” 的实现，它实现了 dpif 模块 API

昨晚读了一篇Paper： https://penberg.org/parakernel-hotos19.pdf 大意是说，随着IO设备的进化，它们的存取/传输速率已经超过了CPU到内存的存储/传输速率，再也不再是慢速 外设 了，所以，对这些快速设备的管理和操作要发生改变才能适应，从这个意义上讲，几乎一成不变的Linux kernel在很多方面确实阻滞了性能的优化。 这可能是现如今人们纷纷转向DPDK/netmap或者XDP的本质原因了。怎么说呢？周末回上海前，发一篇感想。 在人们的印象中，一台标准的计算机包含三大件： CPU，即中央处理器。 内存，悬挂在类似叫做北桥的芯片上。 外设，慢速IO设备，悬挂在类似叫做南桥的芯片上。 这也是我们在《计算机组成原理》这门课中学到的。其实这就是现实中的计算机，就这样子，如果按照抽象的冯诺伊曼计算机来看，计算机是不包含外设的，它只有CPU和内存，强调存储和执行，是为 存储执行计算机。 有了现实中的计算机组成后，下一步就是设计操作系统来管理这些东西，事实上，几乎任何操作系统都可以按照这堆东西划分为不同的模块： 进程管理，管理CPU分时和调度。 内存管理，管理内存分配。 文件系统，管理文件组织。 网络协议栈，管理网络IO。 磁盘驱动，… … 其实一开始从名字上将除CPU，内存之外的物件叫做 外设 (某种意义上磁盘也是)，并且将其连接到相对慢速的桥片上

一、分析总结 系统是应用的运行环境，系统的瓶颈会导致应用的性能下降； 而应用的不合理设计，也会引发系统资源的瓶颈。 （1）CPU 性能分析 （2）内存性能分析 （3）磁盘和文件系统 I/O 性能分析 （4）网络性能分析 （5）应用程序瓶颈分析 1）strace，观察系统调用； 2）perf 和火焰图，分析热点函数； 3）动态追踪技术，来分析进程的执行状态。     二、优化总结 （1）CPU 优化 核心在于排除所有不必要的工作、充分利用 CPU 缓存并减少进程调度对性能的影响。 1）把进程绑定到一个或者多个 CPU 上，充分利用 CPU 缓存的本地性，并减少进程间的相互影响。 2）为中断处理程序开启多 CPU 负载均衡，以便在发生大量中断时，可以充分利用多 CPU 的优势分摊负载。 3）使用 Cgroups 等方法，为进程设置资源限制，避免个别进程消耗过多的 CPU。同时，为核心应用程序设置更高的优先级，减少低优先级任务的影响。 （2）内存优化 核心是解决内存使用的问题，如 可用内存不足、内存泄漏、Swap 过多、缺页异常过多以及缓存过多等。 1）除非有必要，Swap 应该禁止掉。这样就可以避免 Swap 的额外 I/O ，带来内存访问变慢的问题。 2）使用 Cgroups 等方法，为进程设置内存限制。这样就可以避免个别进程消耗过多内存，而影响了其他进程。对于核心应用，还应该降低

Redis 6.0在5.2号这个美好的日子里悄无声息的发布了，这次发布在IT圈犹如一颗惊雷一般，因为这是redis最大的一次改版，首次加入了 多线程 。 作者Antirez在RC1版本发布时在他的博客写下： the most “enterprise” Redis version to date // 最”企业级”的 the largest release of Redis ever as far as I can tell // 最大的 the one where the biggest amount of people participated // 参与人数最多的 这次改变，性能有个飞速的提升~ 先po出新版和旧版性能图 从上面可以看到 GET/SET 命令在 4 线程 IO 时性能相比单线程是几乎是翻倍了。另外，这些数据只是为了简单验证多线程 IO 是否真正带来性能优化，并没有针对严谨的延时控制和不同并发的场景进行压测。数据仅供验证参考而不能作为线上指标，且只是目前的 unstble分支的性能，不排除后续发布的正式版本的性能会更好。 Redis 6.0 之前的版本真的是单线程吗？ Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器。它的组成结构为4部分：多个套接字、IO多路复用程序、文件事件分派器、事件处理器。

在刚刚结束的“2020虚拟开发人员和测试论坛”上，来自瞻博网络的工程师Kiran KN和同事，介绍了在Tungsten Fabric数据平面上完成的一组性能改进（由Intel DDP技术提供支持），以下为论坛技术分享的精华： 作为DPDK应用的vRouter 在深入到DDP技术之前，首先介绍一下vRouter，它是什么，以及在整个Tungsten Fabric框架中的位置。 实际上，vRouter可以部署在常规X86服务器上，也可以在OpenStack或K8s的计算节点当中。vRouter是主要的数据平面组件，有两种部署的模式，分别是vRouter:kernel module，以及vRouter:DPDK模式。 在用DPDK改善性能之前，此用例将涉及DPDK应用和vRouter。vRouter的职责是数据平面，用于数据包转发和由vRouter代理在计算节点上编程的数据包转发，但实际上，整个配置是通过控制器上的XMPP提供的。我们使用XMPP通过vRouter agent与控制器通信，并且有一个专门的接口来对vRouter数据平面进行编程以转发软件包。 在DPDK中，vRouter是一个高性能、多核和多线程的应用程序，这里想强调一下，它是专用于多核的DPDK应用，我们需要寻找多核的正确用法。 我们可以从示例中看到，网卡具有与vRouter相同数量的队列，已为数据包或链接分配了核心。

https://wiki.centos.org/HowTos/Grub2#head-535f476a61e62f24bc150c73f7e0816f85345f46 1, 查看所有的entry [root@dpdk grub2]# awk -F \ ' ' $ 1 == " menuentry " {print i++ " : " $ 2 } ' /etc/grub2.cfg 0 : CentOS Linux ( 3.10 . 0 - 693.11 . 1 .el7.x86_64) 7 (Core) 1 : CentOS Linux ( 3.10 . 0 - 693.5 . 2 .el7.x86_64) 7 (Core) 2 : CentOS Linux ( 3.10 . 0 - 693.2 . 2 .el7.x86_64) 7 (Core) 3 : CentOS Linux ( 0 -rescue-37138ca794604b28bca5b6394f5cd3c2) 7 (Core) 2. 查看当前default的entry [root@dpdk grub2]# grub2- editenv list saved_entry =CentOS Linux ( 3.10 . 0 - 693.11 . 1 .el7.x86_64) 7 (Core) [root@dpdk grub2]#

【前言】 　　随着网络的高速发展，对网络的性能要求也越来越高，DPDK框架是目前的一种加速网络IO的解决方案之一，也是最为流行的一套方案。DPDK通过bypass内核协议栈与内核驱动，将驱动的工作从内核态移至用户态，并利用polling mode的线程工作模式加速网络I/O使得网络IO性能出现大幅度的增长。 　　在使用DPDK的时候，我们常常会说提到用DPDK来接管网卡以达到bypass内核驱动以及内核协议栈的操作，本篇文章将主要分析DPDK是如何实现的bypass内核驱动来实现所谓的“接管网卡”的功能。 注意： 本篇文章会涉及一些pci设备的内容，但是不会重点讲解pci设备，pci设备中的某些规则就是这么设计的，并没有具体原因。 本篇部分原理的讲解会以Q&A的方式拖出，因为DPDK bypass内核的这部分涉及的知识维度比较多，没有办法按照线性的思路讲解。 本人能力以及 水平有限，没办法保证没有疏漏 ，如有疏漏还请各路神仙进行指正，本篇内容都是本人个人理解，也就是 原创内容 。 由于内容过多，本篇文章会着重基础的将PCI以及igb_uio相关的知识与分析，以便于不光是从DPDK本身，而是全面的了解DPDK如果做到的bypass内核驱动，另外关于DPDK的代码部分实现将会放在后续文章中放出，另外还有DPDK的中断模式以及vfio也会在后续的文章中依次发出（先开个坑，立个flag）