加速NFV（網絡功能虛擬化）數據面：SR-IOV和DPDK[原文意譯]

事實確實如此 - 過去不少人都在談論SR-IOV和DPDK，即便在咱們本身的博客上也是如此。我認爲這是一個挑戰：有機會以稍微不一樣的方式講述數據平面加速的故事。固然，咱們的審查編輯也認爲這是一個挑戰，由於她正在瀏覽大量潛在的資料，在個人做品中尋找剽竊的例子。顯然，「最誠懇的奉承」在寫做界並無價值。

查爾斯·卡萊布·科爾頓(英國做家)

真是慚愧，由於我與說這句話（指上段最後一句）的查爾斯·卡萊布·科爾頓有許多共同之處......不只僅是由於我也逃離了英國，以逃避個人債權人。查爾斯在他的着做《Lacon, or Many Things in Few Words: Addressed to those who think》說：「當追隨本身的經驗時，錯誤比無知讓本身更難到達終點」。寫這樣一篇文章的主要緣由是：爲了幫助我在前進以前控制個人無知，防止直撞懸崖。另外，咱們網站上的其餘頁面也歡迎瀏覽，謝謝。

英特爾做爲SR-IOV和DPDK的領導者或直接創始者，都是關於二者的絕佳信息來源。基於AMD（IOV），Inte（VT-d）等的輸入/輸出內存管理單元（IOMMU）技術的創建和標準化，「單根I/O虛擬化和共享規範」於2007年9月^[1]首次發佈，同時服務器虛擬化的概念正在大踏步前進。到目前爲止，I/O虛擬化選項是嚴格基於軟件的，虛擬機監控程序（VMM）永久駐留在物理網卡與虛擬網卡（vNIC）之間，vNIC與虛擬機緊密相連。

雖然一般咱們就是這麼看待虛擬化機的，並且這確實有一些優點，例如對老舊的應用程序支持和緩解對「專用」硬件的依賴，但使用虛擬機也致使了很是高的CPU利用率。這最終會下降吞吐量和一個平臺實際部署的虛擬機數量--在某些狀況下，從業務角度來看虛擬化已經再也不可行。

與非虛擬化同樣，在虛擬機中處理線纜中的數據包也是中斷驅動的。當網卡接收到數據時，會向CPU發送中斷請求（IRQ），而後CPU必須停下來去獲取數據。任何有孩子的人都會明白，中斷是無止境的 - 下降CPU執行主要計算任務的能力。在虛擬機中，這個問題被進一步放大了。運行管理程序的CPU內核不只會被中斷，並且一旦識別出該數據包屬於哪一個虛擬機（例如，基於MAC或VLAN ID），則必須再向運行該虛擬機的CPU內核發送中斷，告訴那個虛擬機來獲取它的數據。

這對性能是一個雙重傷害，但更重要的是第一個CPU內核是主要的瓶頸，會很快到達最大負載。Intel採起了第一步消除這一瓶頸，並經過被稱爲虛擬機設備隊列（VMDq）的技術來提升總體性能。顧名思義，VMDq使hypervisor可以爲每一個虛擬機分配一個不一樣的網卡隊列。這樣以來，不要先向管理程序CPU內核發送中斷，只須要中斷宿主目標VM的CPU內核。數據包只被搬弄一次，由於它直接複製到VM用戶空間內存中。

如今VMDq已經消除了瓶頸，全部VM主機核心中的中斷更加平衡。雖然這具備使hypervisor保持在循環中的優勢，從而使得諸如vSwitch的功能保持在線，可是以數據平面爲中心的虛擬化網絡功能中的絕對數量的中斷仍將對性能具備使人難以置信的不利影響。這就是SR-IOV誕生的由來。

當SR-IOV誕生時，咱們正在經歷一些中斷根除運動。 InfiniBand風靡一時，其遠程直接存儲器訪問（RDMA）技術有望推翻IRQs，只要它可以克服以太網。然而，像房子同樣，以太網再次證實了這是不該該被打賭的東西。雖然不是「遠程的」，由於沒有獨特的鏈路層協議，SR-IOV提供的是更加不可知的（讀取：以太網）針對DMA的本地化和非overlay方法，專門針對虛擬化^[2]。

源於PCI術語定義的元素把CPU和內存鏈接到PCI switch fabric (Root Complex)，特別是本身定義名字的port(Root Port)，SR-IOV容許單個的以太網接口表現的像多個獨立的物理端口（很像VMDq），用以減輕中斷問題，可是，SR-IOV比VMDq更好。

VM 3-ways: Normal operation through bottleneck eradication (VMDq) and interrupt mitigation (SR-IOV)

使用SR-IOV，hypervisor負責爲每一個VM實例劃分NIC中的特定硬件資源。使人困惑的是咱們全部人仍然試圖讓咱們的腦殼圍繞NFV命名，這些被稱爲虛擬功能（VFs）。虛擬功能由一個有限的，輕量級的PCIe資源^[3]和一個專用的發送和接收數據包隊列組成。在啓動時加載VF驅動程序，hypervisor爲每一個虛擬機分配這些虛擬功能中的一個。而後NIC中的VF被賦予一個描述符，告訴它所在的具體虛擬機擁有的用戶空間內存在哪裏。一旦在物理端口上接收到數據包，並將其分類（經過MAC地址，VLAN標記或其餘標識符），數據包將在VF中排隊，直到它們能夠被複制到VM的存儲位置中爲止^[4]。

這種無中斷的操做解放了VM的CPU核心，它就能夠更多的被用於本機上的虛擬網絡功能的計算。簡而言之，SR-IOV很快。事實上，惟一比他更快的是PCI直通技術，可是我忽略了他是由於一次只能有一個VM使用，緣由是PCI設備其實是直接分配給了guest VM。也就是說，和SR-IOV不同，PCI直通技術確實有做爲純軟件解決方案的優勢，可是他是基於特定的硬件特性（非標準化）。我也忽略了這些優勢。

全部這些DMA的好處也是它的缺點，由於接口和虛擬機之間的任何事情都被繞過了。儘管OpenStack的Juno版本擴展了Neutron和Nova以支持網絡設備的SR-IOV，從而減小了發生錯誤的機會，這個數據平面加速選項取決於NFV管理和編排（MANO）層，但DMA技術最終仍是會致使流量繞過Hypervisor vSwitch。這引發了一些問題，包括SR-IOV支持便攜性，靈活性，QoS，複雜的業務導向（包括用於服務功能連接的網絡服務報頭，若是VNF是中間件）的能力以及指望的NFV的雲網絡虛擬化需求的問題。

一般這並非說你不能在同一臺主機上或者你的雲環境中同時運行SR-IOV和vSwitch，絕對可行。這將容許NFVI工程師在須要的時候使用vSwitch，SR-IOV或者兩種結合使用。SR-IOV對於虛擬化是一個不錯的選擇，或者用以實施一個單獨的虛擬化設備，對於指望得到高吞吐量的VNF設備，路由器或者三層爲中心的架構，使用SR-IOV都是很是值得推薦的。而對於以二層爲中心的中間設備或者VNF，若是對跨主機的東西向流量有嚴格的要求，那麼就使用vSwitch。可是，這樣的混合體繫結構可能會增長管理的複雜性，也下降了構建通用，高效和靈活的SDN部署方式的可能性。

先把上面的推測放一邊，簡單的事實是在NFV基礎設施中，咱們在某些地方須要vSwitch。可是vSwitch很慢又笨拙。這並不使人感到驚訝，公平的講，你們獲得了想要的東西--靈活，可編程，狀態可維護。但這些都不是沒有代價的，這是以犧牲性能爲代價的。若是咱們討論OVS，從如今開始，它嘗試引入Megaflow(OVS 1.11 circa April 2011)的概念來提升性能，Megaflow是安裝入內核中的二級流表緩存項。

經過把OVS拆分紅內核態和用戶態兩部分，這樣以來，一旦在用戶態報文被識別並通過處理後，最近被精確匹配轉發的數據包對應的Microflow項就經過NETLINK被下發安裝到內核中。此外Megaflow每條緩存還包含通配符，能夠匹配多個數據包，而不僅是一個。這避免了大量的數據包頻繁地與用戶態進行IPC通訊，減小上下文切換形成的性能損失。

OVS Circa 1.11, featuring the kernel-level Megaflow Cache together with the Microflow Cache.

可是據稱，在OVS 2.1中，這種加強加速顯得不太靠譜^[5]。Megaflow的加速能力仍然依賴於數據包的特徵和行爲和穿越他的流量的模式，所以，不一樣的應用會有不一樣的結果。簡單的說，他可能有效也可能無效--必定程度的不可預測性是不可能被開發和部署到商業服務中的。另外一方面，他依然存在高開銷的IPC，這就須要Data Plane Development Kit (DPDK) 大顯身手了。

在Megaflow首次亮相（2011年9月）以後沒多久，DPDK正式推向了世界，它是一個純淨又簡潔的工具包。利用底層英特爾硬件的功能，它包含一組輕量級軟件數據平面庫和優化的NIC驅動程序，可針對特定應用程序進行修改。領先於6WindGate優化的產品和支持，緊隨其後的是另外一個Wind（River，英特爾部門），DPDK在2013年以開源BSD許可證形式向開發社區開放。DPDK能夠應用於任何在Intel架構上運行的網絡功能，OVS是理想的用例。

DPDK包含內存，buffer，和隊列管理，此外還有一個流量分類引擎和一組輪詢驅動程序。與Linux新API（NAPI）驅動程序相似，正如咱們從SR-IOV知道的那樣，DPDK輪詢模式執行全部重要的中斷緩解，這對於提升應用程序的總體性能相當重要。在網絡流量較大的時候以輪詢模式工做，內核會按期檢查接口是否有傳入數據包，而不是等待中斷。爲了防止poll-ution(是的，我用來它描述當沒有數據須要被獲取時的輪詢狀態)而不至於當有數據包到來時數據包須要等待被接收(這樣會增長時延和抖動)，當數據包流量低於某一個閥值時，DPDK能夠切換到中斷模式。

經過隊列，內存和buffer管理器，DPDK還能夠經過零拷貝直接把報文DMA到位於用戶空間存儲器中的大型先進先出（FIFO）環形緩衝區，相似於PF_RING。這又一次顯着提升了數據包採集的總體性能，不只能夠實現更快的捕獲速度，還能夠平滑突發的入站流量，使應用程序可以更加一致地處理數據包，從而更高效地處理數據包。 另外，若是客戶機CPU忙於處理應用程序，它能夠將數據包保留在緩衝區中，而不用擔憂這些數據包被丟棄。天然，這個緩衝區大小以及輪詢/中斷閾值須要對延遲敏感的應用程序（如語音）仔細調優。

The FIFO Ring Buffer

一個開放的vSwitch能夠表現一些魔法，可是魔法老是伴隨着一個代價，咱們最終在CPU開銷中付出了成本。 可是，若是使用修改後的DPDK實現CPU加速，那麼CPU開銷會大大下降。 那些使用DPDK加速OVS的方法已經實現了獨立的控制和數據平面體系結構，這些體系結構在特定CPU內核的用戶空間中執行分組處理，以從Linux卸載處理。 實際上，DPDK取代了Linux內核數據平面，這意味着microflows和megaflows都是在用戶空間中以相同的方式操做的。

DPDK Accelerated OVS Within User Space

只有複雜的，基於狀態的控制和管理協議（即ARP）才被髮送到Linux網絡堆棧進行處理。 可是，若是將加速的vSwitch與傳統的vSwitch實現進行比較，則知足高吞吐量速率的虛擬化網絡功能所需的CPU內核數量將大大減小。來自Wind的Charlie Ashton在一年前的博客上發表了一些具體的數字^[6]，一個OVS CPU核心處理0.3M（64字節）pps，須要12個才能支持4 Mpps（或1 Gbps全雙工以太網）。即使更多的核心意味着更大的吞吐量，然而主機能夠支持的VNF數量也會隨之減小。 即便在不利的64字節數據包大小下，Wind的Accelerated vSwitch每一個核心也能處理12 Mpps，所以只須要四個便可將單個全雙工10 Gbps接口打滿。

HPE最近發佈了測試結果，比較裸機與SR-IOV和加速vSwitch的效果，此次是從6Wind^[7]。雖然必須考慮CPU開銷，但結果代表，一旦超出64字節的數據包範圍，三者的表現都開始與接近高峯的表現大踏步前進。

Data plane acceleration testing results and comparisons, courtesy of HPE

雖然這在表格中看起來不錯，但咱們應該記住，典型的Internet Mix（IMIX）流量中的64byte長度的數據包，佔平均流量樣本的50％到60％。若是有問題的VNF碰巧正在處理實時語音和視頻流量，例如會話邊界控制器，這將會大大增長。這就是爲何咱們將SBC用於SR-IOV和DPDK/OVS測試用例。正如Metaswitch首席技術官Martin Taylor在2015年1月的一篇博客文章中記錄的，咱們的結果讓人們放心許多^[8]。讀了這麼多以後，聽到SR-IOV僅致使只有幾個百分點的性能提升，比咱們行業領先的裸機SBC實施還要少。然而，最使人滿意的是，修改後的DPDK OVS達到了SR-IOV的90％的性能。即便經過這種加速的vSwitch方案帶來了一些開銷，但這也可以理解，畢竟它們有助於部署的靈活性。

若是上面的描述讓你覺得SR-IOV和DPDK只能二選一的話，那我得道歉。你固然可使用SR-IOV把數據寫入到使用DPDK的虛擬機中。如前所述，您也能夠將DPDK加速vSwitch放入主機中，若是從部署的角度來看說的通的話，甚至能夠混合使用（和正確的SR-IOV目標VNF加上適當配置的NFV基礎架構管理器來處理這種複雜性）。這將仍然有待觀察。

因此，感謝Mr.Colton的建議，我學到了什麼？或者，更具體地說，我必須「忘掉」什麼？我瞭解到，SR-IOV能夠避免不止一個，而是兩個中斷和一個巨大的性能瓶頸。另外，我發現進程間通訊調用對於vSwitch是多麼的有害，並且DPDK將解決喝這個問題。總而言之，我就是這麼想的。

原文連接：https://www.metaswitch.com/blog/accelerating-the-nfv-data-plane

相關索引材料

1. Rev 1.1 was introduced in January 2010.

2. iWARP and later RoCE brought true RDMA to Ethernet, in answer to the threat of InfiniBand.

3. The Physical Function (PF - the Ethernet port itself) continues to include a complete PCIe implementation.

4. These are not the physical memory locations, as the VM is unaware of those, so Intel Virtualization Technology for Directed I/O (VT-d) is required to perform the mapping between the virtual address space and the physical one.

5. Andy Hill and Joel Preas from Rackspace at the OpenStack Paris Summit in November 2014.

6. http://www.6wind.com/products/6windgate/optimized-architecture/

7. http://www.slideshare.net/jstleger/dpdk-summit-2015-hp-al-sanders

8. http://www.metaswitch.com/the-switch/tackling-the-nfv-packet-performance-challenge