官方文檔查看地址：
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