在 vhost_net 的方案中,由于 vhost_net 实现在内核中,guest 与 vhost_net 的通信,相较于原生的 virtio 方式性能上有了一定程度的提升,从 guest 到 kvm.ko 的交互只有一次用户态的切换以及数据拷贝。这个方案对于不同 host 之间的通信,或者 guest 到 host nic 之间的通信是比较好的,但是对于某些用户态进程间的通信,比如数据面的通信方案,openvswitch 和与之类似的 SDN 的解决方案,guest 需要和 host 用户态的 vswitch 进行数据交换,如果采用 vhost_net 的方案,guest 和 host 之间又存在多次的上下文切换和数据拷贝,为了避免这种情况,业界就想出将 vhost_net从内核态移到用户态。这就是 vhost-user 的实现。
DPDK最初动机很简单,网络处理器的软件解决方案,证明IA多核处理器能够支撑高性能数据包处理。 什么是DPDK?对于用户来说,它可能是一个出色的包数据处理性能加速软件库;对于开发者来说,它可能是一个实践包处理新想法的创新工场;对于性能调优者来说,它可能又是一个绝佳的成果分享平台。DPDK在主流Linux包含,比如Debian, Fedora,Redhat, Ubuntu, FreeBSD。 DPDK代码在www.dpdk.org上自由提交,软件发布时间是1年4次,分别是2017年2月、5月8月和11月。本质
PMD是Poll Mode Driver的缩写,即基于用户态的轮询机制的驱动。本文将介绍PMD的基本原理。
本章分为两节,第一节介绍数据平面开发套件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在专注数据面报文处理的同时,一直紧跟着网络发展的脉搏以开放的姿态融合不断涌现的各种新的网络设备。从最初的普通网卡,到集成虚拟化和交换功能的高级网卡,再到各种网络SoC(片上系统)设备,到现在最热的基于FPGA的Smart NIC,DPDK一直走在软件定义的网络技术发展的最前沿。近年来,数据中心异构化的趋势出现,基于云的数据中心如何使用加速器来进行存储,网络以及人工智能的加速,成为炙手可热的话题,在刚结束的APNET’18研讨会上,华为与腾讯都分享了技术方向与实践演进过程,基于Linux Foundation的开源项目,对这种架构的支持,在软件的持续性与高质量保证上至关重要。
virtio-user 是 DPDK 针对特定场景提出的一种解决方案,它主要有两种场景的用途,一种是用于 DPDK 应用容器对 virtio 的支持,这是 DPDK v16.07 开始支持的;另一种是用于和内核通信,这是 DPDK v17.02 推出的。 virtio_user 用于容器网络 我们知道,对于虚拟机,有 virtio 这套半虚拟化的标准协议来指导虚拟机和宿主机之间的通信,但对于容器的环境,直接沿用 virtio 是不行的,原因是虚拟机是通过 Qemu 来模拟的,Qemu 会将它虚拟出的整个 K
一、Dpdk简介 Dpdk是X86平台报文快速处理的库和驱动的集合,不是网络协议栈,不提供二层,三层转发功能,不具备防火墙ACL功能,但通过DPDK可以轻松的开发出上述功能。优势在于通过Dpdk,可以
Intel DPDK,全称为Intel Data Plane Development Kit,是一个为Intel架构处理器设计的强大的数据包处理工具集。不同于传统的Linux系统设计,DPDK专注于网络应用中的高性能数据包处理。
前面章节我们简单的介绍了dperf的相关基础概念,本章节我们将要讲dperf 在实际部署过程中遇到不支持的光模块导致系统启动失败的问题的解决方法。
云计算数据平面发生危机,一般是因为计算机CPU性能的线性增长,难以跟上网络带宽的指数提升,及其带来的“数据中心税”的增加。
◆DPDK是什么 Intel® DPDK全称Intel Data Plane Development Kit,是intel提供的数据平面开发工具集,为Intel architecture(IA)处理器架构下用户空间高效的数据包处理提供库函数和驱动的支持,它不同于Linux系统以通用性设计为目的,而是专注于网络应用中数据包的高性能处理。具体体现在DPDK应用程序是运行在用户空间上利用自身提供的数据平面库来收发数据包,绕过了Linux内核协议栈对数据包处理过程。 ◆DPDK技术介绍 一、主要特点 1、UIO(L
Linux处理Packets主逻辑 系统接受数据包的过程 当网卡收到第一个包时候,通过DMA把这个包发送给接受队列(rx) 系统通过中断的方式通知新数据包的到来,同时也需要把数据包传递给内核的buffer(每个包一个buffer,sk_buff struct).一个数据包到来会触发多次的中断,内核处理完毕后,数据包再次传输到用户态空间 瓶颈分析 内核在处理很多包的时候,会消耗非常多的资源,同时也会触发很多次中断,这会严重影响系统处理数据包的性能 内核的sk_buff的设计是为了内核协议栈兼容多个协议。因此所
本文主要介绍了我在阅读《深入浅出DPDK》,《DPDK应用基础》这两本书中所划下的知识点
概述 数据平面开发套件(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一直在云计算与虚拟化中扮演着重要的角色。而virtio网络接口,作为virtio标准支持下最复杂的接口之一,在虚拟机/容器网络加速、混合云加速中一直扮演着重要角色。本文将在读者对virtio标准与虚拟化有一定了解的前提下,介绍virtio网络架构从创造之初到如今的演化之路。
场景 测试qinq 发包,但是tcpreplay是没法带vlan tag的。所以需要用pktgen发送qinq包。 问题 qinq双层vlan tag,有些包大小超过了1518字节,pktgen不支持。 解决方案 修改 dpdk-2.1.0/x86_64-native-linuxapp-gcc/include/rte_ether.h: #define ETHER_MAX_LEN 1522 重新编译DPDK,Pktgen,重新加载DPDK驱动 资料 DPDK2.1.0: http://dpdk.org/bro
相对传统的基于内核的网络数据处理,dpdk 对从内核层到用户层的网络数据流程进行了重大突破,我们先看看传统的数据流程和 dpdk 中的网络流程有什么不同。
本文列举四个比较经典的 Linux 收包引擎,如果还有其他你觉得ok的可以留言。这四个分别是:
本文主要通过介绍简单的Intel DPDK基础来帮助广大朋友入门DPDK和自我总结交流,如下提供在Linux PC 基础上安装Intel DPDK,仅供大家学习参考
传统的Linux内核网络协议栈由于更加注重通用性,其网络处理存在着固有的性能瓶颈,随着10G、25G、40G、100G甚至更高速率的网卡出现,这种性能瓶颈变得更加突出,传统内核网络协议栈已经难以满足高性能网络处理的要求。
" 如果你怀念 SDN 领域丰富的网络能力却在云原生领域苦苦追寻而不得,那么 Kube-OVN 将是你的最佳选择。本系列我们将逐个介绍Kube-OVN高级功能的工作原理及使用路径,帮你尽快征服容器网络难题!"
前段时间同事在测试Mellanox ConnectX-6网卡在vpp和dpdk l2fwd or l3wfd性能对比,发现新版本中vpp性能下降明显。当时正巧我在vpp-dev邮箱列表中看到有关此网卡性能下降的讨论。
Virtio作为一种半虚拟化的解决方案,其性能一直不如设备的pass-through,即将物理设备(通常是网卡的VF)直接分配给虚拟机,其优点在于数据平面是在虚拟机与硬件之间直通的,几乎不需要主机的干预。而virtio的发展,虽然带来了性能的提升,可终究无法达到pass-through的I/O性能,始终需要主机(主要是软件交换机)的干预。vDPA(vhost Data Path Acceleration)即是让virtio数据平面不需主机干预的解决方案。该框架由Redhat提出,实现了virtio数据平面的硬件卸载。控制平面仍然采用原来的控制平面协议,当控制信息被传递到硬件中,硬件完成数据平面的配置之后,数据通信过程由硬件设备(智能网卡)完成,虚拟机与网卡之间直通。中断信息也由网卡直接发送至虚拟机不需要主机的干预。这种方式,控制面比较复杂,硬件难以实现。
从我们用户的使用就可以感受到网速一直在提升,而网络技术的发展也从1GE/10GE/25GE/40GE/100GE的演变,从中可以得出单机的网络IO能力必须跟上时代的发展。
以前提到过vdpa,只有mellanox connectx-5网卡,不支持vdpa,公司最近来了mellanox DPU,也就是bluefield-2,自带connectx-6网卡,硬件支持vdpa,再分析一下看怎么个搞法。
原文链接:https://www.cnblogs.com/qcloud1001/p/9585724.html
惠伟:virtio+ovs转发原理和性能分析zhuanlan.zhihu.com
Q1:请问再视频领域,媒体服务器,使用F-Stack是否合适? A1:F-Stack在纯推流的模式上是支持且合适的,如果有转码服务等计算密集型服务,需要等我们支持中断+轮询模式之后更合适。 Q2:请问,安装F-Stack对网卡有没有要求? A2:F-Stack使用了DPDK作为网络模块,网卡要求与DPDK相同,具体支持网卡列表请参考《list of supported NICs》(http://dpdk.org/doc/nics)。 Q3:基于 F-Stack 的分布式文件系统是怎么样的,效率提高的明显
首先,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周期左右一个包。
在vpp使用命令行 show hardware-interfaces 查询网卡相关功能(offload、rx tx队列等)使能情况,发现支持ipv4-sctp但是未开启。具体如下:
随着云计算产业的异军突起,网络技术的不断创新,越来越多的网络设备基础架构逐步向基于通用处理器平台的架构方向融合,从传统的物理网络到虚拟网络,从扁平化的网络结构到基于 SDN 分层的网络结构,无不体现出这种创新与融合。
本章节介绍的是一款面向四层网关(如四层负载均衡,L4-LB)的高性能的压测工具dperf。该工具目前已经在github上开源,是一款高性能的压测工具:
传统数据中心中硬件服务器上运行linux,linux用硬件网卡收发包,硬件网卡有broadcom的有mellanox的有intel的等各式各样的,硬件网卡连接到硬件交换机上,硬件交换机有H3C的有cisco的,交换机进行包转发实现服务器之间互通。在云计算环境下,对计算资源进行了切分,服务器上运行的是一个个虚拟机,虚拟机也要有网卡实现互连互通,但虚拟机的网卡不是物理的,是虚拟的网卡,虚拟的网卡连接到虚拟的交换机上,虚拟的交换机对同一个服务器上的虚拟机之间流量进行转发,如果虚拟交换机再连接到服务器的硬件网卡,那么虚拟机就可以和服务器外面通信了。
数据平面开发套件(DPDK [1] ,Data Plane Development Kit)是由6WIND,Intel等多家公司开发,主要基于Linux系统运行,用于快速数据包处理的函数库与驱动集合,可以极大提高数据处理性能和吞吐量,提高数据平面应用程序的工作效率。
文章介绍了dperf是一款基于intel DPDK开发的一款高性能的开源网络压力测试仪,目前已经被收录至DPDK官方生态项目。
做过DPDK/SPDK开发或者用kvm做过pci passthrough的一定知道以下的配置:
关系图谱(点击看大图): 部分名词: 名词 全写 解释 备注 DPDK Data Plane Development Kit 数据平面开发套件或叫数据平面开发工具集 Intel开源的快速数据包处
上次的陈老师在对PolarDB 的分享中,提到一个新名词,bypass,通过bypass 来提高整体的云原生数据库的性能。这在传统的数据库的技术中我未曾听过,当然上次的东西,最近比较懒,没有整理,后续我会把相关的录音转换成文字,把PolarDB到底打败了谁,之快问快答的东西整理出来。
在DPDK使用meson管理后相对之前的编译方法已经变的简单和清晰了,为此我们简单介绍一下如何进行給21.11.1版本的交叉编译,如果对如何编译DPDK没有概念请参考:
一、 引入 随着TIG阿基米德平台全面应用。组成京东容器生态技术栈的分布式域名解析服务ContainerDNS(go版https://github.com/tiglabs/containerdns )全量生产环境应用,承载着每天百亿的访问量,单实例峰值每秒请求达到15W QPS,已经接近ContainerDNS的性能极限(17W QPS)。为了更好的提高系统的并发服务,对ContainerDNS 的优化也势在必行。 本文对ContainerDNS性能优化思考和技术实践历程,希望对业内在容器领域和域名解析方
以前基于DPDK做NFV,转发程序跑在虚拟机中,先把硬件网卡passthrough给虚拟机,然后在虚拟机中把网卡绑定内核模块igb_uio,问题是igb_uio的代码没有upstream,依赖于内核版本,提前编译好的内核模块换个版本就不能运行,就想着用vfio-pci,这家伙早早upsteam,一般linux发行版本内核都自带,且不省事,理想是丰满的,现实是骨感的。
NIC 在接收到数据包之后,首先需要将数据同步到内核中,这中间的桥梁是 rx ring buffer。它是由 NIC 和驱动程序共享的一片区域,事实上,rx ring buffer 存储的并不是实际的 packet 数据,而是一个描述符,这个描述符指向了它真正的存储地址,具体流程如下:
在上一期,我们留下了一个问题:如何通过让专业的人做专业的事,提升虚拟化网元vSwitch的性能?
本文根据DPDK董事会董事和FD.io技术指导委员会成员George Zhao先生在2020网络数据平面峰会上的演讲《开源网络数据平面生态》整理而成。
本文基于vpp 主线master分支版本号v24.02介绍当前vpp ipsec crypto框架。在公众号《DPDK与SPDK开源社区》中,有一篇文章介绍VPP的异步Crypto框架(链接在参考文章1中)。与当前版本框架相差不大。
George Zhao,目前任职华为在美国的研发公司 Futurewei Technologies,主要从事网络开源与生态发展。曾经担任过 OpenDaylight 董事,技术指导委员会成员,社区经理和版本经理,目前是DPDK 董事会董事 和FD.io 技术指导委员会成员。
目前大多需要进行高速流量处理的场景,基本都是使用DPDK进行数据包处理加速,DPDK虽然是开源免费的,但是DPDK提供的API很简单,进行开发十分复杂,耗时,应用困难,于是许多人开始寻找替代方案–虹科PF_RING ZC。
领取专属 10元无门槛券
手把手带您无忧上云