日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
桃李春風(fēng)一杯酒，江湖夜雨十年燈-老兵夜話DPDK

20年彈指一揮間。技術(shù)在飛速的發(fā)展，從最初接觸ixp1200 的耳目一新，到如今DPDK， smart NIC的 如火如荼。我也已經(jīng)從昔日的青蔥少年，變成了兩鬢微霜的打工人。午夜夢回， 在感慨人生有如逆旅之余，心中也有很多想法不吐不快。

創(chuàng)新互聯(lián)服務(wù)熱線：028-86922220，為您提供成都網(wǎng)站建設(shè)網(wǎng)頁設(shè)計(jì)及定制高端網(wǎng)站建設(shè)服務(wù)，創(chuàng)新互聯(lián)網(wǎng)頁制作領(lǐng)域十多年，包括成都戶外休閑椅等多個方面擁有豐富建站經(jīng)驗(yàn)，選擇創(chuàng)新互聯(lián)，為企業(yè)保駕護(hù)航。

前傳

2000年是網(wǎng)絡(luò)處理器的黃金時代，Intel在那個時候也有一個Network Processor產(chǎn)品，名為IXP1200，主要是通過可編程的專用引擎來加速網(wǎng)絡(luò)報(bào)文處理。IXP1200/2400/2800本身帶有N個微引擎，可供編程。但是編程的難度很大，尤其是在高并發(fā)的情況下并不容易調(diào)試。

我們來看看IXP1200 和2800的架構(gòu)圖：

IXP 1200 是初代試水產(chǎn)品， 只有6個微引擎。其整體頻率也較低，約為233Mhz，所以只支持千兆網(wǎng)絡(luò)線速。

IXP 2800 就進(jìn)化到了16個微引擎. 微引擎頻率提高到1.2Ghz. 可以支持萬兆網(wǎng)絡(luò)線速。同時支持各類加密算法加速引擎。

這個產(chǎn)品線于2007年被出售給了Netronome公司，現(xiàn)在依然存在，而且已經(jīng)擴(kuò)充至60個甚至更多的微引擎。

https://www.netronome.com/products/agilio-fx/

每個微引擎又內(nèi)置了4-8個硬件線程，每個線程可以發(fā)起收包操作然后進(jìn)入等待模式調(diào)度器調(diào)度其它硬件線程運(yùn)行，直到I/O 操作完成 對應(yīng)的signal重新設(shè)置為可以調(diào)度(注意這一切都是硬件邏輯)下面是微引擎的內(nèi)部架構(gòu)

大家可以看到這個微引擎麻雀雖小五臟俱全，甚至帶有CAM (Content-addressable memory) 。

寄存器分為幾類：計(jì)算用的 通用GPR 以及IO用的xfer寄存器。有4k的空間存放代碼。有一定大小的本地緩存Local Mem。也有類似于中斷但又不完全一樣的signal機(jī)制。在這個螺螄殼里也可以寫出很多非常精巧的代碼，包括復(fù)雜的有限狀態(tài)機(jī)。下面是一段代碼示例。

估計(jì)大多數(shù)人都不太能看明白這段代碼。這其實(shí)就是微引擎編程的一個瓶頸-可讀性差與學(xué)習(xí)曲線陡峭。微引擎中的資源(各類寄存器，signal) 都是非常有限的，基本上都需要進(jìn)行手動的優(yōu)化，開發(fā)人員編碼時如履薄冰。寄存器耗盡是我那時的噩夢。絞盡腦汁也要騰挪出一些資源。學(xué)習(xí)的曲線之高直接導(dǎo)致的就是開發(fā)生態(tài)非常之小。同時開發(fā)工具，調(diào)試工具都必須是專有的。直接導(dǎo)致開發(fā)效率不高。這些其實(shí)也是專用的ASIC和網(wǎng)絡(luò)處理器普遍存在的問題。

挑戰(zhàn)到來

X86 CPU 在控制面處于統(tǒng)治地位，數(shù)據(jù)面則長期受制于FSB，PCI/PCIE 帶寬限制。2010年以后，隨著新一代X86 CPU性能的不斷增強(qiáng)(FSB被替代，DMI帶寬不斷增大)以及PCIE 2.0 推出。那么人們不禁要問。使用X86是否有可能達(dá)萬兆線速處理?這在當(dāng)時是一個巨大的疑問。普遍認(rèn)為是很難做到的。

首先來看看FSB的移除

FSB 全稱是 Front-side bus。如下圖所示， 主要是負(fù)責(zé)連接CPU 與北橋內(nèi)存控制器的總線技術(shù)。

FSB 橫亙在北橋(一般是內(nèi)存控制器Hub)與CPU之間。FSB不但掌管了對內(nèi)存的訪問同時也是PCIE通信的必經(jīng)之路。性能不具備水平擴(kuò)展性。作為控制平面是沒問題的。但是如果作為數(shù)據(jù)平面 就成了首要瓶頸。

再來看看之后的Sandy bridge 微架構(gòu)的樣子。FSB被移除， 內(nèi)存控制器直接整合到CPU之中， PCIE也升級到了2.0(這就意味著每個lane的帶寬升級到了 4Gbps)

揭開大幕

使用X86作為數(shù)據(jù)平面方案有很多福利：

  • X86 芯片通常有18個月?lián)Q代的，可以使得性能搭車18個月就獲得更新。一個最好的例子就是aes-ni，每一代aes-ni指令性能都有所增強(qiáng)。同理適用于sse/avx/avx2/avx512。(aes-ni 屬于X86的aes加密算法指令擴(kuò)展)
  • 虛擬化技術(shù)也是可以毫無障礙的搭順風(fēng)車來利用，從而節(jié)省單獨(dú)研發(fā)的費(fèi)用問題。
  • 同時因?yàn)槭荴86，整個技術(shù)生態(tài)是完備的。開發(fā)環(huán)境/調(diào)試環(huán)境都無需再使用專有的。大大增強(qiáng)了普適性同時也大大提高了效率以及升級換代的時間。例如 可以使用最先進(jìn)最好的編譯器技術(shù)。C語言的普及程度也是非常之高，學(xué)習(xí)曲線平緩。

隨著Sandy bridge 這代的X86 處理器發(fā)布， 之前的各種技術(shù)瓶頸貌似都有了松動的跡象。Venky Venkatesan(已故的DPDK之父) 腦海中的新一代的技術(shù)方案也逐漸成型。在經(jīng)過一段內(nèi)部的醞釀之后，2010-2012年 Intel完成架構(gòu)分析與設(shè)計(jì)。2013 年dpdk社區(qū)正式上線，從而在業(yè)內(nèi)成為了一個現(xiàn)象級的產(chǎn)品。

那么我們可以復(fù)盤一下 當(dāng)時 Venky 先生所面臨的挑戰(zhàn)(X86 萬兆線速)

  1. 萬兆線速基本上約等于15 MPPS(也就是1500萬個報(bào)文每秒)。那么CPU大約有67.2 ns的預(yù)算來轉(zhuǎn)發(fā)一個報(bào)文
  2. Sandybridge 主頻達(dá)到2.2Ghz是毫無困難的。困難應(yīng)該主要還是來自IO。FSB這個瓶頸已經(jīng)被替代。PCIE2.0 已經(jīng)開始支持。2M/1G的巨頁也開始支持!
  3. 但是如果回頭看軟件， 問題就很多了。如果通過傳統(tǒng)的內(nèi)核協(xié)議棧， 這一目標(biāo)完全是無法實(shí)現(xiàn)的。當(dāng)然內(nèi)核協(xié)議棧的設(shè)計(jì)哲學(xué)也并非是單純?yōu)榱诵阅?。通用性也是其重要考量。但是在這個特定的場景下就成為了最后一個瓶頸。

應(yīng)對挑戰(zhàn)

DPDK是一個典型的由量變到質(zhì)變的設(shè)計(jì)過程。它本質(zhì)上是眾多優(yōu)化方法的集合。單一的優(yōu)化方法，其實(shí)以前也已經(jīng)存在。比如 by pass kernel 的 net map。但是單一的優(yōu)化方法都不足以把性能提升到一個質(zhì)變的程度。DPDK則是集所有可以使用到的優(yōu)化方法之大成，把X86處理器的網(wǎng)絡(luò)處理能力推上了一個新的境界。

我們可以列出DPDK的優(yōu)化方法有(包含但不限于)：

  1. By pass 內(nèi)核協(xié)議棧。通過uio/vfio將網(wǎng)絡(luò)設(shè)備暴露給用戶層, 拋開通用的內(nèi)核路徑, 一身輕。(uio/vfio 是Linux內(nèi)核支持用戶層驅(qū)動的編程框架)
  2. 使用巨頁從而大大降低TLB miss帶來的性能損失。細(xì)節(jié)請參考(https://lwn.net/Articles/374424/)
  3. 廣泛的應(yīng)用批處理從而攤薄單個報(bào)文的開銷 (例如 使用simd優(yōu)化網(wǎng)卡驅(qū)動). 批處理的優(yōu)化思想在DPDK之中是一個極其常見的范式。
  4. 放棄中斷模式而轉(zhuǎn)而直接使用輪詢模式。這個對于降低時延非常重要。因?yàn)樵赑CIE總線上，中斷也是一個TLP報(bào)文過多的中斷也會影響真正數(shù)據(jù)的時延(尤其是小包)，中斷處理導(dǎo)致的上下文切換也會引起系統(tǒng)抖動。但是輪詢非?？简?yàn)內(nèi)存控制器和PCIE Root Complex的魯棒性。魯棒性差的平臺容易出問題。
  5. 魔改DDIO，網(wǎng)卡直接DMA數(shù)據(jù)到LLC(Last-Level Cache)中. DDIO對于小包的性能非常重要. 這個在今天依然是xeon的獨(dú)有功能(新一代的CLX協(xié)議中實(shí)現(xiàn)了DDIO的超集)，細(xì)節(jié)請參考“Linux閱碼場”公眾號前期文章《Linux 系統(tǒng)性能評測基準(zhǔn)系統(tǒng)配置及其原理》。
  6. 對齊對齊再對齊。預(yù)取預(yù)取再預(yù)取。極度重視cache的優(yōu)化。對齊主要是針對CacheLine 長度以及 PCIE的DMA地址。預(yù)取Prefetch 則較為難以把握精確的時間點(diǎn)， 需要反復(fù)的實(shí)驗(yàn)找到最佳位置。細(xì)節(jié)請參考Intel 軟件優(yōu)化手冊(https://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-optimization-reference-manual.html)
  7. 隔離Core 不讓Core參與操作系統(tǒng)的調(diào)度。減少抖動。禁止進(jìn)程切換，盡量減少系統(tǒng)調(diào)用，這些都會引起嚴(yán)重的抖動。細(xì)節(jié)請參考之前的公號文章(https://mp.weixin.qq.com/s/nkiE4CEo_zSN35I_qITAvQ)
  8. 針對X86微架構(gòu)。無所不用其極地進(jìn)行優(yōu)化。例如 write forwarding. 細(xì)節(jié)請參考Intel 軟件優(yōu)化手冊
  9. 廣泛使用二階遞進(jìn)的分區(qū)設(shè)計(jì)模式。盡量避免核間通信(例如mem pool/local pool etc) 細(xì)節(jié)請參考DPDK 官方文檔
  10. 廣泛使用無鎖隊(duì)列以及相關(guān)精巧的數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)。例如著名的rte_ring。細(xì)節(jié)請參考DPDK 官方文檔

經(jīng)過這樣層層遞進(jìn)聯(lián)合的優(yōu)化， DPDK終于站上了性能的巔峰。

但是故事并沒有結(jié)束。X86有一個比較突出的問題，就是關(guān)于價(jià)格。那么每一個X86 Xeon核心的價(jià)格并不便宜。所以當(dāng)一些業(yè)務(wù)流程逐漸沉淀下來比較固化以后，又可以重新的轉(zhuǎn)化為ASIC來處理。這樣就催生了各類的Smart NIC，繞了個圈又回到了IXP 。只是如今微引擎(或者類似的可編程組件)都集成進(jìn)了網(wǎng)卡。這些恰恰印證了技術(shù)的發(fā)展是一個螺旋上升的過程，永遠(yuǎn)是圍繞著性能/價(jià)格進(jìn)行動態(tài)平衡調(diào)整。

DPDK與內(nèi)核的關(guān)系

這個話題通常是一個DPDK廣泛被誤解的地方。我覺得既有競爭關(guān)系，但是又有非常密切的合作關(guān)系。

首先我們來談競爭。DPDK和Linux 內(nèi)核進(jìn)行競爭的僅僅是Linux內(nèi)核協(xié)議棧中關(guān)于包轉(zhuǎn)發(fā)處理的一小部分。那么這一部分由于Linux內(nèi)核協(xié)議棧性能常年非常的低下。當(dāng)然，這也是Linux 內(nèi)核的一些設(shè)計(jì)哲學(xué)導(dǎo)致的.其實(shí)并不算是設(shè)計(jì)失誤而是追求的目標(biāo)不同。那么這一部分確實(shí)是存在競爭關(guān)系，但是值得一提的是 DPDK同時也催生了Linux 內(nèi)核中的新的包處理框架XDP 以及AF_XDP這些新興的技術(shù)。也算是既競爭又促進(jìn)。關(guān)于某些內(nèi)核協(xié)議棧maintainer一些過于戲劇化的行為，竊以為看看就好， 畢竟想想DPDK的編碼風(fēng)格，開發(fā)管理流程， 大多還是跟隨內(nèi)核社區(qū)。

那么合作的這一部分呢?其實(shí)就非常之多了。

首先DPDK所用到的所有基礎(chǔ)架構(gòu)：

  1. UIO/VFIO/IOMMU這些框架無一不是由內(nèi)核來提供的。
  2. Hugepage 以及Systemmap 地址查找都是依賴內(nèi)核
  3. 所有的sysfs，不用說都要依賴。
  4. 電源管理的框架完全根植于cpufreq/idle 這兩個內(nèi)核的子系統(tǒng)
  5. 每次新一代的處理器的支持
  6. 周邊的生態(tài)linker loader debuger compiler perf etc
  7. 虛擬化的支持也要依賴kvm/qemu
  8. 你可以想到的更多。

展望未來

在通信技術(shù)高速發(fā)展的今天，DPDK 面臨很多新的挑戰(zhàn)：

  1. 使用如此高配得core來polling，浮點(diǎn)單元、極致的亂序引擎沒有充分發(fā)揮效用，同時價(jià)格上還是不便宜的，那么在性價(jià)比上就會面臨DPU的挑戰(zhàn)。最終應(yīng)該是多種方案并存的狀態(tài)。
  2. 100%的cpu占用使得真正的cpu使用比例很難被監(jiān)測到，同時能耗也是一個問題,當(dāng)然這個方面已經(jīng)有很多改進(jìn)的方案在社區(qū)進(jìn)行討論。
  3. 擴(kuò)展生態(tài)，開源的魯棒性高的協(xié)議棧仍然是稀缺的
  4. 同樣是生態(tài)問題，與控制平面的接口如何優(yōu)化也是一大方向。
  5. 在Cloud Native 的大趨勢下， 如何進(jìn)化、適應(yīng)。

這些問題都有待通過整個DPDK社區(qū)的繼續(xù)努力來解決。

參考

https://www.dpdk.org/wp-content/uploads/sites/35/2014/09/DPDK-SFSummit2014-HighPerformanceNetworkingLeveragingCommunity.pdf

http://dpdk.org

https://www.intel.com/content/www/us/en/io/data-direct-i-o-technology-brief.html

https://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-optimization-reference-manual.html

https://lwn.net/Articles/374424/

作者簡介

作者Liam，海外老碼農(nóng)，對應(yīng)用密碼學(xué)、CPU微架構(gòu)、高速網(wǎng)絡(luò)通信等領(lǐng)域都有所涉獵。

本文轉(zhuǎn)載自微信公眾號「Linux閱碼場」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系Linux閱碼場公眾號。


名稱欄目：桃李春風(fēng)一杯酒，江湖夜雨十年燈-老兵夜話DPDK
標(biāo)題來源：http://www.dlmjj.cn/article/djooiei.html