DPDK与SR-IOV两者目前主要用于提高IDC(数据中心)中的网络数据包的加速。但是在NFV(网络功能虚拟化)场景下DPDK与SR-IOV各自的使用场景是怎样的?以及各自的优缺点?
大家晚上好。那我们开始吧。主要还是抛装引玉,互相学习交流。今天和大家分享下面一些内容: 1.关于openstack中VNF网络性能的一些思考和思路 2.相关的开源项目 3.OVS 2.4 DPDK with IVSHMEM/vHost-user(w/DPDK) 和vHost (w/oDPDK)性能测试数据 4.后续可以一起来做的一些工作 第一部分 关于openstack中VNF网络性能的一些思考和思路 先来介绍一下背景,目前openstack社区版本的一些网络服务如routing,fip,snat,fw,v
本文主要介绍了我在阅读《深入浅出DPDK》,《DPDK应用基础》这两本书中所划下的知识点
在上一期,我们留下了一个问题:如何通过让专业的人做专业的事,提升虚拟化网元vSwitch的性能?
DPDK最初动机很简单,网络处理器的软件解决方案,证明IA多核处理器能够支撑高性能数据包处理。 什么是DPDK?对于用户来说,它可能是一个出色的包数据处理性能加速软件库;对于开发者来说,它可能是一个实践包处理新想法的创新工场;对于性能调优者来说,它可能又是一个绝佳的成果分享平台。DPDK在主流Linux包含,比如Debian, Fedora,Redhat, Ubuntu, FreeBSD。 DPDK代码在www.dpdk.org上自由提交,软件发布时间是1年4次,分别是2017年2月、5月8月和11月。本质
传统数据中心中硬件服务器上运行linux,linux用硬件网卡收发包,硬件网卡有broadcom的有mellanox的有intel的等各式各样的,硬件网卡连接到硬件交换机上,硬件交换机有H3C的有cisco的,交换机进行包转发实现服务器之间互通。在云计算环境下,对计算资源进行了切分,服务器上运行的是一个个虚拟机,虚拟机也要有网卡实现互连互通,但虚拟机的网卡不是物理的,是虚拟的网卡,虚拟的网卡连接到虚拟的交换机上,虚拟的交换机对同一个服务器上的虚拟机之间流量进行转发,如果虚拟交换机再连接到服务器的硬件网卡,那么虚拟机就可以和服务器外面通信了。
云计算数据平面发生危机,一般是因为计算机CPU性能的线性增长,难以跟上网络带宽的指数提升,及其带来的“数据中心税”的增加。
原文链接:https://blog.csdn.net/dog250/article/details/103301816
2020年12月19日,2020 TECHO PARK 腾讯开发者大会在北京顺利召开。网络专场以“全球互联、高速上云”为主题,腾讯云网络产品专家工程师周显平带来了《腾讯云网络VPC大规模演进实践》的演讲,子标题《百万级虚拟网络、千万级云主机规模下云网络的挑战与思考》,重点讨论云网络在支持超大规模节点和流量上在可扩展,高可用,高性能, 可运维上面临的挑战, 以及腾讯云在这方面的实践。本文主要从腾讯云网络VPC的产品架构、云网络VPC的挑战、以及腾讯云网络的解决方案、重点讲解SDN控制器、虚拟交换机、云服务网关的演进路线。
随着云计算产业的异军突起,网络技术的不断创新,越来越多的网络设备基础架构逐步向基于通用处理器平台的架构方向融合,从传统的物理网络到虚拟网络,从扁平化的网络结构到基于 SDN 分层的网络结构,无不体现出这种创新与融合。
概述 数据平面开发套件(DPDK)可提供高性能的数据包处理库和用户空间驱动程序。自Open vSwitch(OVS)2.4版 (http://openvswitch.org/releases/NEWS-2.4.0)起,我们将可在OVS中使用DPDK优化的vHost路径。OVS自2.2版起开始提供DPDK支持。 将DPDK与OVS结合使用可为我们带来诸多性能优势。与其他基于DPDK的应用相同,我们可以在OVS中看到网络包吞吐量显著提升,延迟显著降低。 此外,DPDK包处理库还对OVS内的多个性能热点区域进行了
Virtio作为一种半虚拟化的解决方案,其性能一直不如设备的pass-through,即将物理设备(通常是网卡的VF)直接分配给虚拟机,其优点在于数据平面是在虚拟机与硬件之间直通的,几乎不需要主机的干预。而virtio的发展,虽然带来了性能的提升,可终究无法达到pass-through的I/O性能,始终需要主机(主要是软件交换机)的干预。vDPA(vhost Data Path Acceleration)即是让virtio数据平面不需主机干预的解决方案。该框架由Redhat提出,实现了virtio数据平面的硬件卸载。控制平面仍然采用原来的控制平面协议,当控制信息被传递到硬件中,硬件完成数据平面的配置之后,数据通信过程由硬件设备(智能网卡)完成,虚拟机与网卡之间直通。中断信息也由网卡直接发送至虚拟机不需要主机的干预。这种方式,控制面比较复杂,硬件难以实现。
在DPDK使用环境中,物理网卡收到的报文不再进入内核协议栈,而是直接到达DPDK应用。但是在有些场景中,用户希望把报文(如控制报文)再次发送至内核协议栈进行处理。报文从用户空间再次进入内核的过程在DPDK中称为exception path。
数据平面开发套件(DPDK [1] ,Data Plane Development Kit)是由6WIND,Intel等多家公司开发,主要基于Linux系统运行,用于快速数据包处理的函数库与驱动集合,可以极大提高数据处理性能和吞吐量,提高数据平面应用程序的工作效率。
Linux处理Packets主逻辑 系统接受数据包的过程 当网卡收到第一个包时候,通过DMA把这个包发送给接受队列(rx) 系统通过中断的方式通知新数据包的到来,同时也需要把数据包传递给内核的buffer(每个包一个buffer,sk_buff struct).一个数据包到来会触发多次的中断,内核处理完毕后,数据包再次传输到用户态空间 瓶颈分析 内核在处理很多包的时候,会消耗非常多的资源,同时也会触发很多次中断,这会严重影响系统处理数据包的性能 内核的sk_buff的设计是为了内核协议栈兼容多个协议。因此所
◆DPDK是什么 Intel® DPDK全称Intel Data Plane Development Kit,是intel提供的数据平面开发工具集,为Intel architecture(IA)处理器架构下用户空间高效的数据包处理提供库函数和驱动的支持,它不同于Linux系统以通用性设计为目的,而是专注于网络应用中数据包的高性能处理。具体体现在DPDK应用程序是运行在用户空间上利用自身提供的数据平面库来收发数据包,绕过了Linux内核协议栈对数据包处理过程。 ◆DPDK技术介绍 一、主要特点 1、UIO(L
我们知道,各类智能网卡在服务器集群中的大规模部署,可以进一步降低数据中心建设和运营成本,更好地将服务器资源货币化。但仅从网卡层面来看,这个方案还存在不少优化空间。
传统的Linux内核网络协议栈由于更加注重通用性,其网络处理存在着固有的性能瓶颈,随着10G、25G、40G、100G甚至更高速率的网卡出现,这种性能瓶颈变得更加突出,传统内核网络协议栈已经难以满足高性能网络处理的要求。
除了在前面提到的,对于计数器等多个核可能并发访问的数据结构,为每个核分配一个,还需要引入新的机制——大页机制。
相对传统的基于内核的网络数据处理,dpdk 对从内核层到用户层的网络数据流程进行了重大突破,我们先看看传统的数据流程和 dpdk 中的网络流程有什么不同。
本章分为两节,第一节介绍数据平面开发套件DPDK(Data Plane Development Kit)的基础知识,第二节介绍DPDK盒子的使用方法。 一、DPDK简介 本节首先介绍DPDK出现的行业背景,然后介绍DPDK概述、DPDK关键技术、DPDK开源代码,最后介绍DPDK Lib库。 1.1 DPDK背景 在过去10年里,以太网接口技术也经历了飞速发展。从早期主流的10Mbit/s与100Mbit/s,发展到千兆网(1Gbit/s)。到如今,万兆(10Gbit/s)网卡技术成为数据中心服务器的主流
近些年来,云计算蓬勃发展,上云成为现在软件开发落地的首选。但随着企业业务的不断增长和扩大,传统云计算的劣势也暴露出来:单体硬件性能不够,只能堆集群;租户隔离不够彻底,时有新闻爆出问题。因此,物理机服务器又再一次的被提上了台面。
首先,DPDK和内核网络协议栈不是对等的概念。 DPDK只是单纯的从驱动拿数据,然后组织成数据块给人用,跑在用户态。功能相当于linux的设备无关接口层,处于socket之下,驱动之上。只不过linux协议栈的这部分在核心态。 你说的包处理器,很多时候是不用linux内核协议栈的,而是用专用包处理程序,类似于DPDK加上层应用处理。通常会有些硬件加速器,包处理效率更高些。缺点是一旦用不上某些功能,那些加速器就白费了。而纯软件处理就非常灵活,不过代价就是功耗和性能。 纯DPDK性能非常高,intel自己给出的数据是,处理一个包80时钟周期。一个3.6Ghz的单核双线程至强,64字节小包,纯转发能力超过90Mpps,也就是每秒9千万包。 不知你有没有看出来,80周期是一个非常惊人的数字?正常情况下,处理器访问一下ddr3内存都需要200个周期,而包处理程序所需要操作的数据,是从pcie设备送到ddr内存的,然后再由处理器读出来,也就是说,通常至少需要200周期。为啥现在80周期就能完成所有处理?我查了下文档,发现原因是使用了stashing或者叫direct cache access技术,对于PCIe网卡发过来的包,会存在一个特殊字段。x86的pcie控制器看到这个字段后,会把包头自动塞到处理器的缓存,无序处理器来干预。由于包头肯定是会被读取的,这样相当于提前预测,访问的时间大大缩短。 如果加上linux socket协议栈,比如跑个纯http包反弹,那么根据我的测量,会掉到3000-4000周期处理一个包,单核双线程在2.4Mpps,每秒两百四十万包,性能差40倍。 性能高在哪?关键一点,DPDK并没有做socket层的协议处理,当然快。其他的,主要是使用轮询替代中断,还有避免核心态到用户态拷贝,并绑定核,避免线程切换开销,还有避免进入系统调用的开销,使用巨页等。 还有很关键的一点,当线程数大于12的时候,使用linux协议栈会遇到互斥的瓶颈,用性能工具看的话,你会发现大部分的时间消耗在spin_lock上。解决方法之一是如github上面的fastsocket,改写内核协议栈,使包始终在一个核上处理,避免竞争等。缺点是需要经常自己改协议栈,且应用程序兼容性不够。 另外一个方法是使用虚拟机,每个特征流只在一个核处理,并用虚拟机隔绝竞争,底层用dpdk做转发,上层用虚拟机做包处理,这样保证了原生的linux协议栈被调用,做到完全兼容应用程序。不过这种方法好像还没有人做成开源的,最近似的是dpdk+虚拟交换机ovs的一个项目。 如果你只想要dpdk的高性能加tcp/ip/udp的处理,不考虑兼容性,那么还可以去买商业代码,我看了下供应商的网站介绍,纯转发性能大概在500-1000周期左右一个包。
在前几期,我们发现,正如生产关系与生产力之间的相互作用那样,低效的虚拟化数据平面工作机制,会严重约束云计算生产力的发展。
以前基于DPDK做NFV,转发程序跑在虚拟机中,先把硬件网卡passthrough给虚拟机,然后在虚拟机中把网卡绑定内核模块igb_uio,问题是igb_uio的代码没有upstream,依赖于内核版本,提前编译好的内核模块换个版本就不能运行,就想着用vfio-pci,这家伙早早upsteam,一般linux发行版本内核都自带,且不省事,理想是丰满的,现实是骨感的。
所谓的“数据中心税”,指的是数据中心计算、存储、网络等基础资源虚拟化后带来的开销。
以前提到过vdpa,只有mellanox connectx-5网卡,不支持vdpa,公司最近来了mellanox DPU,也就是bluefield-2,自带connectx-6网卡,硬件支持vdpa,再分析一下看怎么个搞法。
底层网络 Underlay Network 顾名思义是指网络设备基础设施,如交换机,路由器, DWDM 使用网络介质将其链接成的物理网络拓扑,负责网络之间的数据包传输。
从我们用户的使用就可以感受到网速一直在提升,而网络技术的发展也从1GE/10GE/25GE/40GE/100GE的演变,从中可以得出单机的网络IO能力必须跟上时代的发展。
惠伟:virtio+ovs转发原理和性能分析zhuanlan.zhihu.com
原文链接:https://www.cnblogs.com/qcloud1001/p/9585724.html
NIC 在接收到数据包之后,首先需要将数据同步到内核中,这中间的桥梁是 rx ring buffer。它是由 NIC 和驱动程序共享的一片区域,事实上,rx ring buffer 存储的并不是实际的 packet 数据,而是一个描述符,这个描述符指向了它真正的存储地址,具体流程如下:
文章介绍了dperf是一款基于intel DPDK开发的一款高性能的开源网络压力测试仪,目前已经被收录至DPDK官方生态项目。
dperf 是一款基于 DPDK 的 100Gbps 网络性能和负载测试软件,能够每秒建立千万级的 HTTP 连接、亿级别的并发请求和数百 Gbps 的吞吐量。
惠伟:openstack网络设计-(一)试探zhuanlan.zhihu.com
网络offload主要是指将原本在内核网络协议栈中进行的IP分片、TCP分段、重组、checksum校验等操作,转移到网卡硬件中进行,CPU的发包路径更短,消耗更低,提高处理性能。
作者Liam,海外老码农,对应用密码学、CPU微架构、高速网络通信等领域都有所涉猎。
dperf 是百度开源的一款基于 DPDK 的 100Gbps 网络性能和负载测试软件,能够每秒建立千万级的 HTTP 连接、亿级别的并发请求和数百 Gbps 的吞吐量。
在上期《云计算与虚拟化硬核技术内幕 (14) —— 不忘初心,删繁就简》中,我们介绍了Linux网桥,也遗留了一些问题:
目前,有大量的网络应用在处理数据包的时候只需要处理数据包头,而不会操作数据负载部分,例如防火墙、TCP/IP协议栈和软件交换机。对这类网络应用而言, 包头处理产生的开销(称为“per-packet overhead”)占了整体开销的大部分。因此,如何减少包头处理开销是优化这类应用性能的关键。
本章节介绍的是一款面向四层网关(如四层负载均衡,L4-LB)的高性能的压测工具dperf。该工具目前已经在github上开源,是一款高性能的压测工具:
在使用vpp老版本copy报文的时候,经常遇到mbuf泄露的问题,根本原因是在vlib_buffer分段场景下没有将rte_mbuf进行串联,导致dpdk发包时造成了泄漏。最新的版本已经彻底解决了此问题。下面来分析一下:
在传统的应用场景中,服务器资源过剩情况普遍,为了充分利用服务器资源,产生了虚拟化技术。虚拟化技术以牺牲部分效率为代价提升了资源的使用率,将原来需要硬件完成的工作,通过软件模拟的方式,满足多个云租户的需要。随着5G、8K等新型业务的不断涌现,应用系统对性能提出了更高的要求,云服务也出现了满足不同QoS要求的分化,有(物理机、裸金属)等不同产品形态。各个功能模块的衔接配合,各租户之间的信息交互都需要高效的网络系统来实现。
F-Stack KNI配置注意事项 KNI介绍 KNI(Kernel NIC Interface)内核网卡接口,是DPDK中用于与内核通信的模块,在主要的业务流程中可能并不需要,但在部分场景下,如服务器所有网卡都被F-Stack接管用于业务(或服务器本身只有单网卡),其他如SSH登录管理等数据等就必须开启KNI来与内核进行数据交互。 KNI配置 因为开启KNI将对收到所有的数据包按转发策略进行检查,会对性能造成一定的影响,所以在F-Stack中默认配置关闭了KNI选项,如有需要可以在控制文件config
目前F-Stack的配置文件中包含有以下8个部分,下面将分别进行简单的介绍: [dpdk]、[pcap]、[portN]、[vdevN]、[bondN]、[kni]、[freebsd.boot]、[freebsd.sysctl] [DPDK] 设置运行DPDK的相关参数,如果是DPDK也有的参数,则含义和使用方法同DPDK参数。 lcore_mask 16进制位掩码,用于设置进程运行在哪些CPU核心上。如fc表示使用CPU第2-7个核,不使用第0和1核。 建议优先使用物理核,数据尽量不要跨NUMA节点交互,
领取专属 10元无门槛券
手把手带您无忧上云