[[356769]]

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

前傳

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

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

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

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

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

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

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

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

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

估計(jì)大多數(shù)人都不太能看明白這段代碼。這其實(shí)就是微引擎編程的一個(gè)瓶頸-可讀性差與學(xué)習(xí)曲線陡峭。微引擎中的資源(各類寄存器，signal) 都是非常有限的，基本上都需要進(jìn)行手動(dòng)的優(yōu)化，開發(fā)人員編碼時(shí)如履薄冰。寄存器耗盡是我那時(shí)的噩夢。絞盡腦汁也要騰挪出一些資源。學(xué)習(xí)的曲線之高直接導(dǎo)致的就是開發(fā)生態(tài)非常之小。同時(shí)開發(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)時(shí)是一個(gè)巨大的疑問。普遍認(rèn)為是很難做到的。

首先來看看FSB的移除

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

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

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

揭開大幕

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

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

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

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

1. 萬兆線速基本上約等于15 MPPS(也就是1500萬個(gè)報(bào)文每秒)。那么CPU大約有67.2 ns的預(yù)算來轉(zhuǎn)發(fā)一個(gè)報(bào)文
2. Sandybridge 主頻達(dá)到2.2Ghz是毫無困難的。困難應(yīng)該主要還是來自IO。FSB這個(gè)瓶頸已經(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)榱诵阅?。通用性也是其重要考量。但是在這個(gè)特定的場景下就成為了最后一個(gè)瓶頸。

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

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

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

1. By pass 內(nèi)核協(xié)議棧。通過uio/vfio將網(wǎng)絡(luò)設(shè)備暴露給用戶層, 拋開通用的內(nèi)核路徑, 一身輕。(uio/vfio 是Linux內(nèi)核支持用戶層驅(qū)動(dòng)的編程框架)
2. 使用巨頁從而大大降低TLB miss帶來的性能損失。細(xì)節(jié)請參考(https://lwn.net/Articles/374424/)
3. 廣泛的應(yīng)用批處理從而攤薄單個(gè)報(bào)文的開銷 (例如 使用simd優(yōu)化網(wǎng)卡驅(qū)動(dòng)). 批處理的優(yōu)化思想在DPDK之中是一個(gè)極其常見的范式。
4. 放棄中斷模式而轉(zhuǎn)而直接使用輪詢模式。這個(gè)對于降低時(shí)延非常重要。因?yàn)樵赑CIE總線上，中斷也是一個(gè)TLP報(bào)文過多的中斷也會(huì)影響真正數(shù)據(jù)的時(shí)延(尤其是小包)，中斷處理導(dǎo)致的上下文切換也會(huì)引起系統(tǒng)抖動(dòng)。但是輪詢非?？简?yàn)內(nèi)存控制器和PCIE Root Complex的魯棒性。魯棒性差的平臺(tái)容易出問題。
5. 魔改DDIO，網(wǎng)卡直接DMA數(shù)據(jù)到LLC(Last-Level Cache)中. DDIO對于小包的性能非常重要. 這個(gè)在今天依然是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 則較為難以把握精確的時(shí)間點(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)度。減少抖動(dòng)。禁止進(jìn)程切換，盡量減少系統(tǒng)調(diào)用，這些都會(huì)引起嚴(yán)重的抖動(dòng)。細(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有一個(gè)比較突出的問題，就是關(guān)于價(jià)格。那么每一個(gè)X86 Xeon核心的價(jià)格并不便宜。所以當(dāng)一些業(yè)務(wù)流程逐漸沉淀下來比較固化以后，又可以重新的轉(zhuǎn)化為ASIC來處理。這樣就催生了各類的Smart NIC，繞了個(gè)圈又回到了IXP 。只是如今微引擎(或者類似的可編程組件)都集成進(jìn)了網(wǎng)卡。這些恰恰印證了技術(shù)的發(fā)展是一個(gè)螺旋上升的過程，永遠(yuǎn)是圍繞著性能/價(jià)格進(jìn)行動(dòng)態(tài)平衡調(diào)整。

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

這個(gè)話題通常是一個(gè)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同時(shí)也催生了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 這兩個(gè)內(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ā)揮效用，同時(shí)價(jià)格上還是不便宜的，那么在性價(jià)比上就會(huì)面臨DPU的挑戰(zhàn)。最終應(yīng)該是多種方案并存的狀態(tài)。
2. 100%的cpu占用使得真正的cpu使用比例很難被監(jiān)測到，同時(shí)能耗也是一個(gè)問題,當(dāng)然這個(gè)方面已經(jīng)有很多改進(jìn)的方案在社區(qū)進(jìn)行討論。
3. 擴(kuò)展生態(tài)，開源的魯棒性高的協(xié)議棧仍然是稀缺的
4. 同樣是生態(tài)問題，與控制平面的接口如何優(yōu)化也是一大方向。
5. 在Cloud Native 的大趨勢下， 如何進(jìn)化、適應(yīng)。

這些問題都有待通過整個(gè)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閱碼場公眾號。