官方文档查看地址：
http://doc.dpdk.org/guides/prog_guide/lpm_lib.html
PDF下载地址：
https://www.intel.com/content/www/us/en/embedded/technology/packet-processing/dpdk/dpdk-programmers-guide.html
本篇难度系数：
翻译：☆☆☆☆☆
理解：★★☆☆☆
24.LPM库
DPDK LPM库组件为32位键实现最长前缀匹配(LPM：Longest Prefix Match)表搜索方法，通常用于在IP转发应用程序中查找最佳路由匹配。
24.1LPM API概述
LPM组件实例的主要配置参数是要支持的规则的最大数量。LPM前缀由一对参数(32位键，depth)表示，depth的范围在1到32之间。LPM规则由一个LPM前缀和一些与该前缀关联的用户数据表示。前缀作为LPM规则的唯一标识符。在此实现中，用户数据为1字节长，称为next hop，这与它主要用于将下一跳的ID存储在路由表条目中有关。
LPM组件导出的主要方法有:
- 添加LPM规则:提供LPM规则作为输入。如果表中没有具有相同前缀的规则，则将新规则添加到LPM表中。如果表中已经存在具有相同前缀的规则，则更新规则的下一跳。当没有可用的规则空间时，返回一个错误。
- 删除LPM规则:提供LPM规则的前缀作为输入。如果LPM表中存在具有指定前缀的规则，则删除该规则。
- 查找LPM键:提供32位键作为输入。算法选择表示给定键的最佳匹配的规则，并返回该规则的下一跳。如果有多个规则行分钟表中有相同的32位键,最高的算法选择规则的深度是最佳匹配规则,这意味着规则最多的最重要的比特之间的匹配输入键和键。
24.2实现细节
当前的实现使用DIR-24-8算法的变体，该算法使用内存来提高LPM查找速度。该算法允许使用通常一个内存读访问来执行查找操作。在统计上罕见的情况下，当最佳匹配规则的深度大于24时，查找操作需要两次内存读取访问。因此，LPM查找操作的性能受处理器缓存中是否存在特定内存位置的影响很大。
主要数据结构是使用以下元素构建的:
- 一个包含
2^24项的表。 - 具有
2^8项的许多表(RTE_LPM_TBL8_NUM_GROUPS)。
第一个表(称为tbl24)使用要查找的IP地址的前24位进行索引，而第二个表(称为tbl8)使用IP地址的后8位进行索引。这意味着，根据试图将传入包的IP地址与存储在tbl24中的规则匹配的结果，我们可能需要在第二层继续查找过程。
因为tbl24的每一项都可能指向一个tbl8，理想情况下，我们将有2^24个tbl8，这与拥有一个包含2^32项的表是一样的。由于资源限制，这是不可行的。相反，这种方法利用了规则长度很少超过24位的事实。通过将进程划分为两个不同的表/级别，并限制tbl8的数量，我们可以在保持非常好的查找速度的同时大大减少内存消耗(大多数情况下是一次内存访问)。
Fig. 24.1 Table split into different levels
tbl24中的条目包含以下字段:
- tbl8的下一跳(next hop)/索引
- 有效的标志
- 外部入口标志
- 规则深度(长度)
第一个字段可以包含一个数字，指示应该继续执行查找过程的tbl8，也可以包含下一跳本身(如果已经找到最长的前缀匹配)。这两个标志分别用于确定条目是否有效以及搜索过程是否已经完成。规则的深度或长度是存储在特定条目中的规则位的数量。
tbl8中的条目包含以下字段:
- 下一跳
- 有效
- 有效的组
- 深度
Next hop和depth包含与tbl24中相同的信息。这两个标志分别显示条目和表是否有效。
另一个主要数据结构是一个表，其中包含关于规则(IP和next hop)的主要信息。这是一个更高层次的表，用于不同的事情:
- 在添加或删除规则之前，检查规则是否已经存在，而不必实际执行查找。
- 删除时，检查是否有包含要删除的规则。这很重要，因为必须相应地更新主数据结构。
24.2.1添加
当添加规则时，有不同的可能性。如果规则的深度正好是24位，则:
- 使用规则(IP地址)作为tbl24的索引。
- 如果条目是无效的(即它不已经包含规则)然后设置它的下一个跃点它的价值,有效的标志为1(即该条目在使用),和外部条目标记为0(即查找过程结束在这一点上,因为这是最长前缀匹配)。
如果规则的深度正好是32位，则:
- 使用规则的前24位作为tbl24的索引。
- 如果条目是无效的(即它不已经包含规则)然后寻找免费tbl8设置索引tbl8这个值,有效的标志为1(即该条目使用),和外部条目标记为1(即查找过程必须继续自规则尚未完全探索)。
如果规则的深度是任何其他值，则必须执行前缀展开。这意味着将规则复制到所有条目(只要它们没有被使用)，这也会导致匹配。
作为一个简单的例子，我们假设深度是20位。这意味着有2^(24 - 20)= 16个IP地址的前24位的不同组合将导致匹配。因此，在本例中，我们将完全相同的条目复制到由这些组合之一索引的每个位置。
通过这样做，我们可以确保在查找过程中，如果存在匹配IP地址的规则，则可以在一次或两次内存访问中找到它，这取决于是否需要移动到下一个表。前缀扩展是该算法的关键之一，它通过增加冗余大大提高了速度。
24.2.2查找
查找过程更简单、更快。在这种情况下:
- 使用IP地址的前24位作为tbl24的索引。如果条目没有使用，则意味着没有匹配此IP的规则。如果它是有效的，并且外部条目标志被设置为0，那么将返回下一跳。
- 如果它是有效的，并且外部条目标志被设置为1，那么我们使用tbl8索引来找出要检查的tbl8，并将IP地址的最后8位作为这个表的索引。类似地，如果条目没有使用，则没有匹配此IP地址的规则。如果它是有效的，则返回下一跳。
24.2.3规则数量的限制
有一些不同的东西限制了可以添加的规则的数量。第一个是规则的最大数量，这是通过API传递的一个参数。一旦达到这个数字，就不可能向路由表添加更多的规则，除非删除一个或多个规则。
第二个原因是算法本身的局限性。如前所述，为了避免高内存消耗，编译时间限制了tbl8的数量(默认值为256)。如果我们耗尽了tbl8，我们将无法添加更多的规则。对于特定的路由表，需要多少个路由表很难预先确定。
当我们有一个深度大于24的新规则时，就会使用tbl8，并且这个规则的前24位与先前添加的规则的前24位不同。如果是，那么新规则将与前一个规则共享相同的tbl8，因为这两个规则之间惟一的区别是在最后一个字节内。
在默认值为256的情况下，最多可以有256条规则比前三个字节的24位长。由于路由长度不太可能超过24位，所以在大多数设置中这不应该是一个问题。然而，即使是这样，也可以修改tbl8的数量。
24.2.4用例:IPv4转发
LPM算法用于实现IPv4转发路由器使用的无类域间路由(CIDR)策略。
24.2.5参考
-
RFC1519分类间路由(CIDR){Classless Inter-Domain Routing (CIDR)}::地址分配和聚合战略，http://www.ietf.org/rfc/rfc1519
-
斯坦福大学，2000年(http://klamath.stanford.edu/~pankaj/thesis/ thesis_1sided.pdf)
-
DPDK IPV4 LPM(路由表实现)详解https://blog.csdn.net/tekjin/article/details/78466311