DPDK系列之三十三DPDK并行机制的底层支持

一、背景介绍

在前面介绍了DPDK中的上层对并行的支持，特别是对多核的支持。但是，大家都知道，再怎么好的设计和架构，再优秀的编码，最终都要落到硬件和固件对整个上层应用的支持。单纯的硬件好处理，一个核不够多个核，在可能的情况下把CPU的频率增加，加大缓存等等。在现有水平的范围内，这些都是可以比较容易做到的。
但是另外一个，就是在CPU上如何最终运行指令（也可以叫做固件设计），这个就需要设计人员动脑子了。一般来说，IPC（Instruction Per Clock，一个时钟周期内执行的指令数量，可不要看成进程间通信）的数量越高，CPU运行性能越高（频率和核数相同）。
现代CPU基本使用了越标量（superscalar）体系结构，通过以空间换时间的方式实行了指令级并行运算。不同的架构的处理器，可能在硬件设计本身有所不同，但在追求并行度上，原理基本相同。
在前面的多核编程中，介绍过几种指令，目前常用的基本以SIMD（单指令流多数据流）和MIMD（多指令流多数据流）为主。后者一般是多核和多CPU（当然更高层次的多计算机也算），但在分析本文中更倾向的是SIMD，毕竟一个核心能处理多少更能体现性能和效率。
SIMD其实很容易理解，可以认为是一种并行的批处理。原来只能一次取一条指令处理一条数据，这次可以一条指令处理多条数据。举个最简单的例子，加指令，需要有两次读操作数，而如果使用SIMD,则一次就可以都读进来。其后的处理周期也是如此，那么效率至少增加了一倍。
而这些指令设计和处理会形成一个指令集，它的发展也有一个过程，intel的SIMD指令集主要有MMX, SSE, AVX, AVX-512，主流就是SSE/AVX。AMD的比较复杂，有兴趣可以查找看一下。

二、DPDK中的应用

在DPDK中对SIMD的应用体现在数据的处理上，DPDK提供了一个化化的拷贝memcpy函数，它充分利用了SIMD指令集：

static __rte_always_inline void *
rte_memcpy(void *dst, const void *src, size_t n)
{if (!(((uintptr_t)dst | (uintptr_t)src) & ALIGNMENT_MASK))return rte_memcpy_aligned(dst, src, n);elsereturn rte_memcpy_generic(dst, src, n);
}
static __rte_always_inline void *
rte_memcpy_aligned(void *dst, const void *src, size_t n)
{void *ret = dst;/* Copy size < 16 bytes */if (n < 16) {return rte_mov15_or_less(dst, src, n);}/* Copy 16 <= size <= 32 bytes */if (n <= 32) {rte_mov16((uint8_t *)dst, (const uint8_t *)src);rte_mov16((uint8_t *)dst - 16 + n,(const uint8_t *)src - 16 + n);return ret;}/* Copy 32 < size <= 64 bytes */if (n <= 64) {rte_mov32((uint8_t *)dst, (const uint8_t *)src);rte_mov32((uint8_t *)dst - 32 + n,(const uint8_t *)src - 32 + n);return ret;}/* Copy 64 bytes blocks */for (; n >= 64; n -= 64) {rte_mov64((uint8_t *)dst, (const uint8_t *)src);dst = (uint8_t *)dst + 64;src = (const uint8_t *)src + 64;}/* Copy whatever left */rte_mov64((uint8_t *)dst - 64 + n,(const uint8_t *)src - 64 + n);return ret;
}
static __rte_always_inline void *
rte_memcpy_generic(void *dst, const void *src, size_t n)
{__m128i xmm0, xmm1, xmm2, xmm3, xmm4, xmm5, xmm6, xmm7, xmm8;void *ret = dst;size_t dstofss;size_t srcofs;/*** Copy less than 16 bytes*/if (n < 16) {return rte_mov15_or_less(dst, src, n);}/*** Fast way when copy size doesn't exceed 512 bytes*/if (n <= 32) {rte_mov16((uint8_t *)dst, (const uint8_t *)src);rte_mov16((uint8_t *)dst - 16 + n, (const uint8_t *)src - 16 + n);return ret;}if (n <= 48) {rte_mov32((uint8_t *)dst, (const uint8_t *)src);rte_mov16((uint8_t *)dst - 16 + n, (const uint8_t *)src - 16 + n);return ret;}if (n <= 64) {rte_mov32((uint8_t *)dst, (const uint8_t *)src);rte_mov16((uint8_t *)dst + 32, (const uint8_t *)src + 32);rte_mov16((uint8_t *)dst - 16 + n, (const uint8_t *)src - 16 + n);return ret;}if (n <= 128) {goto COPY_BLOCK_128_BACK15;}if (n <= 512) {if (n >= 256) {n -= 256;rte_mov128((uint8_t *)dst, (const uint8_t *)src);rte_mov128((uint8_t *)dst + 128, (const uint8_t *)src + 128);src = (const uint8_t *)src + 256;dst = (uint8_t *)dst + 256;}
COPY_BLOCK_255_BACK15:if (n >= 128) {n -= 128;rte_mov128((uint8_t *)dst, (const uint8_t *)src);src = (const uint8_t *)src + 128;dst = (uint8_t *)dst + 128;}
COPY_BLOCK_128_BACK15:if (n >= 64) {n -= 64;rte_mov64((uint8_t *)dst, (const uint8_t *)src);src = (const uint8_t *)src + 64;dst = (uint8_t *)dst + 64;}
COPY_BLOCK_64_BACK15:if (n >= 32) {n -= 32;rte_mov32((uint8_t *)dst, (const uint8_t *)src);src = (const uint8_t *)src + 32;dst = (uint8_t *)dst + 32;}if (n > 16) {rte_mov16((uint8_t *)dst, (const uint8_t *)src);rte_mov16((uint8_t *)dst - 16 + n, (const uint8_t *)src - 16 + n);return ret;}if (n > 0) {rte_mov16((uint8_t *)dst - 16 + n, (const uint8_t *)src - 16 + n);}return ret;}/*** Make store aligned when copy size exceeds 512 bytes,* and make sure the first 15 bytes are copied, because* unaligned copy functions require up to 15 bytes* backwards access.*/dstofss = (uintptr_t)dst & 0x0F;if (dstofss > 0) {dstofss = 16 - dstofss + 16;n -= dstofss;rte_mov32((uint8_t *)dst, (const uint8_t *)src);src = (const uint8_t *)src + dstofss;dst = (uint8_t *)dst + dstofss;}srcofs = ((uintptr_t)src & 0x0F);/*** For aligned copy*/if (srcofs == 0) {/*** Copy 256-byte blocks*/for (; n >= 256; n -= 256) {rte_mov256((uint8_t *)dst, (const uint8_t *)src);dst = (uint8_t *)dst + 256;src = (const uint8_t *)src + 256;}/*** Copy whatever left*/goto COPY_BLOCK_255_BACK15;}/*** For copy with unaligned load*/MOVEUNALIGNED_LEFT47(dst, src, n, srcofs);/*** Copy whatever left*/goto COPY_BLOCK_64_BACK15;
}

更多相关的代码在rte_memcpy.h和rte_memcpy.c中，注意，它包含不同CPU架构平台的多个版本，不要搞混。
从上面的代码可以看到，影响拷贝速度的有以下几点：
1、字节对齐和数据的加载存储。
这个大家都明白，除了字节对齐速度加快外，而且DPDK中还对不同的字节对齐以及长度进行了控制，充分发挥SIMD的优势（说直白一点就是在条件允许的情况下，一次拷贝数量多【16字节：128位】，这个和平台支持有关）
2、函数和库调用开销，库函数需要调用过程，这个也浪费时间。这个库调用过程在编译选择优化的过程中，优化难度也比较大，不如在DPDK中直接调用，特别是使用
static __rte_always_inline（静态内联）时，这在网上有很多优化的比较，自己也可以试一试。
3、整体上来说，数据量越大，上面的优化越优势越大；否则优势则不明显。
上述的比较是针对库glibc以及DPDK相比而言的，至于个人优化过的则不在此范畴之内。另外，随着技术的进步，如果用高版本的glibc并开启优化后，可能效果差别也不大，这个没有进行比较。
有兴趣可以看看rte_mov256等几个函数。
需要说明的是，对于某一类函数，没有普遍最优之说。只有场景条件限制下的最合适。也就是说，DPDK的拷贝函数不代表此函数比glibc中的拷贝函数优秀，只是说明此函数在DPDK的应用场景下更合适。
最后总结一下，针对内存拷贝的优化点：
1、减少拷贝过程中的附加处理如字节对齐
2、在平台允许情况下使用最大带宽（拷贝最大数量）
3、使用平坦顺序内存并使用分支预测（减少分支跳转，如是否有范围重叠等）
4、有可能的情况下使用non-temporal访存执令
5、使用加速拷贝的一些指令（string操作指令等）。
6、处理大内存（M以上）和小内存（K以下）的不同场景（这个在一些常用框架中都会处理）

三、总结

性能和效率的提升，是一个系统工程。它可能会从一个点开始，然后不断的影响别的点，然后这些点又互相影响，最后蔓延到整个系统，形成一个量变到质变的过程。计算机应用也不外乎这样。
DPDK中通过Linux内核的一些设计（如大页），通过一种工程优化的手段来提高网络通信的效率，但反过来，内核也会借鉴DPDK的一些特点来吸收到内核中去。同样，DPDK的出现对硬件本身的设计也提出了虚拟化的相关等要求。硬件水平的提高又可以提高DPDK的性能。
国内的缺少的不是后面的一系列动作，缺少的恰恰是开始那个点，那个用于爆发的创新点。