REORDER LIBRARY

重排序庫提供了根據(jù)其序列號對mbuf進(jìn)行重排序的機(jī)制。

16.1 操作

重排序庫本質(zhì)上是一個對mbuf進(jìn)行重新排序的緩沖區(qū)。用戶將亂序的mbuf插入重排序緩沖區(qū)，并從中提取順序正確的mbuf。
在任何給定時刻，重排序緩沖區(qū)包含其序列號位于序列窗口內(nèi)的mbuf。序列窗口由最小序列號和緩沖區(qū)配置為保存的條目數(shù)確定。例如，給定一個具有200個條目和最小序列號為350的重排序緩沖區(qū)，序列窗口的低限和高限分別為350和550。
在插入mbuf時，重排序庫根據(jù)插入mbuf的序列號區(qū)分有效、晚到和早到的mbuf：

• 有效：序列號在窗口內(nèi)。
• 晚到：序列號超出窗口且小于低限。
• 早到：序列號超出窗口且大于高限。
  重排序緩沖區(qū)直接返回晚到的mbuf，并嘗試容納早到的mbuf。

16.2 實現(xiàn)細(xì)節(jié)

重排序庫實現(xiàn)為一對緩沖區(qū)，分別稱為Order緩沖區(qū)和Ready緩沖區(qū)。
在插入調(diào)用時，有效的mbuf直接插入Order緩沖區(qū)，而晚到的mbuf則以錯誤的形式返回給用戶。
對于早到的mbuf，重排序緩沖區(qū)將嘗試移動窗口（遞增最小序列號），使mbuf變?yōu)橛行?。為?#xff0c;將Order緩沖區(qū)中的mbuf移動到Ready緩沖區(qū)。尚未到達(dá)的mbuf將被忽略，因此將成為晚到的mbuf。這意味著只要Ready緩沖區(qū)有空間，窗口就會移動以容納本應(yīng)在重排序窗口外的早到mbuf。
例如，假設(shè)我們有一個包含200個條目、最小序列號為350的緩沖區(qū)，并且我們需要插入序列號為565的早到mbuf。這意味著我們需要至少移動窗口15個位置來容納該mbuf。重排序緩沖區(qū)會嘗試從Order緩沖區(qū)的至少接下來的15個插槽中移動mbuf到Ready緩沖區(qū)，只要Ready緩沖區(qū)有空間。在此時，Order緩沖區(qū)中的任何間隙都將被跳過，并且這些數(shù)據(jù)包在到達(dá)時將被報告為晚到的數(shù)據(jù)包。將數(shù)據(jù)包移動到Ready緩沖區(qū)的過程會持續(xù)超過最小要求，直到在Order緩沖區(qū)中遇到間隙（即丟失的mbuf）為止。
在排空mbuf時，重排序緩沖區(qū)首先從Ready緩沖區(qū)返回mbuf，然后從Order緩沖區(qū)返回，直到找到間隙（尚未到達(dá)的mbuf）為止。

16.3 Use Case: Packet Distributor

使用DPDK數(shù)據(jù)包分發(fā)器的應(yīng)用程序可以利用重排序庫以按接收順序傳輸數(shù)據(jù)包。
一個基本的數(shù)據(jù)包分發(fā)器用例包括具有多個工作核心的分發(fā)器。工作核心對數(shù)據(jù)包的處理不能保證順序，因此可以使用重排序緩沖區(qū)對盡可能多的數(shù)據(jù)包進(jìn)行排序。
在這種情況下，分發(fā)器在將數(shù)據(jù)包傳遞給工作核心之前為mbuf分配序列號。隨著工作核心完成處理數(shù)據(jù)包，分發(fā)器將這些mbuf插入重排序緩沖區(qū)，最后傳輸排空的mbuf。
注意：當(dāng)前的重排序緩沖區(qū)不是線程安全的，因此同一個線程負(fù)責(zé)插入和排空mbuf。

IP FRAGMENTATION AND REASSEMBLY LIBRARY

IP Fragmentation and Reassembly Library實現(xiàn)了IPv4和IPv6數(shù)據(jù)包的分片和重組。

17.1 數(shù)據(jù)包分片

數(shù)據(jù)包分片例程將輸入數(shù)據(jù)包分成多個片段。rte_ipv4_fragment_packet()和rte_ipv6_fragment_packet()函數(shù)假設(shè)輸入的mbuf數(shù)據(jù)指向數(shù)據(jù)包的IP頭的起始位置（即L2頭已經(jīng)被剝離）。為避免對實際數(shù)據(jù)包數(shù)據(jù)進(jìn)行復(fù)制，使用了零拷貝技術(shù)（rte_pktmbuf_attach）。
對于每個片段，創(chuàng)建了兩個新的mbuf：

• 直接mbuf：將包含新片段的L3頭。
• 間接mbuf：附加到具有原始數(shù)據(jù)包的mbuf上。它的數(shù)據(jù)字段指向原始數(shù)據(jù)包數(shù)據(jù)的起始位置加上片段偏移量。
  然后，將原始mbuf中的L3頭復(fù)制到“直接”mbuf中，并更新以反映新的分片狀態(tài)。注意，對于IPv4，不會重新計算頭部校驗和，而是設(shè)置為零。
  最后，通過mbuf的next字段將每個片段的“直接”和“間接”mbuf鏈接在一起，以組成新片段的數(shù)據(jù)包。
  調(diào)用者可以顯式指定應(yīng)從中分配“直接”和“間接”mbuf的內(nèi)存池。
  有關(guān)直接和間接mbuf的更多信息，請參閱DPDK程序員指南7.7 Direct and Indirect Buffers。

17.2 數(shù)據(jù)包重組

17.2.1 IP分片表

分片表維護(hù)關(guān)于已接收到數(shù)據(jù)包片段的信息。
每個IP數(shù)據(jù)包由三元組 <源IP地址>、<目標(biāo)IP地址>、 唯一標(biāo)識。
需要注意的是，對分片表的所有更新/查找操作都不是線程安全的。因此，如果不同的執(zhí)行上下文（線程/進(jìn)程）同時訪問相同的表，則必須提供某種外部同步機(jī)制。
每個表條目可以包含最多 RTE_LIBRTE_IP_FRAG_MAX（默認(rèn)值為4）個片段的信息。
示例代碼演示了如何創(chuàng)建一個新的分片表：

frag_cycles = (rte_get_tsc_hz() + MS_PER_S - 1) / MS_PER_S * max_flow_ttl;
bucket_num = max_flow_num + max_flow_num / 4;
frag_tbl = rte_ip_frag_table_create(max_flow_num, bucket_entries,
max_flow_num, frag_cycles, socket_id);

內(nèi)部分片表是一個簡單的哈希表。基本思想是使用兩個哈希函數(shù)和 <bucket_entries> * 關(guān)聯(lián)性。這為每個鍵提供了 2 * <bucket_entries> 個可能的位置。當(dāng)發(fā)生沖突并且所有 2 * <bucket_entries> 位置都被占用時，ip_frag_tbl_add() 不會重新插入現(xiàn)有鍵到備用位置，而只是返回失敗。
此外，駐留在表中時間超過 <max_cycles> 的條目被視為無效，并且可以被新條目刪除/替換。
需要注意的是，重組需要大量的mbuf進(jìn)行分配。在任何給定時間內(nèi)，最多可以在分片表中存儲 (2 * bucket_entries * RTE_LIBRTE_IP_FRAG_MAX * <每個數(shù)據(jù)包的最大mbuf數(shù)>) 個片段等待其余片段的到來。

17.2.2 數(shù)據(jù)包重組

分片數(shù)據(jù)包的處理和重組由rte_ipv4_frag_reassemble_packet() / rte_ipv6_frag_reassemble_packet()函數(shù)完成。這些函數(shù)要么返回包含重組數(shù)據(jù)包的有效mbuf指針，要么返回NULL（如果由于某種原因無法重組數(shù)據(jù)包）。

這些函數(shù)負(fù)責(zé)：

1. 在分片表中查找具有數(shù)據(jù)包的<IPv4源地址，IPv4目標(biāo)地址，數(shù)據(jù)包ID>的條目。
2. 如果找到條目，則檢查該條目是否已超時。如果是，則釋放所有先前接收到的片段，并從條目中刪除與它們相關(guān)的信息。
3. 如果沒有找到具有此鍵的條目，則嘗試通過以下兩種方式之一創(chuàng)建新條目：
   (a) 使用空條目。
   (b) 刪除超時條目，釋放與其關(guān)聯(lián)的mbuf，并在其中存儲具有指定鍵的新條目。
4. 更新條目以包含新的片段信息，并檢查是否可以重新組裝數(shù)據(jù)包（數(shù)據(jù)包的條目包含所有片段）。
   (a) 如果可以，那么重新組裝數(shù)據(jù)包，將表的條目標(biāo)記為空，并將重組的mbuf返回給調(diào)用者。
   (b) 如果不能，則向調(diào)用者返回NULL。

如果在數(shù)據(jù)包處理的任何階段遇到錯誤（例如：無法將新條目插入分片表，或者無效/超時的片段），則函數(shù)將釋放與數(shù)據(jù)包關(guān)聯(lián)的所有片段，將表條目標(biāo)記為無效，并向調(diào)用者返回NULL。

17.2.3 調(diào)試日志記錄和統(tǒng)計收集

RTE_LIBRTE_IP_FRAG_TBL_STAT配置宏控制分片表的統(tǒng)計收集。默認(rèn)情況下，此宏未啟用。
RTE_LIBRTE_IP_FRAG_DEBUG控制IP片段處理和重組的調(diào)試日志記錄。默認(rèn)情況下，此宏已禁用。需要注意的是，盡管日志包含大量詳細(xì)信息，但它會減慢數(shù)據(jù)包處理速度，并可能導(dǎo)致大量數(shù)據(jù)包丟失。

MULTI-PROCESS SUPPORT

在DPDK中，多進(jìn)程支持旨在允許一組DPDK進(jìn)程在Intel?架構(gòu)硬件上以簡單透明的方式共同執(zhí)行數(shù)據(jù)包處理或其他工作負(fù)載。為支持此功能，對核心DPDK環(huán)境抽象層（EAL）進(jìn)行了一些增加。

EAL已被修改以允許生成不同類型的DPDK進(jìn)程，每個進(jìn)程對應(yīng)用程序使用的hugepage內(nèi)存具有不同的權(quán)限。目前有兩種指定的進(jìn)程類型：

• 主進(jìn)程：可以初始化并具有對共享內(nèi)存的全部權(quán)限。
• 次要進(jìn)程：無法初始化共享內(nèi)存，但可以附加到預(yù)先初始化的共享內(nèi)存并在其中創(chuàng)建對象。

獨立的DPDK進(jìn)程是主進(jìn)程，而次要進(jìn)程只能在主進(jìn)程旁邊運行或在主進(jìn)程已為其配置了hugepage共享內(nèi)存后運行。

為支持這兩種進(jìn)程類型和后續(xù)描述的其他多進(jìn)程設(shè)置，EAL提供了兩個額外的命令行參數(shù)：

• –proc-type：用于指定給定進(jìn)程實例為主要或次要DPDK實例。
• –file-prefix：允許不想合作的進(jìn)程具有不同的內(nèi)存區(qū)域。

提供了許多示例應(yīng)用程序，演示了如何一起使用多個DPDK進(jìn)程。這些在“DPDK示例應(yīng)用程序用戶指南”的“多進(jìn)程示例應(yīng)用程序”章節(jié)中有更詳細(xì)的文檔記錄。

18.1 內(nèi)存共享

使用DPDK創(chuàng)建多進(jìn)程應(yīng)用程序的關(guān)鍵要素是確保內(nèi)存資源在構(gòu)成多進(jìn)程應(yīng)用程序的各個進(jìn)程之間得到正確共享。一旦有多個進(jìn)程可以訪問的共享內(nèi)存塊，那么諸如進(jìn)程間通信（IPC）之類的問題就變得簡單得多。

在主要或獨立進(jìn)程的應(yīng)用程序啟動時，DPDK將內(nèi)存配置的詳細(xì)信息記錄到內(nèi)存映射文件中 - 使用的hugepages，它們映射的虛擬地址，存在的內(nèi)存通道數(shù)等。當(dāng)啟動次要進(jìn)程時，會讀取這些文件，EAL會在次要進(jìn)程中重新創(chuàng)建相同的內(nèi)存配置，以便所有內(nèi)存區(qū)域在進(jìn)程之間共享，并且所有對該內(nèi)存的指針在兩個進(jìn)程中都是有效的，并且指向相同的對象。

注意：有關(guān)Linux內(nèi)核地址空間布局隨機(jī)化（ASLR）如何影響內(nèi)存共享的詳細(xì)信息，請參閱多進(jìn)程限制部分。

Figure 18.1: Memory Sharing in the DPDK Multi-process Sample Application
EAL還支持自動檢測模式（通過EAL的 --proc-type=auto 標(biāo)志設(shè)置），如果已經(jīng)運行了主要實例，則會啟動一個DPDK進(jìn)程作為次要實例。

18.2 部署模型

18.2.1 對稱/對等進(jìn)程

DPDK多進(jìn)程支持可用于創(chuàng)建一組對等進(jìn)程，其中每個進(jìn)程執(zhí)行相同的工作負(fù)載。該模型相當(dāng)于具有多個線程，每個線程都運行相同的主循環(huán)功能，這是大多數(shù)提供的DPDK示例應(yīng)用程序所做的。在此模型中，首個生成的進(jìn)程應(yīng)使用 --proc-type=primary EAL標(biāo)志生成，而所有后續(xù)實例應(yīng)使用 --proc-type=secondary 標(biāo)志生成。

simple_mp 和 symmetric_mp 示例應(yīng)用程序展示了這種用法模型。它們在“DPDK示例應(yīng)用程序用戶指南”的“多進(jìn)程示例應(yīng)用程序”章節(jié)中有描述。

18.2.2 非對稱/非對等進(jìn)程

多進(jìn)程應(yīng)用程序的另一種可用部署模型是擁有一個充當(dāng)負(fù)載均衡器或服務(wù)器的單個主進(jìn)程實例，將接收到的數(shù)據(jù)包分發(fā)給作為次要進(jìn)程運行的工作線程或客戶端線程。在這種情況下，廣泛使用了位于共享hugepage內(nèi)存中的rte_ring對象。

client_server_mp 示例應(yīng)用程序展示了這種用法模型。它在“DPDK示例應(yīng)用程序用戶指南”的“多進(jìn)程示例應(yīng)用程序”章節(jié)中有描述。

18.2.3 運行多個獨立的DPDK應(yīng)用程序

除了涉及多個DPDK進(jìn)程共同工作的上述情景之外，還可以在旁邊運行多個獨立的DPDK進(jìn)程，這些進(jìn)程都在獨立工作。支持此使用場景的方法是使用EAL的 --file-prefix 參數(shù)。

默認(rèn)情況下，EAL在每個hugetlbfs文件系統(tǒng)上創(chuàng)建hugepage文件，文件名為rtemap_X，其中X的范圍是從0到最大hugepages - 1。類似地，當(dāng)以root用戶運行時（或以非root用戶運行時，如果文件系統(tǒng)和設(shè)備權(quán)限設(shè)置允許的話），它會創(chuàng)建共享配置文件，每個進(jìn)程中都有內(nèi)存映射，文件名為/var/run/.rte_config，文件名中的rte部分可以使用file-prefix參數(shù)進(jìn)行配置。

除了指定file-prefix參數(shù)之外，任何要并行運行的DPDK應(yīng)用程序都必須明確限制其內(nèi)存使用。這通過向每個進(jìn)程傳遞 -m 標(biāo)志來實現(xiàn)，以指定每個進(jìn)程可以使用多少兆字節(jié)的hugepage內(nèi)存（或傳遞 --socket-mem 以指定每個進(jìn)程在每個插槽上可以使用多少hugepage內(nèi)存）。

注意：在單個機(jī)器上并行運行的獨立DPDK實例不能共享任何網(wǎng)絡(luò)端口。任何一個進(jìn)程使用的網(wǎng)絡(luò)端口應(yīng)在其他每個進(jìn)程中列入黑名單。

18.2.4 運行多個獨立DPDK應(yīng)用程序組

與在單個系統(tǒng)上并行運行獨立的DPDK應(yīng)用程序類似，這可以輕松地擴(kuò)展到并行運行多個DPDK應(yīng)用程序組。在這種情況下，次要進(jìn)程必須使用與其連接到的主要進(jìn)程相同的 --file-prefix 參數(shù)。

注意：在此使用場景中，所有與并行運行的多個獨立DPDK進(jìn)程相關(guān)的限制和問題也適用。

18.3 多進(jìn)程的限制

在運行DPDK多進(jìn)程應(yīng)用程序時存在一些限制。以下是其中一些已記錄的限制：

• 多進(jìn)程功能要求所有應(yīng)用程序中都存在完全相同的hugepage內(nèi)存映射。Linux安全功能 - 地址空間布局隨機(jī)化（ASLR）可能會干擾此映射，因此可能需要禁用此功能才能可靠地運行多進(jìn)程應(yīng)用程序。
  警告：禁用地址空間布局隨機(jī)化（ASLR）可能會帶來安全問題，因此建議僅在絕對必要時和在理解了此更改的影響后才禁用。

• 所有作為單個應(yīng)用程序運行并使用共享內(nèi)存的DPDK進(jìn)程必須具有不同的coremask參數(shù)。不可能有一個主要實例和次要實例，或者兩個次要實例，使用相同的邏輯核心。試圖這樣做可能會導(dǎo)致內(nèi)存池緩存的損壞，等其他問題。

• 在次要進(jìn)程中，例如以太網(wǎng)設(shè)備鏈接狀態(tài)中斷等中斷的傳遞不起作用。所有中斷僅在主進(jìn)程內(nèi)觸發(fā)。
  任何需要在多個進(jìn)程中進(jìn)行中斷通知的應(yīng)用程序都應(yīng)提供自己的機(jī)制，將中斷信息從主進(jìn)程傳輸?shù)叫枰撔畔⒌娜魏未我M(jìn)程。

• 在基于不同編譯的二進(jìn)制文件的多個進(jìn)程之間使用函數(shù)指針是不受支持的，因為給定函數(shù)在一個進(jìn)程中的位置可能與其在第二個進(jìn)程中的位置不同。這會阻止librte_hash庫的正常行為，因為它在內(nèi)部使用指向哈希函數(shù)的指針，類似于多線程實例。
  為解決此問題，建議多進(jìn)程應(yīng)用程序通過直接從代碼中調(diào)用哈希函數(shù)進(jìn)行哈希計算，然后使用rte_hash_add_with_hash()/rte_hash_lookup_with_hash()函數(shù)，而不是使用內(nèi)部執(zhí)行哈希計算的函數(shù)，如rte_hash_add()/rte_hash_lookup()。

• 根據(jù)正在使用的硬件和使用的DPDK進(jìn)程數(shù)量，可能無法在每個DPDK實例中使用HPET定時器。Linux*用戶空間可用的最小HPET比較器數(shù)量可能只有一個比較器，這意味著只有第一個主要DPDK進(jìn)程實例可以打開并mmap /dev/hpet。如果所需的DPDK進(jìn)程數(shù)量超過可用HPET比較器的數(shù)量，則必須在所有進(jìn)程中使用TSC（在此版本中是默認(rèn)定時器）作為時間源，而不是使用HPET。

DPDK內(nèi)核NIC接口

DPDK（Data Plane Development Kit）內(nèi)核NIC接口（KNI）允許用戶空間應(yīng)用程序訪問Linux*控制平面。

使用DPDK KNI的好處有：

• 比現(xiàn)有的Linux TUN/TAP接口更快（通過消除系統(tǒng)調(diào)用和copy_to_user()/copy_from_user()操作）。
• 允許使用標(biāo)準(zhǔn)的Linux網(wǎng)絡(luò)工具（如ethtool、ifconfig和tcpdump）管理DPDK端口。
• 允許與內(nèi)核網(wǎng)絡(luò)堆棧進(jìn)行接口。

使用DPDK內(nèi)核NIC接口的應(yīng)用程序組件如圖19.1所示。

19.1 DPDK KNI內(nèi)核模塊

KNI內(nèi)核可加載模塊支持兩種類型的設(shè)備：

• 雜項設(shè)備（/dev/kni）：
  • 通過ioctl調(diào)用創(chuàng)建網(wǎng)絡(luò)設(shè)備。
  • 維護(hù)所有KNI實例共享的內(nèi)核線程上下文（模擬網(wǎng)絡(luò)驅(qū)動程序的RX端）。
  • 對于單個內(nèi)核線程模式，維護(hù)所有KNI實例共享的內(nèi)核線程上下文（模擬網(wǎng)絡(luò)驅(qū)動程序的RX端）。
  • 對于多個內(nèi)核線程模式，為每個KNI實例維護(hù)內(nèi)核線程上下文（模擬新驅(qū)動程序的RX端）。
• 網(wǎng)絡(luò)設(shè)備：
  • 通過實現(xiàn)多個操作（如netdev_ops、header_ops、ethtool_ops），提供網(wǎng)絡(luò)功能，這些操作由struct net_device定義，包括對DPDK mbufs和FIFOs的支持。
  • 接口名稱由用戶空間提供。
  • MAC地址可以是真實的NIC MAC地址或隨機(jī)生成的。
    
    Figure 19.1: Components of a DPDK KNI Application

19.2 KNI創(chuàng)建和刪除

KNI接口由DPDK應(yīng)用程序動態(tài)創(chuàng)建。接口名稱和FIFO詳細(xì)信息由應(yīng)用程序通過使用rte_kni_device_info結(jié)構(gòu)的ioctl調(diào)用提供，其中包含：

• 接口名稱。
• 相關(guān)FIFO的對應(yīng)memzones的物理地址。
• Mbuf內(nèi)存池的詳細(xì)信息，包括物理和虛擬地址（用于計算mbuf指針的偏移量）。
• PCI信息。
• 核心親和性。
  請參閱DPDK源代碼中的rte_kni_common.h以獲取更多詳細(xì)信息。
  這些物理地址將重新映射到內(nèi)核地址空間，并存儲在單獨的KNI上下文中。
  一旦創(chuàng)建了KNI接口，可以通過調(diào)用rte_kni_info_get()函數(shù)查詢KNI上下文信息。
  KNI接口可以在創(chuàng)建后由DPDK應(yīng)用程序動態(tài)刪除。
  此外，所有未被刪除的KNI接口將在雜項設(shè)備的釋放操作中被刪除（當(dāng)關(guān)閉DPDK應(yīng)用程序時）。

19.3 DPDK mbuf流程

為了最小化在內(nèi)核空間運行的DPDK代碼量，mbuf內(nèi)存池僅由用戶空間管理。內(nèi)核模塊將了解mbuf，但所有的mbuf分配和釋放操作將僅由DPDK應(yīng)用程序處理。圖19.2顯示了一個典型的雙向發(fā)送數(shù)據(jù)包的場景。

19.4 使用案例：入口

在DPDK的RX端，mbuf由PMD在RX線程上下文中分配。此線程將mbuf排入rx_q FIFO。KNI線程將輪詢所有KNI活動設(shè)備以獲取rx_q。如果出列一個mbuf，它將被轉(zhuǎn)換為sk_buff，并通過netif_rx()發(fā)送到網(wǎng)絡(luò)堆棧。出列的mbuf必須被釋放，因此相同的指針將通過free_q FIFO發(fā)送回去。在同一主循環(huán)中，RX線程輪詢此FIFO并在出列后釋放mbuf。

19.5 使用案例：出口

對于數(shù)據(jù)包出口，DPDK應(yīng)用程序必須首先排入多個mbuf以在內(nèi)核端創(chuàng)建mbuf緩存。

Figure 19.2: Packet Flow via mbufs in the DPDK KNI
數(shù)據(jù)包通過調(diào)用kni_net_tx()回調(diào)從Linux網(wǎng)絡(luò)堆棧接收。mbuf被出列（由于緩存而無需等待），并用sk_buff中的數(shù)據(jù)填充。然后釋放sk_buff并將mbuf發(fā)送到tx_q FIFO。DPDK的TX線程出列mbuf并將其發(fā)送到PMD（通過rte_eth_tx_burst()）。然后將mbuf放回緩存中。

19.6 Ethtool

Ethtool是一個特定于Linux的工具，在內(nèi)核中具有相應(yīng)的支持，每個網(wǎng)絡(luò)設(shè)備必須為支持的操作注冊自己的回調(diào)函數(shù)。當(dāng)前的實現(xiàn)使用了修改后的igb/ixgbe Linux驅(qū)動程序以支持ethtool。在i40e和VM（VF或EM設(shè)備）中不支持Ethtool。

19.7 鏈路狀態(tài)和MTU更改

鏈路狀態(tài)和MTU更改是特定于網(wǎng)絡(luò)接口的操作，通常通過ifconfig完成。請求是從內(nèi)核端（在ifconfig進(jìn)程的上下文中）發(fā)起的，并由用戶空間的DPDK應(yīng)用程序處理。應(yīng)用程序輪詢請求，調(diào)用應(yīng)用程序處理程序，并將響應(yīng)返回到內(nèi)核空間。應(yīng)用程序處理程序可以在接口創(chuàng)建時注冊，也可以在運行時顯式注冊/注銷。這在多進(jìn)程場景中提供了靈活性（其中KNI在主進(jìn)程中創(chuàng)建，但回調(diào)在輔助進(jìn)程中處理）。約束是單個進(jìn)程可以注冊和處理請求。

19.8 KNI作為內(nèi)核vHost后端

vHost是一個內(nèi)核模塊，通常作為virtio（一種para-虛擬化驅(qū)動框架）的后端，加速從客戶機(jī)到主機(jī)的流量。DPDK內(nèi)核NIC接口提供了將vHost流量連接到用戶空間DPDK應(yīng)用程序的功能。與DPDK PMD virtio一起使用，它顯著改善了客戶機(jī)和主機(jī)之間的吞吐量。在DPDK作為主機(jī)中的快速路徑運行的情況下，kni-vhost是流量的高效路徑。

19.8.1 概述

vHost-net有三種真實后端實現(xiàn)。它們是：1）tap，2）macvtap和3）RAW socket。kni-vhost背后的主要思想是使KNI作為RAW socket工作，將其附加為vHost-net的后端實例。它使用與vHost-net的現(xiàn)有接口，因此不需要任何內(nèi)核修改，并且與內(nèi)核vhost模塊完全兼容。由于vHost仍然負(fù)責(zé)與前端virtio通信，因此它自然支持傳統(tǒng)的virtio-net和DPDK PMD virtio。來自vhost非輪詢模式的一點懲罰。但是，在使用多線程模式的KNI時，它能夠很好地擴(kuò)展吞吐量。

Figure 19.3: vHost-net Architecture Overview

19.8.2 數(shù)據(jù)包流動

與原始KNI流量流程相比，只有一個輕微的區(qū)別。在傳輸端，vhost kthread調(diào)用RAW socket的ops sendmsg，并將數(shù)據(jù)包放入KNI傳輸FIFO中。在接收端，kni kthread從KNI接收FIFO獲取數(shù)據(jù)包，將它們放入原始套接字的隊列中，并喚醒vhost kthread中的任務(wù)開始接收。無論是在傳輸端還是接收端，所有的數(shù)據(jù)包復(fù)制都發(fā)生在vhost kthread的上下文中。每個vhost-net設(shè)備都暴露給客戶機(jī)中的一個前端virtio設(shè)備。

Figure 19.4: KNI Traffic Flow
9.8.3 示例用法
在開始使用KNI作為vhost的后端之前，必須打開CONFIG_RTE_KNI_VHOST配置選項。否則，默認(rèn)情況下，KNI將不會啟用其后端支持功能。

當(dāng)然，作為先決條件，在編譯內(nèi)核之前應(yīng)選擇vhost/vhost-net內(nèi)核CONFIG。

1.編譯DPDK并像平常一樣插入uio_pci_generic/igb_uio內(nèi)核模塊。

2.插入KNI內(nèi)核模塊：

insmod ./rte_kni.ko

如果在多線程模式下使用KNI，使用以下命令行：

insmod ./rte_kni.ko kthread_mode=multiple

3.運行KNI示例應(yīng)用程序：

./kni -c -0xf0 -n 4 -- -p 0x3 -P -config="(0,4,6),(1,5,7)"

此命令在兩個物理端口上運行kni示例應(yīng)用程序。每個端口將在用戶空間中釘住兩個轉(zhuǎn)發(fā)核心（入口/出口）。

4.在qemu-kvm啟動時將原始套接字分配給vhost-net。由于DPDK沒有提供執(zhí)行此操作的腳本，因為用戶可以輕松自定義。以下顯示了啟動帶有kni-vhost的qemu-kvm的關(guān)鍵步驟：

#!/bin/bash
echo 1 > /sys/class/net/vEth0/sock_en
fd=$(cat /sys/class/net/vEth0/sock_fd)
qemu-kvm \
-name vm1 -cpu host -m 2048 -smp 1 -hda /opt/vm-fc16.img \
-netdev tap,fd=$fd,id=hostnet1,vhost=on \
-device virti-net-pci,netdev=hostnet1,id=net1,bus=pci.0,addr=0x4

使用sysfs的sock_en簡單啟用原始套接字，并在KNI設(shè)備節(jié)點下使用sock_fd獲取原始套接字fd。

然后，使用帶有-netdev選項的qemu-kvm命令將此類原始套接字fd分配為vhost的后端。

注意：關(guān)鍵字tap必須存在，因為qemu-kvm現(xiàn)在僅支持帶有tap后端的vhost，所以我們通過現(xiàn)有的fd來欺騙qemu-kvm。

19.8.4 兼容性配置選項

在DPDK配置文件中有一個CONFIG_RTE_KNI_VHOST_VNET_HDR_EN配置選項。默認(rèn)情況下，它設(shè)置為n，這意味著不啟用virtio net頭部，該頭部用于支持附加功能（例如，csum offload、vlan offload、generic-segmentation等），因為kni-vhost目前不支持這些功能。

即使選項被打開，kni-vhost也將忽略頭部包含的信息。在與客戶機(jī)上的傳統(tǒng)virtio一起工作時，最好使用ethtool -K關(guān)閉不支持的offload功能。否則，可能會出現(xiàn)諸如不正確的L4校驗和錯誤等問題。

20. 線程安全性的DPDK函數(shù)

DPDK由幾個庫組成。這些庫中的一些函數(shù)可以安全地同時從多個線程調(diào)用，而其他函數(shù)則不行。本節(jié)允許開發(fā)人員在構(gòu)建自己的應(yīng)用程序時考慮這些問題。

20.1 快速路徑 API

在數(shù)據(jù)平面操作的應(yīng)用程序?qū)π阅苊舾?#xff0c;但這些庫中的某些函數(shù)可能不適合同時從多個線程調(diào)用。哈希、LPM和內(nèi)存池庫以及PMD中的RX/TX就是這種情況的例子。

哈希和LPM庫在設(shè)計上是線程不安全的，以保持性能。但是，如果需要，開發(fā)人員可以在這些庫之上添加層以提供線程安全性。并非在所有情況下都需要鎖定，在哈希和LPM庫中，可以在多個線程中并行執(zhí)行值的查找。但是，無法在多個線程中添加、刪除或修改值，除非在訪問單個哈?；騆PM表時使用鎖定。另一個替代鎖定的方法是創(chuàng)建這些表的多個實例，允許每個線程擁有自己的副本。

PMD的RX和TX是DPDK應(yīng)用程序最關(guān)鍵的部分，建議不要使用鎖定，因為它會影響性能。但是，請注意，當(dāng)每個線程在不同的NIC隊列上執(zhí)行I/O時，這些函數(shù)可以安全地從多個線程中使用。如果多個線程要在同一個NIC端口上使用相同的硬件隊列，則需要鎖定或其他形式的互斥。

環(huán)形緩沖區(qū)庫基于無鎖環(huán)形緩沖區(qū)算法，保持其原始設(shè)計以實現(xiàn)線程安全性。此外，它為多個或單個消費者/生產(chǎn)者的入隊/出隊操作提供高性能。內(nèi)存池庫基于DPDK無鎖環(huán)形緩沖區(qū)庫，因此也是多線程安全的。

20.2 不敏感于性能的API

在前一節(jié)中描述的性能敏感區(qū)域之外，DPDK為大多數(shù)其他庫提供了線程安全的API。例如，malloc(librte_malloc)和memzone函數(shù)在多線程和多進(jìn)程環(huán)境中是安全的。

PMD的設(shè)置和配置既不敏感于性能，也不是線程安全的。在PMD設(shè)置和配置期間的多次讀/寫可能在多線程環(huán)境中會導(dǎo)致破壞。由于這不是性能敏感的，開發(fā)人員可以選擇添加自己的層來提供線程安全的設(shè)置和配置。在大多數(shù)應(yīng)用程序中，預(yù)計網(wǎng)絡(luò)端口的初始配置將由單個線程在啟動時完成。

20.3 庫的初始化

建議在應(yīng)用程序啟動的主線程中初始化DPDK庫，而不是在之后的轉(zhuǎn)發(fā)線程中初始化。然而，DPDK執(zhí)行檢查以確保庫只初始化一次。如果嘗試多次初始化，則會返回錯誤。

在多進(jìn)程的情況下，共享內(nèi)存的配置信息只會被主進(jìn)程初始化。之后，主進(jìn)程和次要進(jìn)程都可以分配/釋放依賴于rte_malloc或memzones的任何內(nèi)存對象。

20.4 中斷線程

DPDK幾乎完全在Linux用戶空間中以輪詢模式運行。對于某些不頻繁的操作，例如接收PMD鏈路狀態(tài)更改通知，回調(diào)可能會在主DPDK處理線程之外的額外線程中調(diào)用。這些函數(shù)回調(diào)應(yīng)避免操縱也由常規(guī)DPDK線程管理的DPDK對象。如果它們需要這樣做，就由應(yīng)用程序提供適當(dāng)?shù)逆i定或互斥約束來圍繞這些對象。