济南 营销型网站建设,信誉好的营销单页网站,做网站公司cnfg,给视频做特效的网站问题描述
dpdk 程序在配置网卡队列时会涉及收发包队列描述符数量配置问题#xff0c;收发包描述符的数量看似是一个简单的配置#xff0c;却对转发性能有着一定的影响。实际业务程序中#xff0c;收发包描述符大小配置一般参考 dpdk 内部示例程序配置进行#xff0c;经验之…问题描述
dpdk 程序在配置网卡队列时会涉及收发包队列描述符数量配置问题收发包描述符的数量看似是一个简单的配置却对转发性能有着一定的影响。实际业务程序中收发包描述符大小配置一般参考 dpdk 内部示例程序配置进行经验之谈是不同的网卡配置不同的描述符大小如何确定不同网卡最优的值是一个实际的问题。
dpdk 示例程序中的缺省配置
dpdk-19.11 testpmd 示例程序源码中使用如下变量配置收发包描述符
#define RTE_TEST_RX_DESC_DEFAULT 0
#define RTE_TEST_TX_DESC_DEFAULT 0
uint16_t nb_rxd RTE_TEST_RX_DESC_DEFAULT; /** Number of RX descriptors. */
uint16_t nb_txd RTE_TEST_TX_DESC_DEFAULT; /** Number of TX descriptors. */这里的 nb_rxd 与 nb_txd 分别表示收包描述符个数与发包描述符个数可以看到这里缺省的配置都为 0。 第一次读到这块代码感觉有些奇怪在 testpmd 的所有源码中搜索了下确认收发包描述符的缺省配置确实是这里实现的。 0 显然是个非法的数据但是这里的代码又是这样写的不由让人猜测是不是哪里有针对性地处理于是分析了下代码在本文中记录一下。
testpmd 中 nb_rxd 与 nb_txd 真正配置到 dpdk 中的代码
rte_eth_rx_queue_setup
rte_eth_tx_queue_setup如上两个函数分别配置收包队列与发包队列这两个函数的第三个参数就是描述符数量的配置项目。
nb_rxd 与 nb_txd 最终通过间接传入到这两个函数中实现描述符配置说明业务层没有做额外的处理于是进入到 ethdev 实现中寻找线索。
rte_eth_rx_queue_setup 中相关代码 /* Use default specified by driver, if nb_rx_desc is zero */if (nb_rx_desc 0) {nb_rx_desc dev_info.default_rxportconf.ring_size;/* If driver default is also zero, fall back on EAL default */if (nb_rx_desc 0)nb_rx_desc RTE_ETH_DEV_FALLBACK_RX_RINGSIZE;}
可以看到当描述符配置为 0 时使用 rte_eth_dev_info_get 获取到的驱动提供的 dev_info.default_rxportconf.ring_size配置的值如果此配置为 0 则使用宏RTE_ETH_DEV_FALLBACK_RX_RINGSIZE定义的值其值为 512。
rte_eth_tx_queue_setup 处理逻辑类似不再赘述。
驱动中设置 default_rxportconf.ring_size 的代码
dpdk pmd 驱动种类繁多这里以 i40e 驱动为例分析这部分配置的逻辑。 搜索到 i40e_dev_info_get 函数中有如下代码 if (I40E_PHY_TYPE_SUPPORT_40G(hw-phy.phy_types)) {/* For XL710 */dev_info-speed_capa ETH_LINK_SPEED_40G;dev_info-default_rxportconf.nb_queues 2;dev_info-default_txportconf.nb_queues 2;if (dev-data-nb_rx_queues 1)dev_info-default_rxportconf.ring_size 2048;elsedev_info-default_rxportconf.ring_size 1024;if (dev-data-nb_tx_queues 1)dev_info-default_txportconf.ring_size 1024;elsedev_info-default_txportconf.ring_size 512;} else if (I40E_PHY_TYPE_SUPPORT_25G(hw-phy.phy_types)) {/* For XXV710 */dev_info-speed_capa ETH_LINK_SPEED_25G;dev_info-default_rxportconf.nb_queues 1;dev_info-default_txportconf.nb_queues 1;dev_info-default_rxportconf.ring_size 256;dev_info-default_txportconf.ring_size 256;} else {/* For X710 */dev_info-speed_capa ETH_LINK_SPEED_1G | ETH_LINK_SPEED_10G;dev_info-default_rxportconf.nb_queues 1;dev_info-default_txportconf.nb_queues 1;if (dev-data-dev_conf.link_speeds ETH_LINK_SPEED_10G) {dev_info-default_rxportconf.ring_size 512;dev_info-default_txportconf.ring_size 256;} else {dev_info-default_rxportconf.ring_size 256;dev_info-default_txportconf.ring_size 256;}}将上述逻辑进行整理得到如下表格
⽹卡类型收发包队列数⽬收包描述符个数发包描述符个数40G XL71012048102440G XL710大于 1102451225G XXV710*256256X710 10G*512256X710 1G*256256
观察到上面的表格有如下特征
收包描述符一般为发包描述符数量的 2 倍带宽更高的网卡一般需要配置更大数量的收发包描述符数目
dpdk 网卡收发包队列缺省描述符配置如何确定
使用驱动内部默认值默认值不符合要求则单独调优
代码配置方式如下
应用程序调用 rte_eth_rx_queue_setup 时设置 nb_rx_desc 参数为 0应用程序调用 rte_eth_tx_queue_setup 时设置 nb_tx_desc 参数为 0重新编译应用部署运行测试性能是否达标
此时 dpdk 内部会根据不同网卡类型获取驱动缺省配置进行设置如果驱动未提供缺省值则使用全局默认值这些配置值都是最优配置。
收发包描述符影响什么
发包流程
在 网卡手册阅读ixgbe 发包流程研究 这篇文章中我描述过 intel 82599 网卡的发包流程其中一个关键的结构是环形描述符队列。
dpdk 驱动发包时首先会申请【空闲】的发包描述符然后使用 mbuf 中的字段填充描述符填充完成后再更新 TDT 寄存器设置了一个门限降低频繁访问寄存器 I/O 的性能影响。
网卡硬件读取 TDH 与 TDT之间的发包描述符发起 PCIE 传输 copy 报文到内部的 fifo 中然后更新 TDH 并回写描述符也存在一个门限。
上图实际运作过程中TDH 在不断的追 TDT到达环的底部后再回到起始位置。
cpu 填充发包描述符的速度很快这个环形队列的长度在某种程度上代表了cpu 缓冲给 PCIE 传输与网卡更新描述符的时间理想的情况是 cpu 一直能够获取到空闲的描述符这样 cpu 等待的时间就非常少了cpu 与 PCIE、网卡的并行性更好性能表现也就更好了。
如果将描述符的数量设置为 1在这种极端的情况下cpu 就要不断地等待接近于上文描述的在 rte_eth_tx_burst 中等待发包完成的情况。
在 dpdk 问题分析dpdk-19.11 性能优于 dpdk-16.04 问题分析 这篇文章中我就曾经描述过通过调大 dpdk-16.04 的默认描述符个数来达到性能优化的目标背后的原理就是增加留给 PCIE 传输报文与网卡处理的缓冲时间。
收包流程
收包流程也存在一个环形描述符队列其中的并行性问题与发包大致相同不过发包描述符的数量配置在一定情况下对收包也有影响增加发包描述符为网卡硬件传输缓冲了更多时间但是也意味着对报文 buf 占用了更多的时间当收包已经接近负载的时候可能会因为发包描述符的调整导致 buf 不足出现 imissed一般需要对收发包描述符整体调优单点调优的意义不大。
总结
网卡收发包队列描述符配置看似是一个小的配置其背后也有诸多细节。如何确定一个最优的配置常常不是一个容易的问题需要对现有的实现跟底层原理有相对清晰的了解既知道哪种配置是最优的也知道为啥它是最优的这点就相对有些难度了。
