赵占旭的博客

OVS-DPDK 瓶颈分析

注:本文是参照了一些其他文章,原文地址点击这里

前言


推荐看原文,因为我是懵逼的。并且这也算是广告贴了。

谈到优化应用程序的性能,开发人员不必是性能专家,但应该精通自己的应用程序。许多方面的因素都会对应用程序性能产生影响,需要从硬件平台,代码设计和利用microarchitecture特性对功能代码进行微调。应用程序开发人员了解应用程序如何利用硬件资源的基本要求是,对代码设计和实现有深入理解。这可以通过对硬件microarchitecture有更深入的了解,或者通过使用诸如VTune™ Amplifier的专用分析工具来实现。

top-down方法


一个比较好的性能调优方法是top-down的方式。 这种方法有三个阶段:顶部的系统调整,中间的应用程序调整和底层的microarchitecture调整。 系统调整涉及硬件和操作系统调整,而应用程序调整包括更好的设计,并行化和提高库的效率。 microarchitecture是最后一个阶段,包括仔细选择编译器标志,向量化和代码重构w.r.t内存/缓存优化以及对CPU陷阱的理解,如下图所示。

avatar

Microarchitecture和Micro-operations


avatar

上图描述了第四代Intel® Core™ microarchitecture,其中上绿色部分是前端,下蓝色部分是pipeline的后端。前端是指令(例如ADD,MUL)被取出和解码(转换为较小的操作,称为micro-operations[μ-Ops])的地方。后端是执行所需操作,实际计算的地方。pipeline的每个块的详细描述超出了本文的范围。下图描述了前端和后端处理器流水线的职责。

avatar

micro-operations(也称为μOps)成功完成整个datapath,称为retired。后端可以在每个cycle达到4个μOps。μOps通过(pass through)处理器pipeline并retired;偶尔由于各种分支错误预测,推测性地提取的几个μOps就会在其间被取消。pipeline slot表示处理一个μOp所需的硬件资源,这意味着在每个时钟周期的CPU核上有四个pipeline slot可用。如前所述,每个cycle可以有四个μOps retired,这意味着每个指令在理论上应该耗费0.25个cycle。

在给定的时间点,pipeline slot可以为空或用μOps填充。pipeline slot分为四类,如下图所示。有关pipeline slot分类的更多信息,请参见本文

avatar

VTune™ Amplifier


VTune Amplifier通过利用作为CPU内核的部分PMU(performance monitoring units)来收集测量结果。专用监视计数器可以收集和公开关于硬件资源消耗的信息。在PMU的帮助下,可以测量和检索关于所处理的指令的效率和缓存使用的度量。熟悉各种可用的指标(例如retired instructions; clock ticks; L2, L3 cache statistics; branch mis-predicts等)非常重要。此外,可以测量非CPU的PMU度量,如从/向存储器控制器读/写的字节,以及由Intel® QPI(Intel® QuickPath Interconnect)传输的数据流量。

下面是用于计算不同pipeline slot度量的简要描述和公式。如果后端准备好接受更多μOps,而前端每个周期传送小于4μOps,那么应用程序考虑是front-end bound。这可能是由于提取代码(cache/ITLB问题)或解码指令的延迟所致。front-end bound pipeline slot可以被分类为子类别,如下图所示。

公式:IDQ_UOPS_NOT_DELIVERED.CORE / (4 * Clockticks)

avatar

如果由于在pipeline的后端缺少所需的资源而没有传送μOps,则应用程序考虑是back-end bound。这可能是因为内部结构填充了等待数据的μOps。下图中进一步描绘了front-end bound子类别。

公式:Formula: 1 - (Front-end Bound + Bad speculation + Retiring)

avatar

由于从分支错误预测或机器清除中恢复,μOps从不retire或分配slots被浪费时,pipeline slot被归类为bad speculation。

公式:(UOPS_ISSUED.ANY - UOPS_RETIRED.RETIRE_SLOTS + 4* INT_MISC.RECOVERY_CYCLES) / (4* Clockticks)

avatar

如果成功传递的μOps最终retired,那pipeline slot被归类为retiring

公式:UOPS_RETIRED.RETIRE_SLOTS / (4 * Clockticks)

avatar

每个子类别的详细描述超出了本文的范围。 有关每个子类别的深入描述,请参考CPU指标参考

OVS-DPDK瓶颈分析


通过上面的一堆看不懂的东东,终于可以到了我想看到的性能瓶颈分析了,接着往下看吧,骚年。

流表的报文批处理


OVS-DPDK报文pipeline的一个重要阶段是流量批处理。首先对每个传入的报文进行分类,然后根据其匹配流进行分组,如下图所示。

avatar

进入流表批处理的报文,根据该流表定义的相应的action(drop,push / pop VLAN)进行处理。为了提高报文转发性能,同一流表的报文将被批处理。偶尔,批处理中可能会有很少的报文。在最坏的情况下,每个获取的报文都匹配不同的流,因此每个批处理将包含一个数据包。当流表的相应action是将报文转发到某个物理端口时,由于DPDK接口上的数据包传输会导致昂贵的内存映射I/O(MMIO)写操作,所以传输报文可能非常低效。

下图显示了报文处理关系调用图。对于每个输入的报文,在EMC中执行查找以匹配流表。在EMC命中的情况下,将报文使用dp_netdev_queue_batches()匹配流(请参阅OvS-DPDK源代码中的struct packet_batch_per_flow)。此后,使用packet_batch_per_flow_execute进行更快的数据包处理。如果流表的相应action是将数据包转发到DPDK端口,netdev_send将被调用,如下图所示。

avatar

64字节UDP报文的性能基准测试


用IXIA流量仪搭建测试环境,它发送64字节的UDP报文。在”PHY2PHY”测试用例中,有数十个不同的流时观察到显着的性能下降。请注意,流规则是唯一的,并且根据报文的源IP匹配流表。示例流程规则如下所示; 这将创建四个批次,并且数据包排队到相应的批次。

1
2
3
4
$ ovs-ofctl add-flow br0 in_port=4,dl_type=0x0800,nw_src=2.2.2.1,actions=output:2
$ ovs-ofctl add-flow br0 in_port=4,dl_type=0x0800,nw_src=4.4.4.1,actions=output:2
$ ovs-ofctl add-flow br0 in_port=4,dl_type=0x0800,nw_src=6.6.6.1,actions=output:2
$ ovs-ofctl add-flow br0 in_port=4,dl_type=0x0800,nw_src=8.8.8.1,actions=output:2

根据上述流程规则,VTune General Exploration分析显示了对OVS-DPDK传输瓶颈的有趣见解。

VTune Amplifier总结


当VTune分析运行60秒时,下图显示了VTune Amplifier关于pipeline slots占用情况的总结。请注意,粉红色的高亮slots需要注意,并由VTune根据应用程序类别的默认阈值自动高亮显示。

avatar

根据VTune文档,下图显示了通过VTune放大器输出的OVS-DPDK结果,HPC(high-performance computing)应用程序中pipeline slots的预期范围之间的比较。

avatar

如上图所示,对于特定的测试用例,OVS-DPDK是back-end bound的,retiring(只有35%)远远低于预期和健康70%限制的指令。bottom-up的分析显示了一些有趣的细节,如下图所示。

  • netdev_dpdk_eth_send()消耗了总周期的17%。
  • 上述功能的每个指令周期(CPI)为4.921,远高于理论极限0.25,在HPC应用情况下可接受的范围为1.0。
  • 此功能完全是back-end bound,并且几乎不retiring任何指令(小于6%)。

avatar

通过扩展back-end Bound列,可以更详细地了解back-end pipeline中发生的情况。 下图描述了back-end pipeline中的瓶颈在何处,并且它指向了L1 cache中的一个重大问题。

avatar

列出的函数是关于报文传输的。这可能意味着back-end pipeline在I/O操作中遇到长时间的延迟。所以瓶颈可能是在于MMIO操作。当处理的报文(最多32个)匹配许多不同的流表时,情况尤其如此。在每个报文正在触发不同流表的最坏情况下,将触发MMIO操作,以从相应批处理去处理每个报文。

降低MMIO成本的解决方案


在实际情况下,物理端口的报文可能会遇到很多流表,每个流表的批处理缓存非常少的报文。当报文通过DPDK接口传输时,这变得非常低效。为了摊销MMIO写入的成本,可以使用中间队列来排队”NETDEV_MAX_BURST”(即32个)报文,并以rte_eth_tx_burst的格式发送数据包。中间队列是使用netdev_dpdk_eth_tx_queue()函数实现的,它将对数据包进行排队。当满足以下条件之一时,数据包将被传送。

  • 如果txq(txq-> count)> = NETDEV_MAX_BURST中的数据包计数,则调用netdev_dpdk_eth_tx_burst()来突发报文。
  • 超时后,任何等待队列的数据包都必须刷新,而不管其数量如何。

通过这种解决方案,可以观察到back-end和Retiring类别的改进,如下图所示。

avatar

下图显示,在应用补丁后,函数netdev_dpdk_eth_send()从列表的顶部到底部大幅度移动。通过减轻MMIO延迟的影响,测量的CPI从4.921下降到1.108。

avatar

请注意,通过报文传输路径中的更多优化可以进一步提高性能; 但是,这超出了本文的范围。以上是使用VTune Amplifier了解和修复HPC应用程序瓶颈的示例。 在我们使用VTune Amplifier的分析中,我们使用了General Exploration模式,并集中在back-end bound度量上。值得注意的是,其他分析类型在VTune Amplifier工具中可用,如热点,高级热点模式,hpc性能,内存访问和锁定和等待。此外,其他指标可用于显示资源消耗。

注意:所有文章非特别说明皆为原创。为保证信息与源同步,转载时请务必注明文章出处!谢谢合作 :-)

原始链接:http://zhaozhanxu.com/2017/02/03/SDN/OVS/2017-02-03-analyzing-bottlenecks/

许可协议: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。