DPDK LPM庫(學習筆記)


1 LPM庫

DPDK LPM庫組件為32位的key實現了最長前綴匹配(LPM)表查找方法,該方法通常用於在IP轉發應用程序中找到最佳路由匹配。

2 LPM API概述

LPM組件實例的主要配置參數是要支持的最大規則數。 LPM前綴由一對參數(32位Key,深度)表示,深度范圍為1到32。LPM規則由LPM前綴和與該前綴關聯的一些用戶數據表示。 該前綴用作LPM規則的唯一標識符。 在此實現中,用戶數據的長度為1字節,稱為下一跳,與其在路由表條目中存儲下一跳ID的主要用途相關。

LPM組件主要方法有:

  • 添加LPM規則:LPM規則作為輸入參數。如果表中不存在具有相同前綴的規則,則新規則將添加到LPM表中。如果表中已經存在具有相同前綴的規則,則將更新該規則的下一跳。如果沒有可用的存儲空間,則會返回錯誤。
  • 刪除LPM規則:LPM規則的前綴作為輸入參數。如果LPM表中存在具有指定前綴的規則,則將其刪除。
  • 查找LPM規則:提供32位Key作為輸入。該算法用於選擇給定Key的最佳匹配的LPM規則,並返回該規則的下一跳。如果LPM表中存在多個具有相同32位Key的規則,則該算法將深度最大的規則選為最佳匹配規則,這意味着輸入Key和該規則Key之間具有最高有效位的匹配。

3 實現細節

當前實現使用DIR-24-8算法的一種變體,該算法以內存使用量為代價來提高LPM查找速度。 該算法允許執行查找操作,通常只需一次內存讀訪問。從統計上看,即便是不常出現的情況,當即最佳匹配規則的深度大於24時,查找操作也僅需要兩次內存讀訪問。 因此,LPM查找操作的性能在很大程度上取決於特定內存位置是否存在於處理器高速cache中。

主要數據結構使用以下元素構建:

  • 具有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的數量,我們可以大大降低內存消耗,同時保持非常好的查找速度(大部分時間僅一個內存訪問)。

clipboard

tbl24中的條目包含以下字段:

  • 下一跳,或指向tbl8的索引
  • 有效標志
  • 外部條目標志
  • 規則深度(長度)

第一個字段可以包含指示查找過程應該繼續的tbl8的索引,或者如果已經找到最長的前綴匹配,則可以是下一跳本身。 這兩個標志分別用於確定條目是否有效以及搜索過程是否已完成。 規則的深度或長度指的是存儲在特定條目中的規則的位數。

tbl8中的條目包含以下字段:

  • 下一跳
  • 有效標志
  • 有效組
  • 規則深度

下一跳和深度包含與tbl24中相同的信息。 這兩個標志分別顯示條目和表是否有效。

另一個主要數據結構是一個包含有關規則(IP和下一跳)的主要信息的表。 這是一個更高級別的表,用於不同的事物:

  • 在添加或刪除之前,無需實際執行查找即可檢查規則是否已經存在。
  • 刪除時,檢查是否存在包含要刪除的規則。 這很重要,因為主數據結構必須相應更新。

3.1 添加

添加規則時,存在不同的可能性。 如果規則的深度恰好是24位,則:

  • 使用規則(IP地址)作為tbl24的索引。
  • 如果條目無效(即它尚未包含規則),則更新下一跳的值,將有效標志設置為1(表示該條目正在使用),將外部條目標志設置為0(表示查找查找過程結束,因為這是匹配的最長前綴)。

如果規則的深度恰好是32位,則:

  • 使用規則的前24位作為tbl24的索引。
  • 如果該條目無效(即它尚未包含規則),則尋找一個空閑的tbl8,將tbl8的索引設置為此值,將有效標志設置為1(表示該條目正在使用),並將外部條目標志為1(意味着查找過程必須繼續,因為規則尚未被完全探測)。

如果規則的深度為其他任何值,則必須執行前綴擴展。 這意味着將規則復制到所有條目(只要這些條目不被使用),這也會導致匹配。

舉一個簡單的例子,假設深度為20位。 這意味着將導致匹配的IP地址的前24位有2 ^(24-20)= 16個不同的組合。 因此,在這種情況下,我們將完全相同的條目復制到這些組合之一所索引的每個位置。

通過這樣做,我們確保在查找過程中,如果存在與IP地址匹配的規則,則可以在一個或兩次內存訪問中找到該規則,具體取決於我們是否需要移至下一張表。 前綴擴展是該算法的關鍵之一,因為它可以通過添加冗余來極大地提高速度。

3.2 查找

查找過程更加簡單快捷:

  • 使用IP地址的前24位作為tbl24的索引。 如果該條目未使用,則表明我們沒有與此IP匹配的規則。 如果有效且外部入口標志設置為0,則返回下一跳。
  • 如果有效且外部入口標志設置為1,則我們使用tbl8索引查找要檢查的tbl8,並將IP地址的最后8位用作此表的索引。 同樣,如果該條目未使用,則我們沒有與此IP地址匹配的規則。 如果有效,則返回下一跳。

3.3 規則數限制

規則數量受到諸多不同因素的限制。第一個是規則的最大數量,它是通過API傳遞的參數。一旦達到此數目,除非刪除一個或多個規則,否則就無法在路由表中添加更多規則。

第二個原因是算法的固有局限性。如前所述,為避免高昂的內存消耗,編譯時間限制了tbl8的數量(此值默認為256)。如果我們用盡了tbl8,我們將無法再添加任何規則。對於特定的路由表,需要多少個是很難預先確定的。

每當我們有一個深度大於24的新規則時,並且此規則的前24位與先前添加的規則的前24位不同,就會消耗tbl8。如果相同,那么新規則將與前一個規則共享相同的tbl8,因為這兩個規則之間的唯一區別是在最后一個字節之內。

默認值為256情況下,我們最多可以有256個長度超過24位,且前三個字節都不同的規則。由於路由長度超過24位的不多,因此在大多數設置中這不是問題。即使是,也可以通過修改tbl8的數量來解決。

3.4 用例:IPv4轉發

LPM算法用於實現實現IPv4轉發的路由器使用的無類域間路由(CIDR)策略。

3.5 References


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM