前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >几行代码修改引发VPP性能严重下降?

几行代码修改引发VPP性能严重下降?

作者头像
dpdk-vpp源码解读
发布2023-06-23 10:40:27
6310
发布2023-06-23 10:40:27
举报
文章被收录于专栏:DPDK VPP源码分析DPDK VPP源码分析

前段时间同事在测试Mellanox ConnectX-6网卡在vpp和dpdk l2fwd or l3wfd性能对比,发现新版本中vpp性能下降明显。当时正巧我在vpp-dev邮箱列表中看到有关此网卡性能下降的讨论。

在Afaik VPP xconnect(相当于 l2fwd)或 L3 路由(l3wfd)早 2017 年的vpp版本中都可以产生 10 Mpps性能(如下图所示),而在22.10版本中只有6Mpps。

测试环境配置如下:

Traffic Gen: TRex running on Intel(R) Xeon(R) Gold 6354 CPU @ 3.00GHz DuT: VPP 22.10 running on Icelake Intel(R) Xeon(R) Platinum 8352Y CPU @ 2.20GHz NICs: ConnectX-6 Dx Dualport OS: Ubuntu Server 20.04

作者使用基于vpp22.10版本源码,修改dpdk.mk来支持编译MLX5_PMD.驱动。作者运行普通 DPDK 22.07 示例 l2fwd 或 l3fwd 使用 1 个 lcore 产生 > 10 Mpps(100 Gbps 线路速率,也不需要额外的 dpdk 选项)。而使用编译后vpp版本运行l2xconnect和L3路由,相同的测试环境下性能下降到6Mpps。相关配置参数如下:

代码语言:javascript
复制
#dpdk 响应的版本及参数
VPP show dpdk version:
DPDK Version:             DPDK 22.07.0
DPDK EAL init args:       --in-memory --no-telemetry --file-prefix vpp -a 0000:4b:00.0,mprq_en=1,rxqs_min_mprq=1,mprq_log_stride_num=9,
txq_inline_mpw=128,rxq_pkt_pad_en=1 
-a 0000:4b:00.1,mprq_en=1,rxqs_min_mprq=1,mprq_log_stride_num=9,
txq_inline_mpw=128,rxq_pkt_pad_en=1 
#l2 
 set interface l2 xconnect HundredGigabitEthernet4b/0/0 HundredGigabitEthernet4b/0/1
 set interface l2 xconnect HundredGigabitEthernet4b/0/1 HundredGigabitEthernet4b/0/0

# l3 routing
 set interface ip address HundredGigabitEthernet4b/0/0 10.10.1.1/24
 set interface ip address HundredGigabitEthernet4b/0/1 10.10.2.1/24
 ip route add 16.0.0.0/8 via 10.10.1.2
 ip route add 48.0.0.0/8 via 10.10.2.2 

邮件中提出可以通过设置 no-multi-seg 选项来提高 Mellanox DPDK PMD 的性能。而作者设置此选项性能下降到小于1Mpps。

通过使用 DPDK 的默认 /etc/vpp/startup.conf 选项,只有仅仅 4 Mpps性能。 而参考DPDK mellanox perf-report 中所推荐的配置性能又提升了20%。

代码语言:javascript
复制
#在/etc/vpp/startup.conf文件中dpdk 选项中增加下述配置。
devargs mprq_en=1,rxqs_min_mprq=1,mprq_log_stride_num=9,txq_inline_mpw=128,
rxq_pkt_pad_en=1,dv_flow_en=0

作者最后通过设置no-multi-seg 选项,并将vpp版本下降到21.10版本,性能才恢复到正常水平。在DPDK 21.11版本有一些变更影响了no-multi-seg 选项。下面是邮件中回复内容说明修改原因:

在 VPP 的 DPDK RX 中,最初的实现是取 256 个数据包。如果没有从 NIC 队列中提取足够的数据包,则使用较小的数量重试。

DPDK 21.11 通过不将大突发大小切片为较小(比如 32)并在启用“no-multi-seg”时多次执行 NIC RX 引入了更改,这导致 VPP 总是在第一次尝试时耗尽 NIC 队列,并且 NIC在 CPU 执行另一个 RX 突发之前无法跟上将足够的描述符填充到队列中 - 至少英特尔 FVL 和 CVL 是这种情况。

这最终导致大量空轮询,并且 vpp 向量大小始终为 64 而不是 256(对于 CVL 和 FVL)。

我解决了 CVL/FVL 的问题,方法是让 VPP 仅多次手动执行较小的突发大小(最多 32)。但是,由于缺少硬件,我没有在 MLX NIC 上进行测试。(a9fe20f4b dpdk:改进每个循环的 rx 突发计数)

由于不同的硬件有其突发大小的最佳点,这使得它能够与 CPU 协调工作。

当 VPP 请求 256 个数据包时,FVL/CVL 驱动程序实际上只提供最多 64 个描述符供 CPU 在任何给定时间获取,因此缓冲区已耗尽。由于现在 CPU 非常快,我们渴望更多的数据包,CPU 会不断询问 NIC - 尴尬的情况发生了,NIC 正忙着告诉 CPU 下次不要再来了,但永远不会重新填充临时缓冲区。于是就成了网卡和CPU之间的一个特殊的“死锁”。

回答你的重试问题——我实际上编写了无限期重试的代码,代码进入了 100% 真正的死锁,无论我尝试了多少次,提取的数据包总数都是 64。

解决方案很简单,不是耗尽描述符的临时缓冲区,我们总是要求 64 个数据包的一半,下次进行 rx burst 时,NIC 很乐意将剩余的 32 个数据包交给 CPU,同时重新填充 32 个数据包以准备没问题。

vpp patch修改内容如下:

代码语言:javascript
复制
From a9fe20f4b8f7a9bd65cc8ee1b6a0204af7fc3627 Mon Sep 17 00:00:00 2001
From: Fan Zhang <roy.fan.zhang@intel.com>
Date: Thu, 10 Mar 2022 14:49:19 +0000
Subject: [PATCH] dpdk: improve rx burst count per loop

Type: improvement

This patch improves the per dpdk-input loop number of packets
received from the port. The change mimics how packets rx happened
before VPP 22.02/DPDK 21.11: instead of trying to rx huge number
of packets (256) in one go, rx more times with up to 32 packets
max each time.

Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
Change-Id: I804dce6d9121ab21b02e53dd0328dc52ac49d80f
---

diff --git a/src/plugins/dpdk/device/node.c b/src/plugins/dpdk/device/node.c
index 0450c42..b460032 100644
--- a/src/plugins/dpdk/device/node.c
+++ b/src/plugins/dpdk/device/node.c
@@ -365,12 +365,13 @@
   /* get up to DPDK_RX_BURST_SZ buffers from PMD */
   while (n_rx_packets < DPDK_RX_BURST_SZ)
     {
-      n = rte_eth_rx_burst (xd->port_id, queue_id,
-                ptd->mbufs + n_rx_packets,
-                DPDK_RX_BURST_SZ - n_rx_packets);
+      u32 n_to_rx = clib_min (DPDK_RX_BURST_SZ - n_rx_packets, 32);
+
+      n = rte_eth_rx_burst (xd->port_id, queue_id, ptd->mbufs + n_rx_packets,
+                n_to_rx);
       n_rx_packets += n;

-      if (n < 32)
+      if (n < n_to_rx)
     break;
     }

如有遇到使用vpp 22.10及以上版本 ,ConnectX-6网卡性能存在下降的朋友,可以回退上述path修改试试,是否有性能提升?

参考资料: 1.https://wiki.fd.io/images/3/31/Benchmarking-sw-data-planes-Dec5_2017.pdf 2.https://lfnetworking.org/wp-content/uploads/sites/ 7/2022/06/benchmarking_sw_data_planes_skx_bdx_mar07_2019.pdf 3.https://lists.fd.io/g/vpp-dev/topic/slow_vpp_performance_vs_dpdk/95959719

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2023-03-29,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 DPDK VPP源码分析 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
腾讯云服务器利旧
云服务器(Cloud Virtual Machine,CVM)提供安全可靠的弹性计算服务。 您可以实时扩展或缩减计算资源,适应变化的业务需求,并只需按实际使用的资源计费。使用 CVM 可以极大降低您的软硬件采购成本,简化 IT 运维工作。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档