解鎖tRPC高效能密碼：網路方案簡介！

騰訊雲加社群發表於2022-06-08
Trpc密碼
導語 | 本文介紹了部分高效能網路方案，包括RDMA、HARP、io_uring等。從技術原理、落地可行性等方面，簡要地做出分析，希望能對此方面感興趣的開發者提供一些經驗和幫助。

一、背景

業務中經常會有這樣的場景：

隨著網路卡速率的提升（10G/25G/100G），以及部分業務對低延遲的極致追求（1ms/50us），目前的核心協議棧由於協議複雜、流程複雜、設計陳舊等因素，已經逐漸成為業務瓶頸。

業界已經有部分RDMA、DPDK的實踐，但是對於大多數開發者而言，依然比較陌生。

那麼這些方案各自的場景究竟怎樣？是否能夠為更多的業務賦能？以下是階段性簡要總結。

二、RDMA

（一）原理簡介

相對於傳統的網路協議棧，RDMA提供的關鍵特性即為：Kernel Bypass，也即利用專用的NIC（網路卡）進行硬體層面的協議傳輸、編解碼（Offload），通過記憶體對映技術直接與使用者態程式互動，從而避免了複雜低效的核心中介。

基於這種設計，隨之提供幾個額外的重要特性：

  • Zero-Copy：基於DMA操作，通訊全程沒有額外的CPU介入拷貝，從而降低CPU消耗。
  • 穩定低延遲：由於硬體通路的可靠性，從而保證了穩定的通訊延遲。
  • 多種傳輸模式：RC、RD、UC、UD等。基於不同業務的不同可靠性和效能需求，提供類似TCP/UDP的多種傳輸模式。

image.png

由於RDMA定位為高效能網路傳輸，同時也為了簡化硬體的設計，一般來說，RDMA會避免如軟體TCP那樣複雜的可靠性設計，而是極其依賴底層傳輸網路的可靠性。

根據不同的傳輸網路，RDMA的具體實現分為幾類：

image.png

image.png

另外補充說明：

  • 雖然RoCE v1/2依賴融合融合乙太網，也即無損傳輸，不過也有部分廠商的優化實現，可以減輕對無損傳輸的依賴。
  • Linux kernel 4.9+中，實現了Soft-RoCE，也即軟體版本的RoCE v2，主要用於測試、學習。

（二）RoCE v2 v.s. iWARP

在乙太網環境，主要可選項為RoCE v2和iWARP，相關對比如下：
image.png

目前來看，目前的機房網路建設中，對RoCE v2的支援更好，而iWARP卻仍然處於相對空白的狀態。

為此，當前的調研主要針對RoCE v2，而iWARP仍然有待探索。

（三）業務落地

後臺業務主流協議仍然是TCP，具有執行穩定、除錯工具豐富等優勢。不過對於少數期望高效能的業務，RDMA也是值得考慮的。

業務使用RDMA主要面臨兩方面的困難：

  • RoCE v2無損網路的要求導致難以跨機房傳輸，當前騰訊機房的支援為module內傳輸（如5跳之內）。
  • 全新的開發介面如libverbs、UCX等，業務軟體需要進行適配。

而有些儲存業務依賴多副本，網路傳輸需要能夠跨越MAN，甚至跨城市傳輸。這直接導致RoCE v2難以落地。

三、io_uring/socket

（一）原理簡介

io_uring是Linux 5.1+中支援的非同步IO框架，其核心優勢有：

  • 真正的非同步化設計（Proactor），而非如epoll等本質上的同步行為（Reactor）。而其關鍵在於，程式和kernel通過SQ/CQ兩個佇列進行解耦。
  • 統一的非同步IO框架，不僅支援儲存、網路。由於良好的擴充套件性，甚至可以支援任何的系統呼叫，如openat、stat等。
    image.png
    如前述，一個io_uring的例項，會建立一對核心和使用者程式共享的佇列，也即提交佇列SQ和完成佇列CQ，兩者皆為SPSC範型：
  • SQ：使用者態執行緒生產，然後系統呼叫（io_uring_enter）通知核心（io_wq kernel thread）消費。其中元素稱為SQE。
  • CQ：核心生產，然後通知（若使用者程式睡眠等待則喚醒）使用者態消費。其中元素稱為CQE。
    這其實是最常規也是最經典的非同步模型，在眾多非同步設計中可見。

一般情況下，CQE和SQE一一對應，不過io_uring支援multi-shot模式後則不一定如此。

另外，io_uring支援批量生產和消費，也即連續生產多個SQ後，一次性通知核心，或者持續消費CQ直到其空。

為了進一步優化部分場景的效能，io_uring支援眾多的高階特性：

  • File Registration：在反覆操作同一個fd時，加速其查詢對映。
  • Buffer Registration：在read/write等反覆需要在核心和使用者程式交換資料的場景，可以重複利用預註冊的一批記憶體。
  • Automatic Buffer Selection：為Proactor read預註冊一批記憶體，在就緒後核心自動選擇其中一塊存放資料，從而減少記憶體分配釋放，也節約記憶體資源。
  • SQ Polling：使核心（io_wq）輪詢SQ指定時間才睡眠，從而減少通知的系統呼叫。
  • IO Polling：開啟子系統（儲存、網路等）的輪詢模式（需要裝置驅動支援），從而加速部分高速裝置。另外可以配合io_uring_enter（flag：IORING_ENTER_GETEVENTS）進行忙等。
  • Multi-Shot：一次提交，多次完成，如只要一次提交socket accept，後續連線到來後多次返回。
  • io_uring在儲存IO場景，相對之前的阻塞IO、glibc aio、linux aio等，都有不錯的效能提升。

那麼在網路IO場景呢？是否優於epoll等方案呢？

（二）測試資料

經過調研，在知名開源軟體中，暫未發現直接採用io_uring進行網路IO的方案，如seastar/nginx等都沒有官方支援，既然可借鑑較少，那麼就自行測試。

由於io_uring還處於完善階段，而且對於網路IO的支援也有多種方式。目前我們梳理出其中3種：

  • Proactor：io_uring直接recv/send。
  • Reactor：io_uring接管socket_fd（POLL_ADD）後再recv/send。
  • io_uring接管epoll_fd後再epoll_wait再RECV/SEND：路徑繁瑣，推測效能不佳，直接略過。
    為此，我們針對前兩種io_uring模型，以及常用的epoll模型，進行測試對比。

為了利用更多的io_uring特性，測試採用當前最新kernel（5.15）。測試模型如下：

  • 通訊協議：tcp echo
  • 服務模型：單執行緒，非同步併發
  • 壓測客戶端：多執行緒，每個執行緒一個連線同步測試
  • 資料：包大小為512B
  • 測試環境：本機通訊loopback介面

epoll

image.png

  • io_uring（Proactor）
    image.png
  • io_uring（Reactor）

目前網上的很多程式採用此方式。不過從理論上分析，應該epoll效能接近，故暫未測試。

（三）資料分析

通過對比、分析以上的測試資料，可以得到以下結論：

  • io_uring在網路IO方面，並不比epoll效能強大。網路IO的主要瓶頸還是在於核心協議棧的開銷。

  • io_uring即使開啟核心輪詢，在負載低時可降低延時，而滿載效能提升不明顯，反而浪費了CPU資源。

    （四）業務落地

在Linux網路IO場景中，io_uring並不比epoll帶來額外的效能提升。這與儲存IO不同。

不過值得思考的是，如果一個系統中同時存在網路IO和儲存IO，對比以下兩種方式：

  • 網路IO採用epoll，儲存IO採用io_uring（可結合eventfd與epoll配合）
  • 網路IO、儲存IO都採用io_uring。

從理論上分析，方式2可以依賴io_uring批量提交等優化，從而進一步減少系統呼叫，是否可以帶來效能提升呢？

這部分需要進一步測試分析。

四、總結

以上簡單介紹了RDMA、io_uring/socket等方案，各有優缺點以及場景限制。後續將介紹DPDK的方案，敬請期待。

作者簡介

quintonwang，騰訊後臺開發工程師。

相關文章