DPDK2.1開發者手冊4-7

Mempool Labrary

一個內存池(memory pool)就是固定大小對象的分配器。在dpdk中，它是經過名字來標示惟一性的，且使用環形隊列來保存沒有使用的空閒對象。它提供了一些可選項服務例如針對每一個核的對象緩存以及數據對齊，有助於將對象使用的內存空間均等的展開在DARM或者是DDR3通道上。

這個庫被Mbuf Library和EAL使用。

5.1     cookies

在調試模式下（CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG打開），cookies會被加到分配的內存塊的頭尾。分配的對象就包含了越界檢查區域以幫助調試緩衝區溢出。

5.2     統計

在調試模式下（CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG打開），對於從內存池中獲取和釋放的統計會保存在內存池結構體中。統計是針對每一個核的，避免併發訪問統計計數器。

5.3     內存對齊限制

取決於硬件內存配置，經過在對象之間作填充，性能能夠獲得巨大的提高。確保每一個對象的起始地址是在內存中的不一樣通道和rank，以便全部的通道都是均等的加載。

在作數據包三層轉發或者是流量分級時，這個是絕對實用的。因爲只有前64個字節的訪問，因此將對象的開始地址展開到不一樣的通道，性能能夠提高。

每一個DIMM（雙列直插式內存）rank數目就是是DIMM可訪問的全數據寬度的相互獨立內存集合的數目。不一樣rank上的內存是不能同時訪問的，即便是共享一樣的數據總線。DIMM自身的內存芯片的物理分佈和rank的數目沒有必然的聯繫。

當啓動程序時，EAL命令行參數提供了設置內存通道數和rank數的選項。

注意：必須在命令行參數中指定處理器的內存通道數。

下面是不一樣的DIMM架構中內存對齊的示例：

 

本例中，包的大小被設置成16個64字節內存塊。

intel 5520芯片有3個內存通道，因此在大部分狀況下，不須要在對象之間作填充擴展（除非對象的大小爲N*3*64字節）。

 

當建立一個mempool時，用戶能夠配置這一特性也可不配。

5.4     本地緩存

以cpu的尿性，多核訪問mempool的空閒緩衝隊列的開銷是很高的，即便是每一個核都只是須要一個CAS原語操做。爲了不對mempool隊列的太多，mempool的分配程序會保持對每一個核的緩存以及對mempool隊列的批量請求，經過緩存就能夠減小對實際mempool結構體的鎖開銷。用這種方式，每一個核均可以徹底訪問它本身的空閒對象緩存（有鎖）且僅當緩存滿的時候，這個核會將一些空閒對象寫回mempool隊列，而在緩存空的時候會獲取更多的對象到緩存。

這就意味着在覈上的緩存中有必定量的對象是佔着茅坑不拉屎的，在一個核無鎖訪問mempool緩存到高速緩存中的數據時，會得到性能提高。

高速緩存時由一個小巧的，針對每一個核的指針表組成，它的長度（用起來像棧同樣）。

是否緩存mempool的內的對象數據能夠在建立mempool的時候打開或者關閉。

最大緩存數據的大小是靜態設置的，定義的是編譯時變量（CONFIG_RTE_MEMPOOL_CACHE_MAX_SIZE）。

 

5.5     用例

全部內存的分配若是須要高性能的處理就須要使用基於內存池的分配方式。下面是一些例子：

l  Mbuf Library

l  EAL，日誌服務

l  任何程序在數據面須要申請固定大小的對象，這些對象應該並系統重複循環利用。

 

Mbuf Library

mbuf庫提供了分配和釋放報文消息緩衝（mbufs）的能力，後者用於dpdk程序存放報文數據。mbufs是保存在mempool中，使用的是mempool Library。

rte_mbuf結構體能夠傳輸網絡報文數據或者是普通的控制數據流（用CTRL_MBUF_FLAG標示）。它也能夠擴成其它類型。rte_mbuf頭結構保持儘量的小，當前是使用了兩個緩衝行的大小，最頻繁使用的在這兩個緩衝行上。

 

設計報文緩衝

對於報文數據（包括協議頭）的存儲，能夠從兩個方面考慮：

1. 在mbuf結構體中嵌入metadata，結構體以後帶上用於保存報文數據的固定大小的區域。
2. 分別給metadata結構體和報文數據使用分開的mbuf。

前者的好處是分配和釋放報文所使用的內存只須要一個操做。在另外一方面，第二種方法更加靈活，且容許將metadata結構體的分配和報文數據buffer的分配徹底分離。

DPDK選用了第一種方法。metadata包含控制信息例如消息類型，長度，報文數據偏移，一個指向mbuf鏈表中其它mbuf結構體的指針。

mbuf用於傳遞網絡報文，當多個mbuf用於裝載一個完整的報文時，它可使用報文緩衝鏈表。對於巨大的數據幀，多個mbufs經過成員next鏈接到一塊兒來保存報文。

對於剛分配的mbuf，報文段開始的位置在整個消息緩衝開頭偏移RTE_PKTMBUF_HEADROOM字節，報文段是緩存對齊的。消息緩衝也用於在系統內不一樣的對象間傳遞控制信息，報文，事件等等。消息緩衝結構體中也使用緩衝指針指向其它的消息緩衝數據區或者是其它的數據結構。

 

 

buffer存於mempool

buffer管理使用mempool來分配buffers。所以，它可以確保報文頭位於不一樣的通道和rank上以便於L3緩存交叉存取。一個mbuf中有一個變量代表這個pool的來源。當使用rte_ctrlmbuf_free(m)或者是rte_pktmbuf_free(m)時，將mbuf歸還給所屬的pool。

構造函數

報文和控制mbuf構造函數由API提供。rte_pktmbuf_init()和rte_ctrlmbuf_init()函數初始化mbuf結構體的一些一旦用戶建立就不會被修改的成員（mbuf類型，所屬的pool，buffer開始地址等等）。這個函數式做爲回調函數在建立一個mempool的時候傳遞給函數rte_mempool_create()。

分配和釋放mbuf

分配一個新的mbuf須要用戶指定從哪一個mempool中分配。對任意新分配的mbuf，它包括一個長度爲0的分段。至於數據位置的偏移，在初始化時就設置成了headroom大小（RTE_PKTMBUF_HEADROOM）。

釋放一個nbuf意味着將其放回所屬的mempool中。mbuf中的內容保存到mempool中時不用修改（做爲一個空閒mbuf）。成員在構造mempool時就已經初始化了，不必在分配mbuf時再從新初始化。

當釋放一個包含幾個分片的報文mbuf時，他們會一塊兒釋放並放回mempool中。

 

對mbuf的操做

本庫提供了一個函數接口操做報文mbuf中的報文數據，例如：

獲取報文數據長度

獲取報文數據的開始地址指針

在報文數據前添加數據

在報文數據後添加數據

從buffer中的開始位置移除數據（rte_pktmbuf_adj()）

從buffer的尾部移除數據（rte_pktmbuf_trim()）。

查閱dpdk的API文檔獲取細節信息

 

meta信息

一些被網卡驅動使用和存儲在mbuf中的信息可使處理更加簡單。例如，VLAN標誌，RSS哈希的結果（請看PollMode Driver）和硬件作校驗計算的標誌。

mbuf也包含了來源網卡端口標誌，本mbuf在分片報文存儲鏈表中的編號。

對於分片儲存報文鏈表，只有鏈表中第一個mbuf保存meta信息。

例如，以RX收包端爲例，有IEEE1558報文時間戳機制，VLAN標記和IP層校驗。

在TX發包端，也能夠將應用程序的一些處理交給硬件來實現（若是硬件支持）。例如，PKT_TX_IP_CKSUM標誌容許不作IPv4校驗計算。

下面的例子解釋了怎麼在封裝了虛擬可擴展局域網的TCP報文中配置不一樣的TX標記:out_eth,out_ip,out_udp,vxlan,in_eth，in_up，in_tcp,payload.

l  計算out_ip的校驗和：

mb->l2_len=len(out_eth)

mb->l3_len=len(out_ip)

mb->ol_flags |= PKT_TX_IPV4|PKT_TX_IP_CSUM

設置發送報文的ip層校驗爲0

這是有標誌DEV_TX_OFFLOAD_IPV4_CKSUM的硬件支持的。

l  計算out_ip和out_udp校驗和

mb->l2_len=len(out_eth)

mb->l3_len=len(out_ip)

mb->ol_flags |= PKT_TX_IPV4|PKT_TX_IP_CSUM|PKT_TX_UDP_CKSUM

設置out_ip檢驗爲0

設置out_udp在虛擬頭中的校驗使用rte_ipv4_phdr_cksum()

這是有DEV_TX_OFFLOAD_IPV$_CKSUM和DEV_TX_OFFLOAD_UDP_CKSUM標記硬件支持的。

l  計算in_ip校驗和

mb->l2_len=len(out_eth+out_ip+out_udp+vxlan+in_eth)

mb->l3_len=len(in_ip)

mb->ol_flags|=PKT_TX_IPV4|PKT_TX_IP_CSUM

設置in_ip的校驗爲0

這個和例子1類似的，可是l2_len不同。硬件有DEV_TX_OFFLOAD_IPV4_CKSUM標記的支持。注意，它僅在outer L4校驗爲0時起效。

l  計算in_ip和in_tcp校驗

mb->l2_len=len(out_eth+out_ip+out_udp+vxlan+in_eth)

mb->l3_len=len(in_ip)

mb->ol_flags|=PKT_TX_IPV4|PKT_TX_IP_CSUM|PKT_TX_TCP_CKSUM

這和例2類似，可是l2_len不同。同二，硬件要有DEV_TX_OFFLOAD_IPV4_CKSUM and DEV_TX_OFFLOAD_TCP_CKSUM.注意僅在outer L4校驗位0時才工做。

l  TCP分片報文

mb->l2_len = len(out_eth + out_ip + out_udp + vxlan + in_eth)

mb->l3_len = len(in_ip)

mb->l4_len = len(in_tcp)

mb->ol_flags |= PKT_TX_IPV4 | PKT_TX_IP_CKSUM | PKT_TX_TCP_CKSUM|PKT_TX_TCP_SEG;

硬件支持DEV_TX_OFFLOAD_TCP_TSO。注意只在outer L4檢驗爲0時工做。

這些標誌的定義和精確的含義在mbuf的API文檔中有講到（rte_mbuf.h）。也能夠查閱testpmd程序源碼（特別是csumonly.c文件）獲取更多的細節。

       直接和間接buffer

       一個直接buffer就是徹底獨立的且只包含本身的。而一個間接buffer的行爲看起來和直接buffer同樣，可是實際上這個buffer的指針和數據偏移都是指向另一個直接buffer。當須要拷貝報文或者是分片的時候，這個頗有用。所以間接buffer提供了多個buffer直接複用一樣的報文數據。

       當使用rte_pktmbuf_attach()將一個buffer附加到一個直接buffer上，則buffer變成間接的。每一個buffer中有一個引用計數器成員，不管是何時一個間接的buffer附加到該直接buffer上，應用計數器都會增長。一樣的，不管何時間接buffer分離，直接buffer上的計數器都會減小。當應用計數器的結果等於0時，直接buffer會被釋放掉再也不使用。

       在處理間接buffer時有一些事要記住。首先，不能將一個間接buffer附加到一個間接buffer上。其次，一個buffer變成間接buffer，它的引用計數器必須等於1，準確的說，它在以前必須不被其它間接buffer引用。最後，不能將一個間接buffer從新附加到一個直接buffer上（除非先detach）。

當作attach/detach操做時，能夠直接使用推薦的函數rte_pktmbuf_attach()和rte_pktmbuf_detach()。建議使用更高級的函數rte_pktmbuf_clone()，它會更當心的初始化一個間接buffer且能拷貝多個分段buffer。

因爲間接buffer設計成不存儲任何實際數據，因此間接buffer的mempool應該配置成減小這部份內存開銷。間接buffer的mempool初始化的例子（和直接buffer的例子同樣）能夠在幾個範例應用程序中找到，好比，IPV4廣播範例程序。

調試

在調試模式下（CONFIG_RTE_MBUF_DEBUG打開），mbuf庫的接口在執行任何操做以前都作安全檢查（例如，buffer錯誤，錯誤類型等等）

用例

全部的網絡應用程序應該用mbufs來傳輸網絡報文。

Poll Mode Driver

DPDK包括千兆，萬兆，4萬兆網卡和虛擬IO網卡設備的輪詢驅動。

PMD由運行在用戶態的BSD驅動提供的API組成，配置設備和收發包隊列。此外，PMD不經過任何中斷來直接訪問RX和TX描述符（除了網卡鏈接狀態改變的中斷以外）實如今應用程序中快速收包，處理和轉發。本章講述了PMD的必要條件，系統設計原則和上層架構以及爲以太網PMD的通用擴展API。

必要條件和設定

對於包處理程序DPDK容許兩種模式，run-to-completion和pipe-line：

l  在run-to-completion模式下，使用API來輪詢指定的網卡收包RX描述符隊列。而後報文也就在這個核上處理，而後經過發送API將報文放入網卡TX描述符隊列中。

l  在pipe-line模式下，一個core經過API輪詢一個或者是多個端口的RX描述符隊列。報文收下來以後經過ring傳遞給其它core。其它的core處理報文，處理完後經過發送API將報文放到端口的TX描述符ring中。

在同步的run-to-completion模式下，每一個邏輯core被分配一個DPDK執行報文處理循環，這個循環包括如下步驟：

l  經過PMD收包API從新獲取報文

l  逐一處理收到的報文直到發送

l  經過PMD發送API發送報文

反之，在異步的pipe-line模式下，一些邏輯core專一於收取報文，其它邏輯core來處理以前收到的報文。從新收到的報文在邏輯core之間的交換經過ring來完成。收包循環包括如下步驟：

l  經過PMD收包API收取報文。

l  經過報文隊列將收到的報文給處理的邏輯core

報文處理的循環包括如下步驟：

l  從新從報文隊列獲取收到的報文。

l  處理收到的報文，若是是發送則直到轉發爲止。

 

設計原則

以太網PMD的API和架構是如下面的知道原則來考慮設計的。

PMD必須適應全局策略決定了必須運行在上層的用戶態。反之，網卡的PMD功能不該該是咱們經過上層全局策略獲取的好處的阻礙，或者是不會讓應用這些策略變得更糟。

例如，PMD的收包和發包功能有一個輪詢報文/描述符的最大值。這就運行一個run-to-completion處理程序使用靜態固定值或者是匹配不一樣全局循環策略的動態值，例如：

l  以零碎的方式一次一個報文的接收，當即處理且發送

l  接收儘量多的報文，而後處理全部收到的報文，接着當即放鬆它們

l  接收給定最大數目的報文，處理收到的報文，堆積處理的報文，最後再將其一塊兒發送

要達到最優的性能，軟件的整體設計選擇和純粹的軟件優化技術必須考慮到，且須要在底層的硬件優化特性（CPU緩存特性，總線加速，網卡PCI帶寬等等）。在報文的發送中，優化網絡報文burst方式的處理性能，就是軟件和硬件之間的折中的例子。在初始的版本中，PMD僅支持rte_eth_tx_one功能來想一個隊列中一次發送一個報文。在其之上，很輕鬆就能夠實現rte_eth_tx_burst功能，循環調用rte_eth_tx_one函數來逐一發送多個報文。然而，rte_eth_tx_burst功能被PMD有效的執行並最小化了在驅動層的發送開銷，經過如下的優化來實現：

l  在多個報文之間調用rte_eth_tx_one函數非應攤成本的開銷的共享

l  使用rte_eth_tx_burst函數來一次提交多個報文，能夠充分利用硬件特性（預取數據到緩存中，使用網卡的頭尾寄存器）來最小化每一個報文的處理cpu時鐘週期。例如，避免沒必要要的訪問發送描述符環形隊列的內存讀取，或者是系統使用指針數組來準確的匹配緩存line的邊界和大小。

l  應用大量提交報文的軟件優化技術來減小一些沒法避免的操做開銷，好比環形隊列的迴環管理。

以大量報文處理的功能在經過API的引進在PMD中大量的使用。特別是在nic的buffer ring中分配和釋放多個報文buffer。例如，mbuf_multiple_alloc函數返回一個rte_mbuf的指針數組，當補充多個描述符到收包的ring中時，這會加速PMD的收包輪詢函數。

邏輯core，內存和網卡隊列的關係

dpdk支持NUMA以獲取更好的性能，處理器的邏輯核和接口利用本地的內存。所以，PCIe接口的mbuf的內存池應該在本地分配。buffers若是可能應該保持在本地處理器來獲取更好的處理性能，RX和TX buffer描述符裝載的mbuf應該是從本地內存建立的mempool中分配。

run-to-completion模式在報文和數據操做都是在本地內存而不是remote處理器內存性能會更好。這對於pipe-line模式也是同樣的，全部的邏輯核都是在一個處理器上。

多個邏輯核最好是毫不共享網卡收包和發包隊列，由於這會要有全局的鎖和下降性能。

 

設備標示和配置

每一個NIC端口的配置包括如下操做：

l  分配PCI資源

l  重置硬件的默認狀態

l  創建物理鏈路層和鏈接

l  初始化統計計數器

PMD API必須提供接口開啓和關閉端口的組播特性的功能以及設置和清除端口混雜模式的功能。

一些硬件加速特性必須在端口初始化時經過特定的配置參數分別配置。好比RSS和DCB。

on-eth-fly配置

全部的設備特性就是on-the-fly下啓動的和中止（準確的說就是沒有中止設備）不須要PMD API爲這個目的提供專門的功能。

這些都須要將PCI設備寄存器映射地址來在驅動外部使用指定功能配置這些特性。

爲了達到這個目的，PMD API導出一個功能，提供了在設備的驅動以外啓動設備的特性的全部的關聯信息。這包括PCI vendor ID，PCI device ID，pci設備寄存器映射的地址，驅動的名字。

這方面作的主要好處是給用戶徹底自由的選擇API來配置，開啓，關閉這些特性。

舉個例子，參考intel的82576千兆網卡控制器和82599萬兆網卡控制器在testpmd程序中IEEE1588特性的配置。

其它特性，例如端口的L3/L4 五元組包過濾特性也能夠用一樣的方式配置。以太網留控（幀暫停）能夠配置在個別的端口上。參考testpmd源碼獲取細節。還有，L4（UDP/TCP/SCTP）校驗網卡加速能夠針對特殊的報文打開，只要之歌報文的mbuf是正確的。看hardwareoffload（硬件加速）獲取細節。

配置收發包隊列

每一個發包隊列都是單獨配置下列信息的:

l  發送環形隊列的描述符個數

l  插槽標識用於在numa架構下從合適的節點分配DMA內存區域

l  發送隊列的預取值,主機和回寫閥值

l  最小報文發送釋放閥值(tx_free_thresh).當發送的報文描述符個數超過這個值,網絡適配器應該檢查是否已經寫回描述符.當值是0是會採用默認值32.這就保證了PMD網卡的發包隊列處理了至少32個報文時纔去檢索完成的報文描述符.

l  最小的RS位閥值.在發送描述符中最小數目的發送描述符用於設置狀態報告位RS.注意這個參數只對萬兆網卡有效.RS位

l   

該部分暫略.

硬件負載均衡Hardware Offload

依賴於驅動的內力,可經過rte_eth_dev_info_get()獲取,PMD可能支持硬件負載均衡，像校驗和，TCP分片，或者是VLAN插入。

對上述負載特性的支持意味着在rte_mbuf結構體中添加額外的狀態位。這些標誌的精確描述參看API文檔，在Mbuf Library章的Meta Information小節。

輪詢驅動API

通常性

默認全部PMD接口都是無鎖的，咱們假定它不會在不一樣的邏輯核之間並行訪問一樣的對象。例如，PMD收包函數不會被不一樣的邏輯核調用輪詢一樣的網卡的相同隊列。固然，這個函數能夠被不一樣的邏輯核並行調用從不一樣的rx收包隊列中取包。上層應用好比遵照這個規則。

通用的報文處理

能夠用一個rte_mbuf結構體表明一個報文，這是通用的metadata結構體，包含全部必須的內部信息。包括fields和硬件負載均衡狀態位，例如IP頭檢驗和或者是VLAN標記。

Rte_mbuf結構體包含特定的fields，略。

以太網設備API

參見API手冊。

DPDK IVSHMEM Library

DPDK IVSHMEM庫在虛擬機之間快速零拷貝數據（host-to-guest 或者是guest-to-guest），經過QEMU的IVSHMEM機制實現。

這個庫經過命令行調用QEMU映射幾個大頁成單獨的ivshmem設備。對於guest須要知道每一個給定的ivshmem設備（識別dpdk和非dpdk ivshmem設備）的內部信息，一個metadata成員也被映射到ivshmem段上。Guest應用程序不必將ivshmem設備映射到內存，這個是dpdk抽象層自動識別完成的。

一個典型的dpdk ivshmem用例以下：

 

在幾個虛擬機之間也是一樣的工做，提供了host-to-VM或者是VM-to-VM通信。最大數量的metadta成員數爲32（默認）且每一個metadata成員可包含不一樣的大頁（甚至是相同的大頁）。惟一的限制就是每一個VM必須和其它對象訪問共享的內存（多是host或者是其它的vm）。若是用戶想在兩個VM之間共享同一個內存區域，每一個VM必須在其metadta成員包含這個內存區域。

8.1              IVSHMEM API 概覽

下面是對使用IVSHMEM庫API的簡單引導：

l  調用rte_ivshmem_metadata_create()建立一個新的metadata文件。這個metadata名字用於多個metadata之間作區別。

l  在metadata結構中加入DPDK數據結構體。可經過一下API調用來實現：

n  Rte_ivshmem_metadata_add_memzone（）來將rte_memzone添加到metadata中。

n  Rte_ivshmem_metadata_add_ring()添加rte_ring結構。

n  Rte_ivshmem_metadata_add_mempool（）添加rte_mempool。

最後，調用rte_ivshmem_metadata_cmdline_generate()來生成用於QEMU的命令行。多個metadata文件（對應多個命令行）能夠設置到一個VM上。

注意：只有數據結構體位於DPDK大頁內存區域時才能正常工做。若是支持的結構體是經過malloc，mmap，或者是其它非dpdk內存建立的，會致使沒法預料的錯誤，甚至是棧錯誤。

8.2 IVSHMEM環境配置

要成功運行IVSHMEM應用程序，下面的步驟是必需的：

l  編譯QEMU的特定版本

源碼能夠從QEMU網站獲取（當前版本1.4.x是支持的，可是1.5.x也能夠工做），須要打補丁才能支持啊。補丁再也不DPDK包中，能夠到官網上去下。

l  在DPDK建立配置時打開IVSHMEM庫開關

在默認配置下，IVSHMEM庫是不編譯的。要編譯IVSHMEM庫，要麼使用有IVSHMEM目標的編譯（例如，x86_64-ivshmem-linuxapp-gcc），或者是設置配置文件中CONFIG_RTE_LIBRTE_IVSHMEM爲y。

l  在虛擬機中建立大頁內存

Guest應用程序做爲DPDK（主）程序運行，那就須要在VM中建立大頁內存。這個過程在DPDK入門手冊中講到的同樣。

8.3 開發IVSHMEM應用程序最佳實踐

當考慮使用IVSHMEM來共享內存，就須要評估安全問題。對於不信任的guest，IVSHMEM並不合適，由於IVSHMEM本質上是一個訪問host處理程序內存的窗口。這對多個VM狀況也是同樣適用的。當IVSHMEM庫共享盡量小的內存區域，頗有可能的，對於這個VM設計的數據也會存在於一個IVSHMEM設備下的其它VM中。因此，任何共享內存出錯會影響到host和其它全部共享了該內存的VM。
IVSHMEM應用程序本質上運行就至關於多進程應用程序，因此就須要考慮數據訪問的串行行和線程安全。DPDK ring結構是線程安全的，可是，任何客戶數據結構的使用者都必須是線程安全的。

和PDDK多進程程序相似，在不一樣的進程中訪問的數據內存地址是不一樣的。

作好是避免在分配的機器以外的機器釋放rte_mbuf結構體，換句話說，host分配的就應該host來釋放。因此，報文的發送和接收也應該在一樣的機器上發生。（要麼虛擬機要麼物理機）。若是不是這樣作可能會致使mempool緩存數據錯誤。

儘管IVSHMEM機制是零拷貝且有很好的性能。在批量處理上也遵循性能優化中的步驟。

 

8.4 運行IVSHMEM程序的最佳實踐

處於性能上的考慮，最好將host進程和QEMU進程分配到不一樣的核上以便其互不干擾。若是系統支持NUMA，也須要保證host進程的大頁內存和QEMU進程的在同一個NUMA節點上。

對於跨NUMA節點的最佳性能，每一個QEMU核應該和host 核在一樣的NUMA節點上。QEMU的虛擬NUMA節點也設置對應到物理NUMA節點。更多關於如何建立DPDK和QEMU numa支持能夠看DPDK入門手冊和QEMU文檔。Dpdk源碼包中腳本cpu_lauout.py（在tools目錄下）能夠用來識別cpu核屬於那個numa節點。

QEMU IVSHMEM命令行在虛擬機中啓動前須要考慮最後一步。當前，QEMU IVSHMEM設備不支持熱插拔，因此一旦建立了就不能添加額外的內存到IVSHMEM設備中。所以，運行IVSHMEM程序的正確順序是先運行host程序，得到每一個IVSHMEM設備的命令行，而後再以guest應用程序運行每一個QEMU實例。

有一點很重要的須要注意，QEMU一旦啓動，它就會獲取用於IVSHMEM設備的大頁內存。結果就是，若是用戶想要關閉或者是重啓IVSHMEM host進程，就不是簡單的關閉程序了。虛擬機也必須關閉（若是沒有，它會一直佔有host數據）。

 

LINK BONDING POLL MODE DRIVER LIBRARY

除了物理和虛擬硬件的輪詢驅動，DPDK也包括一套軟件庫容許物理硬件的PMD 聚合到一塊兒建立一個邏輯的PMD。

 

鏈路聚合PMD庫（librte_pmd_bond）支持聚合一組相同速度和雙工的rte_eth_dev端口，提供和linux上bond驅動的相同功能，容許主機和交換機之間多個（slave）網卡聚合成一個邏輯接口。新的聚合PMD將按照指定的操做模式處理底層網卡，例如鏈路主備，故障容錯，負載均衡。

Librte_pmd_bond庫提供API來建立bond設備，包括配置和管理bond設備和它的slave設備。

注意：librte_pmd_bond庫默認是開啓的，關閉能夠將CONFIG_RTE_LIBRTE_PMD_BOND設置爲n再從新編譯。

 

9.1              鏈路聚合模式概覽

當前的鏈路聚合PMD庫支持4中操做模式：

l  Round-Robin（Mode 0）：

 

這個模式提供了報文傳送的負載均衡和容錯處理，按順序嘗試第一個能夠被動設備直到最後。在round-robind模式下運行報文會大量的從設備的隊列中移除，這種模式不保證順序的接收報文，下行的流應該能處理亂序的報文

l  Active Backup（Mode 1）：

 

         在這個模式下，bond中只有一個slave設備在任什麼時候間是活動的，當且僅當主活動的slave錯誤時，另一個slave纔會變成活動狀態。所以必須提供容錯機制來處理slave錯誤。整個邏輯bond接口的mac地址在外部可見的知識一個端口以免混淆網絡轉換。

l  Balance XOR（Mode 2）：

注意：報文的顏色不一樣用於標示不一樣的流類別，選擇的傳輸策略計算

 

這種模式提供了傳輸負載均和（居於選擇的傳輸策略）和容錯。默認策略（2層）使用一個簡單的計算，基於報文流源和目的mac地址計以及Bond設備中可用的活動slave設備數目的結果標記報文使用指定的slave傳輸。2層和3層支持輪詢傳輸策略，使用ip源地址和目的地址來計算出使用的傳輸slave端口，最後支持的3+4層使用源端口和目的端口，就和源ip、目的ip方式同樣。

l  Broadcast（Mode 3）：

 

這種模式提供了報文傳輸過程當中的容錯，就是每一個端口都發一遍。

l  Link Aggregation 802.3AD（Mode 4）：

 

這個模式支持802.3ad標準的動態鏈路聚合。它聚合管理一組網卡設備共享一樣的速度和雙工設置，使用選擇的輸出平衡策略。

DPDK要支持這種模式須要應用程序知足一些其它要求：

1. 須要調用rte_eth_tx_burst和rte_eth_rx_burst的間隔時間小於100ms
2. 調用rte_eth_tx_burst的大小必須爲2乘以N，N爲slave的個數。這是LACP協議幀須要的大小。此外，LACP報文也包含在統計計數中，可是它們並不傳遞給應用程序。

l  Transmit Load Balancing(Mode 5):

 

這種模式提供了自適應的傳輸負載均衡。它動態的改變傳輸slave，依據據算的負載。每100ms收集一次統計值並每10ms計算調度一次。

9.2              細節

Librte_pmd_bond 聚合的設備和DPDK的以太網PMD接口兼容。Link Bonding庫支持在程序啓動時建立bond設備，在EAL初始化時使用—vdev選項來實現，等同於程序自動調用rte_eth_bond_create函數。

綁定的設備支持動態的添加和移除slave設備，接口爲rte_eth_bond_slave_add和rte_eth_bond_slave_remove。

在一個slave設備添加到綁定的設備以後，能夠用rte_eth_dev_stop來stop這個slave設備且使用rte_eth_dev_configure來從新配置，rx和tx隊列也能夠經過rte_eth_tx_queue_setup和rte_eth_rx_queue_setup來從新配置綁定設備。

9.2.1            鏈路狀態改變中斷/輪詢

鏈路綁定設備支持鏈接狀態改變的回調函數註冊，使用API rte_eth_dev_callback_register。當綁定的設備狀態發生改變時，這個函數會被調用。例如，在一個綁定的設備有3個slave，當一個slave狀態變爲活動時鏈路的狀態就變爲up，或者是全部的slave變爲非活動狀態時，鏈路的狀態就變爲down。當單個的slave狀態發生改變時不會觸發回調機制，先決條件不知足。若是用戶要監控單獨某一個slave就必須註冊這個slave對應的回調函數。

鏈路綁定庫也支持那些鏈接狀態改變沒法觸發中斷的設備，經過固定時間間隔輪詢鏈接狀態來實現，設置接口爲rte_eth_bond_link_monitoring_set。默認的輪詢間隔爲10ms。當一個設備做爲slave添加到bond設備中，它須要經過使用RTE_PCI_DRV_INTR_LSC標記來肯定設備是支持中斷仍是輪詢獲取鏈接狀態。

 

9.2.2            要求和限制

當前只支持添加到bond設備的slave設備均是說一樣的速度和雙工。Bond設備繼承第一個轟動的slave設備屬性，其它以後添加的slave設備必須支持那些參數。

在啓動bond設備前，bond設備下至少有最小數量即1個slave設備。

和PMD同樣，全部的函數都是無鎖的，咱們假定這些接口不會被不一樣的邏輯核並行調用訪問同一個對象。

也要注意在slave設備ijaru到bond設備中以後，PMD接口收包函數不能被slave設備直接調用，由於從slave設備直接讀取的報文時不能再從bond設備讀取的。

 

9.2.3            配置

鏈路bond設備經過函數rte_eth_bond_create建立，這個函數須要指定一個惟一的設備名稱，bond模式以及numa節點id以便分配bond設備的資源所在。其它的配置參數是slave設備，主slave，balance XOR模式下用到的用戶定義的mac地址和傳輸策略。

Slave Devices

Bond設備支持最大量的slave設備RTE_MAX_ETHPORTS。網卡設備最爲slave添加到bond設備的最大數。Slave設備在添加到bond設備時會根據bond設備的配置從新配置。

Bond會確保當一個slave從bond設備移除時可以返回其原始的mac地址值。

Primary Slave

當bond設備是活動主備模式時，那個活動的slave即爲默認的主slave。當且僅當主slave down掉時，其它的端口被用到。若是沒有指定主slave則默認是將第一個添加到bond設備的端口設爲主端口。

MAC Address

Bond設備能夠配置爲用戶指定的mac地址，這個地址會被全部的或者是部分slave繼承，具體依賴於操做模式。當設備處於活動主備模式時，只有主設備有用戶指定的mac，全部其它的slave保留原有的mac地址。在模式0,2,3,4中，全部的slave設備配置成bond設備的mac地址。

若是用戶沒有定義bond設備的mac地址則默認使用主slave的mac地址。

Balance XOR Transmit Policies

有3種支持bond設備在Balance XOR 模式下運行的傳輸策略：

n  Layer 2：基於以太網mac地址的均衡策略是Balance XOR模式的默認傳輸策略。它通過一個簡單的基於報文中源mac地址和目的mac的異或運算，再與slave個數取模獲得具體傳輸用的slave設備的值。

n  Layer 2+3：基於源和目的mac地址、ip地址聯合計算來決定使用哪一個slave端口來傳輸報文。

n  Layer3+4：IP地址和udp端口號爲基礎來計算出用哪一個port傳輸。

全部這些策略支持802.1Q VLAN以太網報文，包括IPv4，IPv6和UDP協議的負載均衡。

9.3              使用鏈路聚合設備

Librte_pmd_bond庫支持兩種方式的設備建立，要麼C語言的API接口，要麼在程序啓動時傳入EAL命令行參數來靜態的配置bond設備。使用後者不須要對API庫有必定的瞭解就能夠建立bond設備。

9.3.1              應用程序使用輪詢模式

使用librte_pmd_bond庫的API能夠在程序內存動態的建立和管理bond設備。這一段實際上上面都講過了，日，估計這個文檔是多我的寫的。

能夠經過如下api來配置或者是查詢配置rte_eth_bond_mode_set/get,rte_eth_bond_primary_set/get,rte_eth_bond_mac_set/reset,rte_eth_bond_xmit_policy_set/get.

 

9.3.2              經過EAL命令行來使用鏈路聚合設備

鏈路聚合設備的能夠在程序啓動時使用命令行—vdev 選項建立。設備名稱必須以eth_bond開頭，後面接數字或者是字母。名字且必須是惟一的。每一個設備的多個選項數組以逗號分隔的列表。多個設備選項能夠屢次調用—vdev。

例如：

$RTE_TARGET/app/testpmd –c f –n 4 –vdev ‘eth_bond0,bond_opt0=..,bond_opt1=..’ –vdev ‘eth_bond1,……….’

 

鏈路聚合EAL選項

略