1.背景

隨著存儲設(shè)備的升級與發(fā)展，當(dāng)代的存儲設(shè)備性能越來越高，延遲也越來越低。對于內(nèi)核而言，Linux I/O 存儲棧的軟件所帶來的性能開銷已經(jīng)越來越不可忽視。同樣在 512B 的隨機讀條件下，在采用二代 Optane SSD 作為存儲設(shè)備的測試?yán)?中，內(nèi)核軟件（ Linux 存儲棧）所帶來的性能開銷已經(jīng)?達(dá) 50%。

2.傳統(tǒng)方式與XRP

我們來看?個實際的例?，假設(shè)現(xiàn)在有?棵樹?為 4 的 B+ tree 存儲于存儲設(shè)備當(dāng)中。當(dāng)我們從根節(jié)點出發(fā)，?共需要經(jīng)過三次訪盤才能獲得最終的葉?節(jié)點，?中間的索引節(jié)點對于?戶??沒有意義，但也需要經(jīng)過?個完整的存儲棧路徑。?每次訪盤的過程中，存儲棧所花費的開銷就要整個存儲路徑的 48.6%。

顯然，冗?的存儲棧路徑鉗制了?性能存儲設(shè)備的發(fā)揮，那么?個直觀的優(yōu)化思路便是通過 Kernel Bypass 的?式，繞開內(nèi)核中存儲棧，以提升存儲性能。?前在學(xué)術(shù)界中，對于這??的?作有 Demikernel、Shenango、Snap 等，??業(yè)界中最為?泛使?的則是 Intel 的 SPDK。

然?，Kernel Bypass 技術(shù)并?銀彈，它雖然能夠降低內(nèi)核存儲棧的開銷，但也存在著如下缺點：

1. 沒有適當(dāng)粒度的訪問控制

2. 需要采? polling ?式來判斷 I/O 是否完成，這會導(dǎo)致在 I/O 利?率低時，Polling 進(jìn)程所在的 CPU ?部分情況下只是在空轉(zhuǎn)，浪費 CPU 周期，同時 CPU 資源不能?效地在多進(jìn)程中共享。

所謂 XRP 的全稱是 eXpress Resubmission Path(快速重提交路徑)。與 SPDK 完全繞開內(nèi)核存儲棧，采? polling的?式來訪問存儲的?式不同，XRP 則是通過將中間請求直接在 NVMe 驅(qū)動層進(jìn)? resubmission，從?避免讓中間請求通過冗?的存儲棧后再提交，從?達(dá)到加速的?的。反映到上?的例?當(dāng)中，可以明顯地看到使? XRP 存儲訪問?式中，只有第?次請求和最后?次響應(yīng)會經(jīng)過?個完整的存儲棧路徑。顯然，在允許范圍內(nèi)，B+ tree的樹?越?，XRP 的加速效果也就越明顯。

既然優(yōu)化思路有了，那么應(yīng)當(dāng)如何才能將請求重提交于 NVMe 驅(qū)動層呢？這?可以借鑒 XDP 的實現(xiàn)思路。XDP 通過 eBPF 來實現(xiàn)對每個數(shù)據(jù)包進(jìn)?獨?的操作(數(shù)據(jù)包過濾、數(shù)據(jù)包轉(zhuǎn)發(fā)、數(shù)據(jù)包追蹤、?絡(luò)調(diào)度)。XRP 也可以通過 BPF 程序來實現(xiàn)。

XRP 是?個使? eBPF 來降低內(nèi)核存儲軟件開銷的系統(tǒng)。它所?臨的挑戰(zhàn)主要有：

1. 如何在 NVMe 驅(qū)動層實現(xiàn)對?件偏移的翻譯

2. 如何強化 eBPF verifier 以?持存儲應(yīng)?場景

3. 如何重新提交 NVMe 請求

4. 如何與應(yīng)?層 Cache 進(jìn)?交互

XRP 引?了?種新的 BPF 類型(BPF_PROG_TYPE_XRP)，包含了 5 個字段，分別是

1. char* data：?個緩沖區(qū)，?于緩沖從磁盤中讀取出來的數(shù)據(jù)

2. int done：布爾語意，表示 resubmission 邏輯是否應(yīng)當(dāng)返回給 user，還是應(yīng)當(dāng)繼續(xù) resubmitting I/O 請求

3. uint64_t next_addr[16]：邏輯地址數(shù)組，存放的是下次 resubmission 的邏輯地址

4. uint64_t size[16]：存放的是下次 resubmission 的請求的??5. char* scratch：user 和 BPF 函數(shù)的私有空間，?來傳遞從 user 到 BPF 函數(shù)的參數(shù)。BPF 函數(shù)也可以?這段

空間來保存中間數(shù)據(jù)。處于簡單考慮，默認(rèn) scratch 的??是 4KB。

同時，為了避免因存在?限循環(huán)?導(dǎo)致 BPF Verifier 驗證失敗，代碼中指定了 B+ tree 的最?扇出數(shù)為

MAX_FANOUT，其值為 16。

?前，最常?鏈?zhǔn)阶x請求主要有 B-Tree 和 LSM Tree 兩種，? XRP 分別繼承了 BPF-KV（?個簡易的基于 B+ Tree的鍵值存儲引擎） 和 WIREDTIGER（mongoDB 的后端鍵值存儲引擎）。

3.實驗測試

上圖為在 512B 隨機讀測試中，標(biāo)準(zhǔn) read 和 XRP 之間的性能對?測試?？梢钥吹诫S著線程數(shù)的增加，XRP 的吞吐保持線性增?的態(tài)勢，同時 XRP 通過降低每次 I/O 請求時的 CPU 開銷，從?緩解了 CPU 爭?問題。

上?兩幅圖中，同樣表示了在 512B 隨機讀測試中（CPU 核?數(shù)為 6），標(biāo)準(zhǔn) read、XRP 和 SPDK 之間的吞吐量以及尾延遲的對?。在線程數(shù)?于等于 CPU 核?數(shù)時，三者性能變化穩(wěn)定，從?到低依次為 SPDK > XRP >read。?當(dāng)線程數(shù)超過了核?數(shù)時，SPDK 性能開始出現(xiàn)嚴(yán)重的下跌，標(biāo)準(zhǔn) read 性能輕微下滑，? XRP 依然保持著穩(wěn)定的線性增?。這主要是因為 SPDK 采? polling 的?式訪問存儲設(shè)備的完成隊列，當(dāng)線程數(shù)超過核?數(shù)，線程之間對 CPU 的爭奪加上缺乏同步性，會導(dǎo)致所有線程都經(jīng)歷尾部延遲顯著提升和整體吞吐量的顯著下降。

4.總結(jié)

XRP 是?個將 BPF 應(yīng)?來通?存儲函數(shù)的加速上的系統(tǒng)，它既能享受到 kernel bypass 的性能優(yōu)勢，同時??須犧牲 CPU 的使?率和訪問控制。?前，XRP 團隊依然在積極地將 XRP 與其他?些流?的鍵值存儲引擎，如 RocksDB進(jìn)?集成。