DPDK-ELASTIC FLOW DISTRIBUTOR LIBRARY（灵活的流分发库）

0x01 缘由

     好的流表设计，在大量网络产品中是一个相当重要的环节，如dpi产品、取证产品、内容审计产品等。

0x02 简介

     1.介绍

      在数据中心的当代，集群和工作负载的调度是一个非常普遍的任务。许多工作负载在集群中需要有一个确切的分区key空间。当一个包进入集群，在进入节点直接将数据包分发的处理节点。例如，具有分解存储的数据中心使用存储元数据将I/O请求转发到正确的后端存储集群的中，有状态的数据包检查将匹配流表中标签来发送进入的数据包到其预期的深度数据包检测（DPI）设备，等等其他。

     EFD是为每条流key使用完美hash生成一个目标或值的分发库。它具有以下优点：首先，因为它使用完美的散列，它不存储密钥本身，因此查找性能不依赖于密钥大小。其次，目标/值可以是任意值，因此系统设计者和/或 运营商可以更好地优化服务速率和群集间网络流量定位。 第三，由于存储要求远小于基于散列的流表（即更适合于CPU缓存），所以EFD可以扩展到数百万个流密钥。 最后，利用当前优化的库实现，性能完全可扩展，任意数量的CPU内核。

     2.基于流的分发

     2.1基于计算的方案

     流量分发和/或负载均衡可以简单地使用无状态计算完成，例如使用轮询调度或基于流key作为输入的简单计算。例如，可以使用散列函数来基于流key（例如h（key）mod n）将特定流引导到目标，其中h（key）是流key的哈希值，并且n是可能的目标。              在该方案（图13.1）中，前端服务器/分发/负载平衡器从输入包中提取流key（如五元组），并应用计算来确定该流应该向哪里引导。 直观地说，这个方案非常简单，不需要在前端节点保持状态，因此存储要求是最小的。

     

     一个使用更广泛的基于计算的分类方法是一致性hash算法。http://blog.csdn.net/cywosp/article/details/23397179

     

     2.2 基于流表的方案

     当使用基于流表的方案来处理流量分配/负载均衡时，与基于计算的方案相反，系统设计人员可以灵活地将给定的流量分配给任何给定的目标。流表（例如DPDK RTE哈希库）将简单地存储流Key和目标值。

     如上图，当用流key生成的hash值去查找基于流表的索引时，这个存储在流表中的索引值与keys值一致是将返回。获取的keys值和输入的流key匹配，如果有匹配，则目标值返回。

     用hash表做流分发和负载均衡的缺点是需要大量的存储空间需求，即流表需要存储keys\标记\目标值。这个方案不允许百万个key值的规模。大的表通畅不适合CPU缓存，因此，因为访问主存的延迟导致查找性能下降。

     2.3 EFD存储方案

     EFD结合了流表和实时计算的优点。它不需要大的存储想基于流表一样，而且他支持keys以任何值给出。EFD的基本思想是当插入给定的key时，搜索一系列哈希函数，直到找到将输入key映射到正确值的正确哈希函数，如图所示。 然而，EFD不仅显式地存储所有key及其关联的值，而是仅存储将key映射到值的散列函数的索引，从而消耗比传统的基于流的表少得多的空间。 查找操作非常简单，类似于基于计算的方案：给定输入键，查找操作被减少为具有正确哈希函数的哈希散列。

     

     直观地，找到将大量（百万）输入键的每一个映射到正确的输出值的散列函数是不可能的，因此，如图13.5所示，EFD将问题分解成较小的部分（划分和征服））。 EFD将整个输入键集合分成许多小组。 每个组由约20-28个键（库的可配置参数）组成，然后，对于每个小组，进行强力搜索以找到为组中的每个键产生正确输出的散列函数。

     应该提到的是，由于EFD的在线查找表不存储key本身，因此EFD表的大小与key大小无关，因此EFD查找性能几乎不变，与key的长度无关 是一个非常需要的功能，特别是对于较长的key.

     总而言之，EFD是一种设置的分离数据结构，支持数百万个key。 它用于将给定的key分发到预期的目标。 本身EFD不是与输入流key完全匹配的FIB数据结构。

0x03 使用

     使用EFD作为流级负载平衡器的示例其中在前端服务器处接收到流，然后转发到目标后端服务器进行处理。系统设计人员将确定性地将流程共同定位，以最小化跨服务器交互。 （例如，请求某些网页对象的流程共同位于一起，以最小化跨服务器的公共对象的转发）。

     

0x04 总结

     利用好dpdk的相关数据结构，构建高性能网络处理设备和系统。