引 言
動機
2015年4月，第一屆dpdk中國峰會在北京成功召開。來自中國移動、中國電信、阿裡巴巴、ibm、intel、華為以及中興的專家朋友登台演講，一起分享了以dpdk為中心的技術主題。表1列出了2015 dpdk中國峰會的主題及演講者。
這次會議吸引了來自各行業、科研機關與高校的200多名開發人員、專家和企業代表參會。會上問答交流非常熱烈，會後我們就想，也許是時間寫一本介紹dpdk、探讨nfv資料面的技術書籍。現在，很多公司在招聘網絡和系統軟體人才時，甚至會将dpdk作為一項技能羅列在招聘要求中。dpdk從一個最初的小衆技術，經過10年的孕育，慢慢走來，直至今日已經逐漸被越來越多的通信、雲基礎架構廠商接受。同時，網際網路上也出現不少介紹dpdk基礎理論的文章和部落格，從不同的角度對dpdk技術進行剖析和應用，其中很多觀點非常新穎。作為dpdk的中國開發團隊人員，我們意識到如果能夠提供一本dpdk的書籍，進行一些系統性的梳理，将核心的原理進行深入分析，可以更好地加速dpdk技術的普及，觸發更多的軟體創新，促進行業的新技術發展。于是，就萌發了寫這本書的初衷。當然，我們心裡既有創作的激動驕傲，也有些猶豫忐忑，寫書不是一件簡單的事情，但經過讨論和考量，我們逐漸變得堅定，這是一本集結團隊智慧的嘗試。我們希望能夠把dpdk的技術深入淺出地解釋清楚，讓更多的從業人員和高校師生了解并使用dpdk，促進dpdk發展日新月異，興起百家争鳴的局面，這是我們最大的願景。
多核
2005年的夏天，剛加入intel的我們暢想着cpu多核時代的到來給軟體業帶來的挑戰與機會。如果要充分利用多核處理器，需要軟體針對并行化做大量改進，傳統軟體的并行化程度不高，在多核以前，軟體依靠cpu頻率提升自動獲得更高性能。并行化改進不是一件簡單的工作，許多軟體需要重新設計，基本很難在短期實作，整個計算機行業都對此糾結了很久。2005年以前，整個cpu的發展曆史，是不斷提升晶片運算頻率核心的做法，軟體性能會随着處理器的頻率升高，即使軟體不做改動，性能也會跟着上一個台階。但這樣的邏輯進入多核時代已無法實作。首先我們來看看表2所示的intel?多核處理器演進。
在過去10年裡，伺服器平台的處理器核心數目擴充了很多。表2參考了英特爾至強系列的處理器的核心技術演進曆史，這個系列的處理器主要面向雙通道（雙路）伺服器和相應的硬體平台。與此同時，基于mips、power、arm架構的處理器也經曆着類似或者更加激進的并行化計算的路線圖。在處理器飛速發展的同時，伺服器平台在硬體技術上提供了支撐。基于pci express的高速io裝置、記憶體通路與帶寬的上升相輔相成。此外，價格和經濟性優勢越發突出，今天一台雙路伺服器的價格可能和10年前一台高端筆記本電腦的價格類似，但計算能力達到甚至超越了當年的超級計算機。強大的硬體平台為軟體優化技術創新蘊蓄了溫床。
以太網接口技術也經曆了飛速發展。從早期主流的10mbit/s與100mbit/s，發展到千兆網（1gbit/s）。到如今，萬兆（10gbit/s）網卡技術成為資料中心伺服器的主流接口技術，近年來，intel等公司還推出了40gbit/s、100gbit/s的超高速網絡接口技術。而cpu的運作頻率基本停留在10年前的水準，為了迎接超高速網絡技術的挑戰，軟體也需要大幅度創新。
結合硬體技術的發展，dpdk（data plane development kit），一個以軟體優化為主的資料面技術應時而生，它為今天nfv技術的發展提供了絕佳的平台可行性。
ixp
提到硬體平台和資料面技術，網絡處理器是無法繞過的話題。電信行業通常使用網絡處理器或類似晶片技術作為資料面開發平台首選。intel此前也曾專注此領域，2002年收購了dec下屬的研究部門，在美國馬薩諸塞州哈德遜開發了這一系列晶片，誕生了行業聞名的intel exchange architecture network processor（ixp4xx、ixp12xx、ixp24xx、ixp28xx）産品線，曾取得行業市場占有率第一的成績。即使今日，相信很多通信業的朋友，還對這些處理器晶片有些熟悉或者非常了解。ixp内部擁有大量的微引擎（microengine），同時結合了xscale作為控制面處理器，衆所周知，xscale是以arm晶片為核心技術的一種擴充。
2006年，amd向intel發起了一場大戰，時至今日結局已然明了，intel依賴麾下的以色列團隊，打出了新一代core架構，迅速在能效比上完成超車。公司高層同時确立了tick-tock的研發節奏，每隔兩年推出新一代體系結構，每隔兩年推出基于新一代制造技術的晶片。這一戰略基本保證了每年都會推出新産品。當時amd的處理器技術一度具有領先地位，并觸發了intel在内部研發架構城門失火的狀況下不得不進行重組，就在那時intel的網絡處理器業務被進行重估，由于ixp晶片系列的市場容量不夠大，intel的架構師也開始預測，通用處理器多核路線有取代ixp專用處理晶片的潛力。自此，ixp的研發體系開始調整，逐漸轉向使用intel cpu多核的硬體平台，客觀上講，這一轉型為dpdk的産生創造了機會。時至今日，intel還保留并發展了基于硬體加速的quickassist技術，這和當日的ixp息息相關。由此看來，dpdk算是生于亂世。
dpdk的曆史
網絡處理器能夠迅速将資料封包接收入系統，比如将64位元組的封包以10gbit/s的線速也就是14.88mp/s（百萬封包每秒）收入系統，并且交由cpu處理，這在早期linux和伺服器平台上無法實作。以venky venkastraen、walter gilmore、mike lynch為核心的intel團隊開始了可行性研究，并希望借助軟體技術來實作，很快他們取得了一定的技術突破，設計了運作在linux使用者态的網卡程式架構。傳統上，網卡驅動程式運作在linux的核心态，以中斷方式來喚醒系統處理，這和曆史形成有關。早期cpu運作速度遠高于外設通路，是以中斷處理方式十分有效，但随着晶片技術與高速網絡接口技術的一日千裡式發展，封包吞吐需要高達10gbit/s的端口處理能力，市面上已經出現大量的25gbit/s、40gbit/s甚至100gbit/s高速端口，主流處理器的主頻仍停留在3ghz以下。高端遊戲玩家可以将cpu超頻到5ghz，但網絡和通信節點的設計基于能效比經濟性的考量，網絡裝置需要日以繼夜地運作，運作成本（包含耗電量）在總成本中需要重點考量，系統選型時大多選取2.5ghz以下的晶片，保證合适的成本效益。i/o超越cpu的運作速率，是橫在行業面前的技術挑戰。用輪詢來處理高速端口開始成為必然，這構成了dpdk運作的基礎。
在理論架構和核心技術取得一定突破後，intel與6wind進行了合作，交由在法國的軟體公司進行部分軟體開發和測試，6wind向intel傳遞了早期的dpdk軟體開發包。2011年開始，6wind、windriver、tieto、radisys先後宣布了對intel dpdk的商業服務支援。intel起初隻是将dpdk以源代碼方式分享給少量客戶，作為評估ia平台和硬體性能的軟體服務子產品，随着時間推移與行業的大幅度接受，2013年intel将dpdk這一軟體以bsd開源方式分享在intel的網站上，供開發者免費下載下傳。2013年4月，6wind聯合其他開發者成立www.dpdk.org的開源社群，dpdk開始走上開源的大道。
開源
dpdk在代碼開源後，任何開發者都被允許通過www.dpdk.org送出代碼。随着開發者社群進一步擴大，intel持續加大了在開源社群的投入，同時在nfv浪潮下，越來越多的公司和個人開發者加入這一社群，比如brocade、cisco、redhat、vmware、ibm，他們不再隻是dpdk的消費者，角色向生産者轉變，開始提供代碼，對dpdk的代碼進行優化和整理。起初dpdk完全專注于intel的伺服器平台技術，專注于利用處理器與晶片組進階特性，支援intel的網卡産品線系列。
dpdk 2.1版本在2015年8月釋出，幾乎所有行業主流的網卡裝置商都已經加入dpdk社群，提供源代碼級别支援。另外，除了支援通用網卡之外，能否将dpdk應用在特别的加速晶片上是一個有趣的話題，有很多工作在進行中，intel最新送出了用于crypto裝置的接口設計，可以利用類似intel的quickassit的硬體加速單元，實作一個針對資料包加解密與壓縮處理的軟體接口。
在多架構支援方面，dpdk社群也取得了很大的進展，ibm中國研究院的祝超博士啟動了将dpdk移植到power體系架構的工作，freescale的中國開發者也參與修改，tilera與ezchip的工程師也花了不少精力将dpdk運作在tile架構下。很快，dpdk從單一的基于intel平台的軟體，逐漸演變成一個相對完整的生态系統，覆寫了多個處理器、以太網和硬體加速技術。
在linux社群融合方面，dpdk也開始和一些主流的linux社群合作，并得到了越來越多的響應。作為linux社群最主要的貢獻者之一的redhat嘗試在fedora linux內建dpdk；接着redhat enterprise linux在安裝庫裡也加入dpdk支援，使用者可以自動下載下傳安裝dpdk擴充庫。redhat工程師還嘗試将dpdk與container內建測試，并公開釋出了運作結果。傳統虛拟化的上司者vmware的工程師也加入dpdk社群，負責vmxnet3-pmd子產品的維護。canonical在ubuntu 15中加入了dpdk的支援。
延伸
由于dpdk主體運作在使用者态，這種設計理念給linux或者freebsd這類作業系統帶來很多創新思路，也在linux社群引發一些讨論。
dpdk的出現使人們開始思考，linux的使用者态和核心态，誰更适合進行高速網絡資料封包處理。從簡單資料對比來看，在intel的通用伺服器上，使用單核處理小包收發，純粹的封包收發，理想模型下能達到大約57mp/s（每秒百萬包）。盡管在真實應用中，不會隻收發封包不處理，但這樣的性能相對linux的普通網卡驅動來說已經是遙不可及的高性能。openvswitch是一個很好的例子，作為主流的虛拟交換開源軟體，也嘗試用dpdk來建構和加速虛拟交換技術，dpdk的支援在ovs2.4中被釋出，開辟了在核心态資料通道之外一條新的使用者态資料通道。目前，經過20多年的發展，linux已經累積大量的開源軟體，具備豐富的協定和應用支援，無所不能，而資料封包進出linux系統，基本都是在linux核心态來完成處理。因為linux系統豐富強大的功能，相當多的生産系統（現有軟體）運作在linux核心态，這樣的好處是大量軟體可以重用，研發成本低。但也正因為核心功能強大豐富，其處理效率和性能就必然要做出一些犧牲。
使用
在專業的通信網絡系統中，高速資料進出速率是衡量系統性能的關鍵名額之一。大多通信系統是基于linux的定制系統，在保證明時性的嵌入式開發環境中開發出使用者态下的程式完成系統功能。利用dpdk的高速封包吞吐優勢，對接運作在linux使用者态的程式，對成本降低和硬體通用化有很大的好處，使得以軟體為主體的網絡裝置成為可能。對intel? x86通用處理器而言，這是一個巨大的市場機會。
對于通信裝置廠商，通用平台和軟體驅動的開發方式具有易采購、易更新、穩定性、節約成本的優點。
易采購：通用伺服器作為主流的基礎硬體，擁有豐富的采購管道和供應商，供貨量巨大。
易更新：軟體開發模式簡單，工具豐富，最大程度上避免系統更新中對硬體的依賴和更新，實作低成本的及時更新。
穩定性：通用伺服器平台已經通過大量功能的驗證，産品穩定性毋庸置疑。而且，對于專用的設計平台，系統穩定需要時間累積和大量測試，尤其是當采用新一代平台設計時可能需要硬體更新，這就會帶來穩定性的風險。
節約研發成本和降低複雜性：傳統的網絡裝置因為功能複雜和高可靠性需求，系統切分為多個子系統，每個子系統需要單獨設計和選型，獨立開發，甚至選用單獨的晶片。這樣的系統需要建構複雜的開發團隊、完善的系統規劃、有效的項目管理群組織協調，來確定系統開發進度。而且，由于開發的範圍大，各項目之間會産生路徑依賴。而基于通用伺服器搭建的網絡裝置可以很好地避免這些問題。
版權
dpdk全稱是data plane development kit，從字面解釋上看，這是專注于資料面軟體開發的套件。本質上，它由一些底層的軟體庫組成。目前，dpdk使用bsd license，絕大多數軟體代碼都運作在使用者态。少量代碼運作在核心态，涉及uio、vfio以及xendom0，kni這類核心子產品隻能以gpl釋出。bsd給了dpdk的開發者和消費者很大的自由，大家可以自由地修改源代碼，并且廣泛應用于商業場景。這和gpl對商業應用的限制有很大差別。作為開發者，向dpdk社群送出貢獻代碼時，需要特别注意license的定義，開發者需要明确license并且申明來源的合法性。
社群
參與dpdk社群［ref1-1］（www.dpdk.org）就需要了解它的運作機制。目前，dpdk的釋出節奏大體上每年釋出3次軟體版本（[email protected]），釋出計劃與具體時間會提前公布在社群裡。dpdk的開發特性也會在路标中公布，一般是通過電子郵件清單讨論[email protected]，任何參與者都可以自由送出新特性或者錯誤修正，具體規則可以參見www.dpdk.org/dev，本書不做詳細解讀。對于使用dpdk的技術問題，可以參與[email protected]進入讨論。
子子產品的維護者名單也會釋出到開源社群，便于查閱。在送出代碼時，源代碼以patch方式發送給[email protected]。通常情況下，代碼維護者會對送出的代碼進行仔細檢查，包括代碼規範、相容性等，并提供回報。這個過程全部通過電子郵件組的方式來完成，由于郵件量可能巨大，如果作者沒有得到及時回複，請嘗試主動聯系，提醒代碼維護人員關注，這是參與社群非常有效的方式。開發者也可以在第一次送出代碼時明确抄送相關的活躍成員和專家，以得到更加及時的回報和關注。
目前，開源社群的大量工作由很多自願開發者共同完成，是以需要耐心等待其他開發者來及時參與問答。通過提前研究社群運作方式，可以事半功倍。這對在校學生來說更是一個很好的鍛煉機會。及早參與開源社群的軟體開發，會在未來選擇工作時使你具有更敏銳的産業視角和技術深度。作為長期浸潤在通信行業的專業人士，我們強烈推薦那些對軟體有強烈興趣的同學積極參與開源社群的軟體開發。
貢獻
本書由目前dpdk社群中一些比較資深的開發者共同編寫，很多作者是第一次将dpdk的核心思想付諸于書面文字。盡管大家已盡最大的努力，但由于水準和能力所限，難免存在一些瑕疵和不足，也由于時間和版面的要求，很多好的想法無法在本書中較長的描述。但我們希望通過本書能夠幫助讀者了解dpdk的核心思想，引領大家進入一個豐富多彩的開源軟體的世界。在本書編纂過程中我們得到很多朋友的幫助，必須感謝上海交通大學的金耀輝老師、中國科學技術大學的華蓓和張凱老師、清華大學的陳渝教授、中國電信的歐亮博士，他們給了我們很多中肯的建議；另外還要感謝李訓和劉勇，他們提供了大量的資料和素材，幫助我們驗證了大量的dpdk執行個體；還要感謝我們的同僚楊濤、喻德、陳志輝、謝華偉、戴啟華、常存銀、劉長鵬、jim st leger、mjay、patrick lu，他們熱心地幫助勘定稿件；最後還要特别感謝英特爾公司網絡産品事業部的上司周曉梅和周林給整個寫作團隊提供的極大支援。正是這些熱心朋友、同僚和上司的支援，堅定了我們的信心，并幫助我們順利完成此書。最後我們衷心希望本書讀者能夠有所收獲。
目 錄
作者介紹
第一部分 dpdk基礎篇
<a href="https://yq.aliyun.com/articles/90266">第1章 認識dpdk</a>
<a href="https://yq.aliyun.com/articles/90266">1.1 主流包處理硬體平台</a>
1.1.1 硬體加速器
1.1.2 網絡處理器
1.1.3 多核處理器
<a href="https://yq.aliyun.com/articles/90281">1.2 初識dpdk</a>
1.2.1 ia不适合進行資料包處理嗎
1.2.2 dpdk最佳實踐
1.2.3 dpdk架構簡介
1.2.4 尋找性能優化的天花闆
<a href="https://yq.aliyun.com/articles/90288">1.3 解讀資料包處理能力</a>
<a href="https://yq.aliyun.com/articles/90291">1.4 探索ia處理器上最艱巨的任務</a>
<a href="https://yq.aliyun.com/articles/90297">1.5 軟體包處理的潛力——再識dpdk</a>
1.5.1 dpdk加速網絡節點
1.5.2 dpdk加速計算節點
1.5.3 dpdk加速存儲節點
1.5.4 dpdk的方法論
<a href="https://yq.aliyun.com/articles/90298">1.6 從融合的角度看dpdk</a>
<a href="https://yq.aliyun.com/articles/90317">1.7 執行個體</a>
1.7.1 helloworld
1.7.2 skeleton
1.7.3 l3fwd
<a href="https://yq.aliyun.com/articles/90321">1.8 小結</a>
<a href="https://yq.aliyun.com/articles/90334">第2章 cache和記憶體</a>
<a href="https://yq.aliyun.com/articles/90334">2.1 存儲系統簡介</a>
2.1.1 系統架構的演進
2.1.2 記憶體子系統
<a href="https://yq.aliyun.com/articles/90345">2.2 cache系統簡介</a>
2.2.1 cache的種類
2.2.2 tlb cache
<a href="https://yq.aliyun.com/articles/90353">2.3 cache位址映射和變換</a>
2.3.1 全關聯型cache
2.3.2 直接關聯型cache
2.3.3 組關聯型cache
<a href="https://yq.aliyun.com/articles/90356">2.4 cache的寫政策</a>
<a href="https://yq.aliyun.com/articles/90368">2.5 cache預取</a>
2.5.1 cache的預取原理
2.5.2 netburst架構處理器上的預取
2.5.3 兩個執行效率迥異的程式
2.5.4 軟體預取 38
<a href="https://yq.aliyun.com/articles/90377">2.6 cache一緻性</a>
2.6.1 cache line對齊
2.6.2 cache一緻性問題的由來
2.6.3 一緻性協定
2.6.4 mesi協定
2.6.5 dpdk如何保證cache一緻性
<a href="https://yq.aliyun.com/articles/90383">2.7 tlb和大頁</a>
<a href="https://yq.aliyun.com/articles/90383">2.7.1 邏輯位址到實體位址的轉換</a>
2.7.2 tlb
2.7.3 使用大頁
2.7.4 如何激活大頁
<a href="https://yq.aliyun.com/articles/90388">2.8 ddio</a>
2.8.1 時代背景
2.8.2 網卡的讀資料操作
2.8.3 網卡的寫資料操作
<a href="https://yq.aliyun.com/articles/90393">2.9 numa系統</a>
<a href="https://yq.aliyun.com/articles/90408">第3章 并行計算</a>
<a href="https://yq.aliyun.com/articles/90408">3.1 多核性能和可擴充性</a>
3.1.1 追求性能水準擴充
3.1.2 多核處理器
3.1.3 親和性
3.1.4 dpdk的多線程
<a href="https://yq.aliyun.com/articles/90414">3.2 指令并發與資料并行</a>
3.2.1 指令并發
3.2.2 單指令多資料
<a href="https://yq.aliyun.com/articles/90418">3.3 小結</a>
第4章 同步互斥機制
4.1 原子操作
4.1.1 處理器上的原子操作
4.1.2 linux核心原子操作
4.1.3 dpdk原子操作實作和應用
4.2 讀寫鎖
4.2.1 linux讀寫鎖主要api
4.2.2 dpdk讀寫鎖實作和應用
4.3 自旋鎖
4.3.1 自旋鎖的缺點
4.3.2 linux自旋鎖api
4.3.3 dpdk自旋鎖實作和應用
4.4 無鎖機制
4.4.1 linux核心無鎖環形緩沖
4.4.2 dpdk無鎖環形緩沖
4.5 小結
第5章 封包轉發
5.1 網絡處理子產品劃分
5.2 轉發架構介紹
5.2.1 dpdk run to completion模型
5.2.2 dpdk pipeline模型
5.3 轉發算法
5.3.1 精确比對算法
5.3.2 最長字首比對算法
5.3.3 acl算法
5.3.4 封包分發
5.4 小結
第6章 pcie與包處理i/o
6.1 從pcie事務的角度看包處理
6.1.1 pcie概覽
6.1.2 pcie事務傳輸
6.1.3 pcie帶寬
6.2 pcie上的資料傳輸能力
6.3 網卡dma描述符環形隊列
6.4 資料包收發——cpu和i/o的協奏
6.4.1 全景分析
6.4.2 優化的考慮
6.5 pcie的淨荷轉發帶寬
6.6 mbuf與mempool
6.6.1 mbuf
6.6.2 mempool
6.7 小結
第7章 網卡性能優化
7.1 dpdk的輪詢模式
7.1.1 異步中斷模式
7.1.2 輪詢模式
7.1.3 混和中斷輪詢模式
7.2 網卡i/o性能優化
7.2.1 burst收發包的優點
7.2.2 批處理和時延隐藏
7.2.3 利用intel simd指令進一步并行化包收發
7.3 平台優化及其配置調優
7.3.1 硬體平台對包處理性能的影響
7.3.2 軟體平台對包處理性能的影響
7.4 隊列長度及各種門檻值的設定
7.4.1 收包隊列長度
7.4.2 發包隊列長度
7.4.3 收包隊列可釋放描述符數量門檻值（rx_free_thresh）
7.4.4 發包隊列發送結果報告門檻值（tx_rs_thresh）
7.4.5 發包描述符釋放門檻值（tx_free_thresh）
7.5 小結
第8章 流分類與多隊列
8.1 多隊列
8.1.1 網卡多隊列的由來
8.1.2 linux核心對多隊列的支援
8.1.3 dpdk與多隊列
8.1.4 隊列配置設定
8.2 流分類
8.2.1 包的類型
8.2.2 rss
8.2.3 flow director
8.2.4 服務品質
8.2.5 虛拟化流分類方式
8.2.6 流過濾
8.3 流分類技術的使用
8.3.1 dpdk結合網卡flow director功能
8.3.2 dpdk結合網卡虛拟化及cloud filter功能
8.4 可重構比對表
8.5 小結
第9章 硬體加速與功能解除安裝
9.1 硬體解除安裝簡介
9.2 網卡硬體解除安裝功能
9.3 dpdk軟體接口
9.4 硬體與軟體功能實作
9.5 計算及更新功能解除安裝
9.5.1 vlan硬體解除安裝
9.5.2 ieee1588硬體解除安裝功能
9.5.3 ip tcp/udp/sctp checksum硬體解除安裝功能
9.5.4 tunnel硬體解除安裝功能
9.6 分片功能解除安裝
9.7 組包功能解除安裝
9.8 小結
第二部分 dpdk虛拟化技術篇
第10章 x86平台上的i/o虛拟化
10.1 x86平台虛拟化概述
10.1.1 cpu虛拟化
10.1.2 記憶體虛拟化
10.1.3 i/o虛拟化
10.2 i/o透傳虛拟化
10.2.1 intel? vt-d簡介
10.2.2 pcie sr-iov概述
10.3 pcie網卡透傳下的收發包流程
10.4 i/o透傳虛拟化配置的常見問題
10.5 小結
第11章 半虛拟化virtio
11.1 virtio使用場景
11.2 virtio規範和原理
11.2.1 裝置的配置
11.2.2 虛拟隊列的配置
11.2.3 裝置的使用
11.3 virtio網絡裝置驅動設計
11.3.1 virtio網絡裝置linux核心驅動設計
11.3.2 基于dpdk使用者空間的virtio網絡裝置驅動設計以及性能優化
11.4 小結
第12章 加速包處理的vhost優化方案
12.1 vhost的演進和原理
12.1.1 qemu與virtio-net
12.1.2 linux核心态vhost-net
12.1.3 使用者态vhost
12.2 基于dpdk的使用者态vhost設計
12.2.1 消息機制
12.2.2 位址轉換和映射虛拟機記憶體
12.2.3 vhost特性協商
12.2.4 virtio-net裝置管理
12.2.5 vhost中的checksum和tso功能解除安裝
12.3 dpdk vhost程式設計執行個體
12.3.1 封包收發接口介紹
12.3.2 使用dpdk vhost lib進行程式設計
12.3.3 使用dpdk vhost pmd進行程式設計
12.4 小結
第三部分 dpdk應用篇
第13章 dpdk與網絡功能虛拟化
13.1 網絡功能虛拟化
13.1.1 起源
13.1.2 發展
13.2 opnfv與dpdk
13.3 nfv的部署
13.4 vnf部署的形态
13.5 vnf自身特性的評估
13.5.1 性能分析方法論
13.5.2 性能優化思路
13.6 vnf的設計
13.6.1 vnf虛拟網絡接口的選擇
13.6.2 ivshmem共享記憶體的pci裝置
13.6.3 網卡輪詢和混合中斷輪詢模式的選擇
13.6.4 硬體加速功能的考慮
13.6.5 服務品質的保證
13.7 執行個體解析和商業案例
13.7.1 virtual bras
13.7.2 brocade vrouter 5600
13.8 小結
第14章 open vswitch（ovs）中的dpdk性能加速
14.1 虛拟交換機簡介
14.2 ovs簡介
14.3 dpdk加速的ovs
14.3.1 ovs的資料通路
14.3.2 dpdk加速的資料通路
14.3.3 dpdk加速的ovs性能比較
14.4 小結
第15章 基于dpdk的存儲軟體優化
15.1 基于以太網的存儲系統
15.2 以太網存儲系統的優化
15.3 spdk介紹
15.3.1 基于dpdk的使用者态tcp/ip棧
15.3.2 使用者态存儲驅動
15.3.3 spdk中iscsi target實作與性能
15.4 小結
附錄a 縮略詞
附錄b 推薦閱讀