DPDK LPM库组件为32位的key实现了最长前缀匹配(LPM)表查找方法,该方法通常用于在IP转发应用程序中找到最佳路由匹配。
LPM组件实例的主要配置参数是要支持的最大规则数。 LPM前缀由一对参数(32位Key,深度)表示,深度范围为1到32。LPM规则由LPM前缀和与该前缀关联的一些用户数据表示。 该前缀用作LPM规则的唯一标识符。 在此实现中,用户数据的长度为1字节,称为下一跳,与其在路由表条目中存储下一跳ID的主要用途相关。
LPM组件主要方法有:
当前实现使用DIR-24-8算法的一种变体,该算法以内存使用量为代价来提高LPM查找速度。 该算法允许执行查找操作,通常只需一次内存读访问。从统计上看,即便是不常出现的情况,当即最佳匹配规则的深度大于24时,查找操作也仅需要两次内存读访问。 因此,LPM查找操作的性能在很大程度上取决于特定内存位置是否存在于处理器高速cache中。
主要数据结构使用以下元素构建:
第一张表称为tbl24,使用要查找的IP地址的前24位进行索引,第二张表称为tbl8,使用IP地址的最后8位进行索引。这意味着,根据尝试将传入数据包的IP地址与tbl24中存储的规则进行匹配的结果,我们可能需要在第二级继续查找过程。
由于tbl24的每个条目都可能指向tbl8,因此理想情况下,我们将有2 ^ 24个tbl8,这与具有2 ^ 32个条目的单个表相同。 由于资源限制,这是不可行的。 相反,这种方法就是利用了超过24位的规则非常少的这一特定。通过将这个过程分为两个不同的表/级别并限制tbl8的数量,我们可以大大降低内存消耗,同时保持非常好的查找速度(大部分时间仅一个内存访问)。

tbl24中的条目包含以下字段:
第一个字段可以包含指示查找过程应该继续的tbl8的索引,或者如果已经找到最长的前缀匹配,则可以是下一跳本身。 这两个标志分别用于确定条目是否有效以及搜索过程是否已完成。 规则的深度或长度指的是存储在特定条目中的规则的位数。
tbl8中的条目包含以下字段:
下一跳和深度包含与tbl24中相同的信息。 这两个标志分别显示条目和表是否有效。
另一个主要数据结构是一个包含有关规则(IP和下一跳)的主要信息的表。 这是一个更高级别的表,用于不同的事物:
添加规则时,存在不同的可能性。 如果规则的深度恰好是24位,则:
如果规则的深度恰好是32位,则:
如果规则的深度为其他任何值,则必须执行前缀扩展。 这意味着将规则复制到所有条目(只要这些条目不被使用),这也会导致匹配。
学习地址: Dpdk/网络协议栈/vpp/OvS/DDos/NFV/虚拟化/高性能专家-学习视频教程-腾讯课堂
更多DPDK相关学习资料有需要的可以自行报名学习,免费订阅,久学习,或点击这里加qun免费
领取,关注我持续更新哦! !
举一个简单的例子,假设深度为20位。 这意味着将导致匹配的IP地址的前24位有2 ^(24-20)= 16个不同的组合。 因此,在这种情况下,我们将完全相同的条目复制到这些组合之一所索引的每个位置。
通过这样做,我们确保在查找过程中,如果存在与IP地址匹配的规则,则可以在一个或两次内存访问中找到该规则,具体取决于我们是否需要移至下一张表。 前缀扩展是该算法的关键之一,因为它可以通过添加冗余来极大地提高速度。
查找过程更加简单快捷:
规则数量受到诸多不同因素的限制。第一个是规则的最大数量,它是通过API传递的参数。一旦达到此数目,除非删除一个或多个规则,否则就无法在路由表中添加更多规则。
第二个原因是算法的固有局限性。如前所述,为避免高昂的内存消耗,编译时间限制了tbl8的数量(此值默认为256)。如果我们用尽了tbl8,我们将无法再添加任何规则。对于特定的路由表,需要多少个是很难预先确定的。
每当我们有一个深度大于24的新规则时,并且此规则的前24位与先前添加的规则的前24位不同,就会消耗tbl8。如果相同,那么新规则将与前一个规则共享相同的tbl8,因为这两个规则之间的唯一区别是在最后一个字节之内。
默认值为256情况下,我们最多可以有256个长度超过24位,且前三个字节都不同的规则。由于路由长度超过24位的不多,因此在大多数设置中这不是问题。即使是,也可以通过修改tbl8的数量来解决。
LPM算法用于实现实现IPv4转发的路由器使用的无类域间路由(CIDR)策略。