dpdk优化相关转

注：本文是参照了一些其他文章，原文地址点击这里。

首先根据这篇文章进行了性能瓶颈的分析

策略与方法

首先根据木桶原理，首先要找到最弱的地方，怎么找往上看↑。

想能优化需要考虑如下：

优化BIOS设置
有效的分配NUMA资源
优化Linux配置
运行l3-fwd程序验证以上的配置，和公布的性能对比
运行micro-benchmarks选出最佳的更性能组件(比如bulk enqueue/bulk dequeue相对于single enqueue/single dequeue)
从dpdk的例子中找一个接近于你想要写的程序，按照上面的默认配置来(比如TX buffers资源比RX多)
适配和更新应用程序，使用正确的优化标志编译
配置你选择的应用程序，以便有一个比较的基础
运行优化过的命令行参数
怎样为架构匹配更好的应用和算法？运行分析找到内存绑定？I/O绑定？CPU绑定？
应用相应的解决方案，软件内存预取，IO的阻塞模式，CPU绑定超线程或者不
重新运行分析，找出是前端pipeline影响还是后端pipeline影响
应用正确的解决方案。编写更加有效的代码-分支预测(likely)，循环展开，编译优化等等
没有得到期望的性能，回到上面运行优化过的命令行参数，再来一次
记录容易记住的方法，分享到dpdk官网

优化BIOS设置

NUMA	ENABLED
Enhanced Intel® SpeedStep® technology	DISABLED
Processor C3	DISABLED
Processor C6	DISABLED
Hyper-Threading	ENABLED
Intel® Virtualization Technology for Directed I/O	DISABLED
MLC Streamer	ENABLED
MLC Spatial Prefetcher	ENABLED
DCU Data Prefetcher	ENABLED
DCU Instruction Prefetcher	ENABLED
CPU Power and Performance Policy	Performance
Memory Power Optimization	Performance Optimized
Memory RAS and Performance Configuration -> NUMA Optimized	ENABLED

请注意，如果要使用DPDK电源管理功能，必须启用EnhancedIntel®SpeedStep®技术。此外，应启用C3和C6。

平台优化

平台优化包括配置内存和I/O(NIC卡)以利用affinity实现更低的延迟。

NUMA & Memory Controller

举个多socket插座的例子，对于在CPU0上运行的线程，socket0访问local memory延迟较低，通过QPI(Intel® QuickPath Interconnect)访问remote memory延迟较高，尽量避免。

问题：
在BIOS中NUMA设置为DISABLED会发生神马？内存控制器通过socket交叉访问。例如，如下所示，CPU0正在读取256个字节（4个高速缓存行）。由于BIOS NUMA设置为DISABLED状态，因为内存控制器交叉存取在256个字节之内的访问，从本地存储器读取128字节，从远程存储器读取128字节。远程内存访问最终跨越QPI链路。这样做的影响是访问远程内存的访问时间增加，从而导致性能降低。

解决方案：
如下图所示，BIOS设置NUMA = Enabled，所有访问都进入相同的socket(local)内存，没有QPI交叉。存储器访问的延迟较，低性能提高。

PCIe* Layout and IOU Affinity

Linux优化

使用isolcpus减少上下文切换

为了减少上下文切换的可能性，需要提示内核，禁止将其他用户空间任务调度到DPDK应用线程所在核。isolcpus Linux内核参数用于此目的。

例如，如果DPDK应用程序要在逻辑核心1,2和3上运行，则应将以下内容添加到内核参数列表中：
isolcpus = 1,2,3

注意：即使使用isolcpus提示，调度程序仍可以在隔离的核心上调度内核线程。请注意，isolcpus需要重新启动。

适配和更新应用程序

现在已经将相关示例应用程序标识为构建最终产品的起点，以下是要回答的下一组问题。

如何配置应用程序以获得最佳性能？

每个端口可以配置多少个队列？
Tx资源可以分配为与Rx资源相同的大小吗？
阈值的最佳设置是什么？

建议：好消息是，示例应用程序不仅具有优化的代码流，而且优化的参数设置为默认值。建议在Tx和Rx的资源之间使用类似的比例。以下是Intel® Ethernet Controller 10 Gigabit 82599的参考和建议。对于其他NIC控制器，请参阅相应的数据手册。

每个端口可以配置多少个队列？

有关此主题的详细测试设置和配置，请参阅白皮书评估软件路由器的服务器网卡的适用性。

下面的图（从上面的白皮书）指示每个端口不使用多于2到4个队列，因为性能随着更高数量的队列而降低。

对于最佳情况，建议每个端口使用1个队列。如果需要更多，可以考虑每个端口2个队列，但不能超过2个。

Tx资源可以分配为与Rx资源相同的大小吗？

为Tx和Rx分配相等大小的资源是一种自然的趋势。然而，请注意，http://dpdk.org/browse/dpdk/tree/examples/l3fwd/main.c显示，Tx ring描述符的数量的最佳默认大小是512，而Rx ring描述符是128.因此，Tx ring描述符的数量是Rx ring描述符的4倍。

建议选择Tx ring描述符是Rx ring描述符的4倍，而不是让它们具有相等的大小。

##　阈值的最佳设置是什么？

例如，http://dpdk.org/browse/dpdk/tree/app/test/test_pmd_perf.c具有以下针对Intel Ethernet Controller 10 Gigabit 82599的优化默认参数。

更详细的说明，请参阅Intel Ethernet Controller 10 Gigabit 82599 data sheet。

Rx_Free_Thresh - 快速总结和关键点：PCIe处理（更新硬件寄存器）的成本可以通过处理批量的数据包（在更新硬件寄存器之前）摊销。

Rx_Free_Thresh - 详细：如下所示，由硬件接收的报文使用报文描述符的循环缓冲器来完成。在循环缓冲器中可以有多达64K-8个描述符。硬件维护卷影副本，包括已完成但尚未存储在内存中的那些描述符。

RDH(Receive Descriptor Head register)表示正在进行的描述符。

RDT(Receive Descriptor Tail register)表示超出硬件可以处理的最后一个描述符的位置。这是软件写入第一个新描述符的位置。

在运行时，软件处理描述符，并在描述符完成后，RDT+1。然而，在软件处理每个分组之后更新RDT具有成本，因为其增加了PCIe操作。

Rx_free_thresh表示DPDK软件在将其发送回硬件之前将保持的空闲描述符的最大数量。因此，通过在更新RDT之前批量处理报文，我们可以减少该操作的PCIe成本。

使用您的配置的rte_eth_rx_queue_setup（）函数中的参数进行微调

1
2
3

ret = rte_eth_rx_queue_setup(portid, 0, rmnb_rxd,
        socketid, &rx_conf,
        mbufpool[socketid]);

使用正确的优化参数编译

应用相应的解决方案：软件预取的内存，I/O阻塞，超线程或不超线程为CPU绑定的应用程序。

内存的软件预取有助于降低存储器延迟。

PREFETCHW：预期写数据时预取到高速缓存：CPU Haswell的新指令，帮助优化降低内存延迟并改善网络堆栈。

PREFETCHWT1：意图写入的预取提示T1（L1高速缓存）：CPU Haswell的新指令，意图写入提示（使数据通过所有权请求进入“独占”状态），将数据提取到指定的高速缓存层级中的位置和位置提示。

有关这些说明的更多信息，请参阅Intel® 64 and IA-32 Architectures Developer’s Manual。

使用优化的命令行参数运行

优化应用程序命令行选项，提高affinity、locality和并发性。

coremask参数

coremask参数指定lcore运行DPDK应用程序。更高的性能，降低处理器间通信成本是关键。这样的沟通的核心是物理的邻居，应该选择coremask。

问题︰ DPDK的命令行coremask参数指定了lcore 0和lcore 1两个相邻芯。请注意，这些lcore号分别映射到指定的NUMA sockets上。不同的平台是不一样的，这个平台上可能lcore 0和1是邻居，有些平台可能不是。

如下图所示，在单socket，lcore 0和lcore 4是相同的物理core（core 0）的兄弟姐妹。所以lcore 0和 lcore 4之间的通信成本低于lcore 0和lcore 1之间的通信成本。

解决方案：不同的平台布局的时候需要注意使用不同的方案。

查看CPU布局的工具

通过tools目录的./cpu_layout.py能找出socket ID，物理core ID，lcore ID。根据这些信息来确定coremask参数怎么确定。

dual-socket机器我们看到的CPU布局如下：
物理core为[0, 1, 2, 3, 4, 8, 9, 10, 11, 16, 17, 18, 19, 20, 24, 25, 26, 27]
注意物理core 5, 6, 7, 12, 13, 14, 15, 21, 22, 23不在上面的范围中，这表明物理核心不一定是连续的。

怎么从cpu布局中找到哪些lcores是超线程的？
在下图中，lcore 1和lcore 37是socket 0的超线程，将通信任务分配给lcore 1和lcore 37比分配给其他的lcore有更低的消耗和更高的性能。

core 0留给Linux，别给DPDK用

DPDK初始化中，master core默认使用的是lcore 0。如下图所示

DPDK应用程序尽量不使用lcore 0，因为Linux 把lcore 0作为master core。避免使用l3fwd – c 0x1…，因为这会使用lcore 0。相反，应用程序可以使用lcore 1，命令行为l3fwd — — c 0x2……。

实际使用OVS-DPDK的情况下，控制平面线程绑定lcore 0，负责响应用户或SDN控制器发出的控制平面命令。所以，DPDK应用程序不应使用lcore 0，设置掩码的时候不激活lcore 0。

正确使用channel参数

要确保正确使用channel参数。例如，使用channel参数n = 3表示3通道内存系统。

DPDK Micro-benchmarks and auto-tests

auto-tests用于功能验证。以下是几个micro-benchmarks性能评价的例子。

怎么测试两个core的cache line往返消耗的时间

http://dpdk.org/browse/dpdk/tree/app/test/test_distributor_perf.c中的函数Time_cache_line_switch()就是用来测试两个core的cache line往返所需要的cpu cycles。

怎么测试报文处理时间

http://dpdk.org/browse/dpdk/tree/app/test/test_distributor_perf.c中的函数Perf_test()一次发送32个报文，最后工作线程记录收到最后一个报文的时间，然后计算出每个报文消耗的时间。

怎么检测single producer/single consumer(sp/sc)和multi-producer/multi-consumer(mp/mc)之间的性能差异

运行/app/test中的ring_perf_auto_test，会输出cpu cycles，来对比不同bulk下sp/sc和mp/mc的差别。

关键点：高bulk下，sp/sc有更高的性能。

注意，默认ring_perf_auto_test贯穿块大小8-32的性能测试，但是如果想自定义，需要修改数组bulk_size[]。下图输出了1、2、4、8、16、32的块大小。

2-Socket System – Huge Page Size = 2 Meg

hash_perf_autotest为每个测试项运行1000000次迭代，改变以下的参数并且为每个组合总结出每次操作所用的时钟滴答(Ticks/Op)

Hash Function	Operation	Key Size (bytes)	Entries	Entries per Bucket
a) Jhash, b) Rte_hash_CRC	a) Add On Empty, b) Add Update, c) Lookup	a) 16, b) 32, c) 48, d) 64	a) 1024, b) 1048576	a) 1, b) 2, c) 4, d) 8, e) 16

附录有详细的测试输出和命令，您可以使用来评估您的平台的性能。摘要结果制成表格下, 图︰

Sl No.	Focus Area to Improve	Use These Micro-Benchmarks and Auto-Tests
1	Ring For Inter-Core Communication	单独enqueue/dequeue和批量enqueue/dequeue之间的性能对比分别对比不同的超线程、cores、sockets上的两个core之间的批量enqueue/dequeue 空ring上dequeue的性能test_ring_perf.c Single producer, single consumer – 1 Object, 2 Objects, MAX_BULK Objects – enqueue/dequeue Multi-producer, multi-consumer – 1 Object, 2 Objects, MAX BULK Objects – enqueue/dequeue 使用test_ring.c验证以上几项 test_pmd_ring.c分验证Tx Burst和Rx Burst
2	Memcopy	使用test_memcpy_perf.c分别验证以下几项： Cache to cache Cache to memory Memory to memory Memory to cache
3	Mempool	使用test_mempool.c验证以下几项的`n_get_bulk`和`n_put_bulk` 1 core, 2 cores, max cores with cache objects 1 core, 2 cores, max cores without cache objects
4	Hash	使用test_hash_perf.c验证`Rte_jhash`和`rte_hash_crc`的以下几项 Add, Lookup, Update
5	ACL Lookup	test_acl.c
6	LPM	test_lpm.c
7	Packet Distribution	test_distributor_perf.c
8	NIC I/O Benchmark	Benchmarks Network I/O Pipe - NIC h/w + PMD Measure Tx Only Measure Rx Only Measure Tx & Rx
9	NIC I/O + Increased CPU processing	Increased CPU processing – NIC h/w + PMD + hash/lpm Examples/l3fwd
10	Atomic Operations/ Lock-rd/wr	test_atomic.c和test_rwlock.c
11	SpinLock	使用test_spinlock.c验证以下两项：申请全局锁，做些操作，释放全局锁申请per-lcore锁，做些操作，释放per-core锁
12	Software Prefetch	test_prefetch.c用法为：rte_table_hash_ext.c
13	Reorder and Seq. Window	test_reorder.c
14	ip_pipeline	用packet framework创建一个pipeline，test_table.c ACL Using Packet Framework，test_table_acl.c
15	Reentrancy	test_func_reentrancy.c
16	mbuf	test_mbuf.c
17	memzone	test_memzone.c
18	Ivshmem	test_ivshmem.c
19	Virtual PMD	virtual_pmd.c
20	QoS	test_meter.c,test_red.c,test_sched.c
21	Link Bonding	test_link_bonding.c
22	Kni	使用test_kni.c验证以下几项：传输、从kernel接收、kernel请求
23	Malloc	test_malloc.c
24	Debug	test_debug.c
25	Timer	test_cycles.c
26	Alarm	test_alarm.c

编译优化

可以参考图书Pyster - Compiler Design and construction

性能优化和弱有序注意事项

背景︰Linux内核的同步原语包含所需的内存屏障如下所示（单处理器和多处理器的版本）

Smp_mb()	内存屏障
Smp_rmb()	读内存屏障
Smp_wmb()	写内存屏障
Smp_read_barrier_depends()	强制后续的操作是依赖与之前的操作，保证有序性
Mmiowb()	全局spinlocks保障有序的MMIO写操作