做高性能網(wǎng)絡(luò)加速的這幾年XDP和eBPF基本已經(jīng)成了我工具箱里最常被翻牌的兩件家伙。XDP全名是eXpress Data Path靠的是eBPF這種既安全又靈活的內(nèi)核可編程能力讓業(yè)務(wù)流量在網(wǎng)絡(luò)驅(qū)動層就被加速或過濾掉。今天這篇我不打算堆概念直接結(jié)合我自己在服務(wù)器上做流量治理和抗抖動的實際經(jīng)歷聊清楚XDP到底能做什么、怎么選、怎么搭、怎么寫、怎么調(diào)速最后送上一份能直接抄作業(yè)的排坑手冊。1. XDP到底在解決什么問題1.1 傳統(tǒng)內(nèi)核網(wǎng)絡(luò)棧的開銷在哪先說說問題本身。在Linux上做網(wǎng)絡(luò)處理默認路徑大概是網(wǎng)卡收到報文DMA進來驅(qū)動把包描述符寫好觸發(fā)硬中斷然后NAPI在軟中斷上下文里分配skb、把數(shù)據(jù)從ring buffer往協(xié)議棧送緊接著是IP層、TCP/UDP層最后進socket隊列等應(yīng)用來讀。這套流程本身很成熟但代價也很明確每收一個包內(nèi)核都要分配一個skb描述符經(jīng)歷路由查找、netfilter鉤子、各種統(tǒng)計和鎖才能到達應(yīng)用。對于幾個Gbps的大流量這套路徑在多數(shù)服務(wù)器上問題不大?？梢坏┡錾厦棵氚偃f級包Mpps的場景比如DDoS清洗、網(wǎng)關(guān)轉(zhuǎn)發(fā)、高頻交易的前置網(wǎng)關(guān)問題就徹底暴露了。內(nèi)核其實不是按流量算開銷也不是按字節(jié)數(shù)算開銷而是近似按包數(shù)算開銷。一個64字節(jié)的小包真正有效載荷沒多少但內(nèi)核為該包付出的CPU代價一點也不少——分配skb、軟中斷調(diào)度、協(xié)議棧解析、鎖競爭這些固定成本足以把CPU打滿。我以前一臺24核的機器跑滿10G線速小包時CPU軟中斷能吃掉十幾個核業(yè)務(wù)幾乎不干活了。這還只是收包如果中間還要過濾、統(tǒng)計、改包那傳統(tǒng)協(xié)議棧路徑上的每一步都是成本。這也是為什么很多人開始往XDP和DPDK這些方案上靠。1.2 XDP的位置比內(nèi)核協(xié)議棧更早一步XDP的思路非常直接不讓你走到skb分配和協(xié)議棧那一步。網(wǎng)卡驅(qū)動收到報文后在NAPI收包流程的起點、也就是還沒為這個包分配skb的時候先執(zhí)行一段eBPF程序。這段程序可以通過自行解析以太網(wǎng)頭、IP頭、甚至四層頭決定這個包接下來是丟棄、放行還是轉(zhuǎn)發(fā)到另一個網(wǎng)卡。這句話里有兩個關(guān)鍵點。第一程序執(zhí)行位置在驅(qū)動內(nèi)部報文數(shù)據(jù)還留在驅(qū)動ring buffer的內(nèi)存里沒有經(jīng)過完整協(xié)議棧也沒有產(chǎn)生skb所以單個包的處理成本可以壓到極低。第二你的處理邏輯并不是寫死的內(nèi)核代碼而是一個eBPF程序由內(nèi)核驗證后運行在驅(qū)動收包路徑上。這意味著你可以像寫普通C代碼一樣寫過濾、統(tǒng)計、轉(zhuǎn)發(fā)邏輯然后在不改內(nèi)核、不重啟機器的情況下動態(tài)掛到網(wǎng)卡上。對我來說它能解決一個很現(xiàn)實的問題以前遇到流量抖動想臨時加個丟包策略要么改iptables規(guī)則要么改程序發(fā)版現(xiàn)在直接在XDP層加個規(guī)則就可以瞬時生效等風(fēng)頭過了再摘掉。單憑這一點線上網(wǎng)絡(luò)治理的姿勢就舒服了很多。2. 核心機制四種模式、五個動作與eBPF的關(guān)鍵選擇2.1 XDP的三種執(zhí)行模式XDP不是一個單一的路徑它有幾種執(zhí)行模式我一開始也被這個繞暈過先給你列一張對照表模式執(zhí)行位置驅(qū)動要求性能典型適用場景native XDP網(wǎng)卡驅(qū)動收包路徑內(nèi)驅(qū)動必須支持XDP hook最高支持XDP的物理網(wǎng)卡如mlx5、i40e/ice、ixgbe等generic XDP內(nèi)核協(xié)議棧收包路徑中模擬執(zhí)行無特殊要求虛擬設(shè)備也能用較低接近傳統(tǒng)路徑快速驗證、veth、不支持原生XDP的設(shè)備offload XDP網(wǎng)卡硬件/固件中執(zhí)行網(wǎng)卡需支持XDP offload不占CPU極高性能智能網(wǎng)卡、可編程NICnative模式是主戰(zhàn)場它掛在驅(qū)動收包的最前端性能收益最明顯。generic模式本質(zhì)是在skb已經(jīng)分配后、協(xié)議棧處理前插入一個模擬的eBPF執(zhí)行點性能遠不如native好處是兼容性極強連veth這種虛擬設(shè)備都能掛。offload模式聽起來最誘人能把程序燒進網(wǎng)卡去跑CPU完全不動但前提是你的網(wǎng)卡得支持且程序不能調(diào)用太復(fù)雜的helper和尾調(diào)用實際約束還挺多的。一般做生產(chǎn)優(yōu)化我基本默認只看native。2.2 XDP返回動作與場景選擇eBPF程序執(zhí)行完必須返回一個int值告訴內(nèi)核怎么處理這個包。XDP的動作就五個XDP_DROP、XDP_PASS、XDP_TX、XDP_REDIRECT和XDP_ABORTED。XDP_DROP控制在驅(qū)動層直接丟包這是低成本抗DDoS、限速、丟特定來源流量的核心手段。XDP_PASS是把包交回常規(guī)內(nèi)核協(xié)議棧相當(dāng)于你的程序只做觀測、審計或攔截部分流量其余正常走。XDP_TX用于從收到該包的網(wǎng)卡上原路發(fā)送出去適合做簡單的反射/回環(huán)。XDP_REDIRECT最強可以重定向到其他網(wǎng)卡、其他CPU隊列或者AF_XDP socket適合做轉(zhuǎn)發(fā)、負載均衡、零拷貝到用戶態(tài)。XDP_ABORTED類似XDP_DROP但會額外觸發(fā)一個tracepoint方便把異常包記錄下來排查問題。選動作不只是寫個返回值它還直接影響后續(xù)的工程復(fù)雜度。我建議新手不要一上來就沖REDIRECT先把DROP和PASS玩明白這兩個動作讓XDP變成“可以線上做實驗的丟包加速器”風(fēng)險也最低。2.3 為什么偏偏選eBPFXDP本身是一個hook點真正靈活在eBPF。eBPF程序有四個特性很適合網(wǎng)絡(luò)加速一是內(nèi)核驗證器會在加載時做完整的安全性檢查不會讓你像寫內(nèi)核模塊一樣把系統(tǒng)搞崩二是JIT編譯后直接變機器碼執(zhí)行沒有解釋執(zhí)行的性能赤字三是用map作為內(nèi)核態(tài)與用戶態(tài)共享數(shù)據(jù)的通道可以做統(tǒng)計、配置下發(fā)四是程序支持helper調(diào)用和尾跳轉(zhuǎn)表達能力足夠覆蓋常見的包處理邏輯。這些特性疊加起來才有了“XDP eBPF”這種兼顧性能、安全和可維護性的組合。對比一下傳統(tǒng)內(nèi)核模塊雖然也能在驅(qū)動層做包處理性能同樣很好但寫錯一個指針就是panic而且還要隨內(nèi)核版本維護ABI生產(chǎn)環(huán)境沒人愿意隨便加載。eBPF的驗證器雖然時不時會把你精心寫的代碼拒掉但這種“安全上的苛刻”恰好是它能在生產(chǎn)環(huán)境長期存在的前提。3. 動手前先確認內(nèi)核、網(wǎng)卡與工具鏈3.1 內(nèi)核版本與網(wǎng)卡硬件確認動手之前先把環(huán)境檢查清楚否則后面出了怪問題你都不知道往哪個方向排查。內(nèi)核版本不用追最新但要足夠支持你想用的特性基礎(chǔ)XDP和BCC在4.8之后就能用AF_XDP建議5.4以上io_uring與AF_XDP聯(lián)動則要更新版本。生產(chǎn)環(huán)境我一般建議至少5.10或更高內(nèi)核長期穩(wěn)定版本別為了一個有意思的特性上了非常新的內(nèi)核結(jié)果跟自己的應(yīng)用組件不兼容。網(wǎng)卡是否支持native XDP用ethtool -i eth0看驅(qū)動名稱再確認一下驅(qū)動是否實現(xiàn)了XDP hook。常見的mlx5_core、i40e/ice、ixgbe、bnx2x、ena這些驅(qū)動都有不錯的XDP支持。查看網(wǎng)卡當(dāng)前隊列數(shù)用ethtool -l eth0想看有沒有丟包錯誤用ethtool -S eth0 | grep -i rx。如果沒有物理網(wǎng)卡也不影響學(xué)習(xí)可以用veth pair配合generic模式跑通全流程。veth的native XDP支持在一些新內(nèi)核上也可以測但版本差異較大所以單純?yōu)榱蓑炞C邏輯generic模式是更省心的路徑。記住一句話先確認模式再開始寫程序。3.2 開發(fā)與加載工具鏈怎么選XDP開發(fā)工具有好幾套最常見的三條路線BCC、libbpf和原生iproute2。BCCBPF Compiler Collection適合快速做原型驗證Python封裝加上Clang后端寫起來很輕松但生產(chǎn)環(huán)境部署bcc依賴庫比較重版本間行為差異也不小。libbpf是正經(jīng)生產(chǎn)路線配合bpftool在編譯期生成vmlinux.h直接編一個自包含的.o文件運行時不需要clang和llvm是目前社區(qū)的主流。直接用ip link set dev eth0 xdp obj xxx.o加載其實和libbpf方式殊途同歸因為iproute2內(nèi)部就是調(diào)用libbpf做的加載。我個人經(jīng)驗是寫原型用BCC一旦要放生產(chǎn)或者要長期維護立刻遷到libbpf這樣可以保證程序在自己服務(wù)器上只依賴內(nèi)核特性不依賴一堆用戶態(tài)庫。加載和查看狀態(tài)的命令只需要iproute2、bpftool、ethtool三件套不需要額外裝太重的東西。4. 實操從零寫一個可用的XDP丟包計數(shù)程序4.1 找一個合適的最小案例講了半天原理總要落地跑一下。我挑個最簡單的場景把來源IP為192.0.2.0/24的包直接丟掉同時用map統(tǒng)計被丟棄的包數(shù)量。為什么選這個案例因為邏輯簡單代碼短還能順帶把map的使用演示出來。語言我選C libbpf的方式編譯出一個xdp_drop_counter.o通過ip命令加載到eth0上。程序要做的事拆一下就是三步先從網(wǎng)絡(luò)數(shù)據(jù)中取到以太網(wǎng)頭識別IPv4再從IP頭里拿出源地址然后匹配規(guī)則命中就返回XDP_DROP否則XDP_PASS。這里比較關(guān)鍵的一點是XDP程序里不能隨便用系統(tǒng)庫和普通內(nèi)存操作只能通過bpf helpers訪問數(shù)據(jù)包內(nèi)存所以校驗包長度、手動計算IP頭偏移這些步驟都省不了。4.2 完整代碼與編譯過程下面是我實際跑通過的一個版本基于vmlinux.h libbpf針對當(dāng)前主流內(nèi)核做了適配#include vmlinux.h #include bpf/bpf_helpers.h #include bpf/bpf_endian.h struct { __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY); __uint(max_entries, 1); __type(key, __u32); __type(value, __u64); } drop_count SEC(.maps); SEC(xdp) int xdp_drop_counter(struct xdp_md *ctx) { void *data (void *)(long)ctx-data; void *data_end (void *)(long)ctx-data_end; struct ethhdr *eth; struct iphdr *ip; eth data; if ((void *)eth sizeof(*eth) data_end) return XDP_PASS; if (eth-h_proto ! bpf_htons(ETH_P_IP)) return XDP_PASS; ip (void *)eth sizeof(*eth); if ((void *)ip sizeof(*ip) data_end) return XDP_PASS; if ((ip-saddr bpf_htonl(0xffffff00)) bpf_htonl(0xc0000200)) { __u32 key 0; __u64 *cnt bpf_map_lookup_elem(drop_count, key); if (cnt) __sync_fetch_and_add(cnt, 1); return XDP_DROP; } return XDP_PASS; } char _license[] SEC(license) GPL;這里有一個我特意保留的小細節(jié)開頭凡是訪問數(shù)據(jù)包內(nèi)存都要先做邊界檢查比一下當(dāng)前指針加結(jié)構(gòu)體大小是否小于data_end。eBPF驗證器對越界訪問零容忍不加這個判斷程序根本加載不上。用PERCPU_ARRAY而不是普通ARRAY是為了讓每個CPU各自累加免掉鎖競爭。生成vmlinux.h一行命令bpftool btf dump file /sys/kernel/btf/vmlinux format c vmlinux.h編譯則用clang指定BPF targetclang -O2 -g -Wall -target bpf -c xdp_drop_counter.c -o xdp_drop_counter.o4.3 加載、驗證與卸載操作編譯出的.o文件直接用ip命令加載ip link set dev eth0 xdp obj xdp_drop_counter.o sec xdp加載后想看程序有沒有真的生效用bpftoolbpftool prog show | grep xdp bpftool net showbpftool net show如果看到eth0(xdp)那一行帶prog id說明native掛載成功。想查看map里統(tǒng)計到的丟包數(shù)量可以先查到map id再用bpftool map dump查看各CPU的計數(shù)。測試方法我的習(xí)慣是單獨起一個測試網(wǎng)段做模擬流量用ping和iperf3分別從白名單和黑名單來源打過來確認該丟的丟、該放行的放行。測試完要清理現(xiàn)場就一條命令ip link set dev eth0 xdp off這個卸載操作比改iptables鏈條更干凈因為程序掛在驅(qū)動路徑上不涉及連接跟蹤和協(xié)議棧狀態(tài)切換很快回滾更快。這也是我為什么說XDP適合線上做“外科手術(shù)”式的手段。4.4 這類程序的性能變化在哪里加了這個XDP程序后性能收益主要不在吞吐峰值而在CPU消耗。同樣是10G流量下的小包風(fēng)暴如果丟包規(guī)則寫在傳統(tǒng)iptables的netfilter鉤子上每個包都要走過skb分配和部分協(xié)議棧路徑而寫在XDP上包從ring buffer進來eBPF程序讀完頭就返回DROPCPU只花極少的指令就能消滅這個包。我自己實測過一個非常簡單的DROP程序在普通雙路服務(wù)器上單核能做到幾Mpps的處理量比走完整協(xié)議棧省下了一個數(shù)量級的CPU開銷。當(dāng)然這個數(shù)據(jù)跟機型和代碼復(fù)雜度強相關(guān)重點理解它“省在工作沒有發(fā)生”這件事上。業(yè)務(wù)邏輯越簡單收益越明顯。5. 性能調(diào)優(yōu)從能跑到線速的正確姿勢5.1 隊列、CPU綁定與RSS多隊列XDP程序默認在每個收包的中斷CPU上執(zhí)行也就是說進來的流量要盡量均勻地分攤到多個CPU核上程序才有橫向擴展性。這就要靠網(wǎng)卡RSS多隊列了。先用ethtool -l eth0查看當(dāng)前combined隊列數(shù)量如果只有一個隊列用ethtool -L eth0 combined 8把它擴出來。然后配合IRQ和RPS把各隊列的中斷綁定到不同物理核上盡量避免兩個隊列搶一個核。這里有個常見誤區(qū)很多人以為綁核只是“把進程的CPU affinity設(shè)一下”就完了。但XDP的觸發(fā)點是軟中斷路徑而不是用戶態(tài)進程所以真正要做的是調(diào)整網(wǎng)卡IRQ的CPU親和性讓每個隊列的NAPI線程固定跑在指定的CPU上。irqbalance這類自動均衡工具在高負載下反而會搗亂建議在關(guān)鍵機器上停掉它手工分配中斷綁定效果要穩(wěn)定很多。5.2 NAPI輪詢與Busy Poll的取舍內(nèi)核默認的NAPI收包機制是“中斷加輪詢結(jié)合”第一個包來觸發(fā)硬中斷之后進入輪詢一段時間盡量攢一批包一次性處理。這套機制對吞吐很友好但延遲上會有微小抖動。如果你的場景對延遲特別敏感可以調(diào)busy poll配置讓軟中斷忙等ring buffer中的包避免每次都走中斷。但這又是個權(quán)衡題busy poll讓CPU在空轉(zhuǎn)等待單個隊列的pps上去了但CPU占用也會升高。實際調(diào)優(yōu)時我不會直接全開而是在具體機器上用perf和bpftool觀察軟中斷時間占比、NAPI poll次數(shù)、每次poll處理包數(shù)量再決定要不要把net.core.busy_poll這些參數(shù)調(diào)大。生產(chǎn)經(jīng)驗是一邊壓測一邊調(diào)調(diào)完看P99延遲和CPU空閑率兩個指標一起建基線別只看一個數(shù)。5.3 走向XDP_REDIRECT與AF_XDP的零拷貝如果只是丟包和放行XDP其實只發(fā)揮了一小半能力。真正把它變成“加速器”的是重定向。XDP_REDIRECT可以把包從一個網(wǎng)卡收進來后通過ndo_xdp_xmit重定向到另一個網(wǎng)卡發(fā)出去CPU在整個過程中不需要把包復(fù)制到用戶態(tài)再復(fù)制回去這對網(wǎng)關(guān)類應(yīng)用非常關(guān)鍵。還有個方向是AF_XDP。它通過XDP_UMEM在用戶態(tài)預(yù)先注冊一段內(nèi)存池驅(qū)動把收到的包直接DMA到這段內(nèi)存里再通過特殊的socket告訴用戶態(tài)“這個包可以讀了”省掉了內(nèi)核態(tài)到用戶態(tài)的數(shù)據(jù)拷貝。配合新版內(nèi)核的io_uring優(yōu)化AF_XDP在轉(zhuǎn)發(fā)、抓包、防火墻用戶態(tài)處理這些場景里已經(jīng)是DPDK之外很有競爭力的方案。當(dāng)然代價是你需要重新設(shè)計用戶態(tài)收包循環(huán)工程復(fù)雜度比單純XDP高不少適合團隊確實有硬性能瓶頸時再去啃。5.4 XDP與DPDK怎么選這兩個方案經(jīng)常被放在一塊兒比。選型我按自己的經(jīng)驗給個簡表維度XDPDPDK數(shù)據(jù)面位置內(nèi)核驅(qū)動層完全繞開內(nèi)核接管網(wǎng)卡CPU占用正常PASS/DROP時開銷極低REDIRECT也遠小于協(xié)議棧輪詢模式會占滿對應(yīng)CPU開發(fā)維護eBPF C libbpf有驗證器保護用戶態(tài)輪詢網(wǎng)卡配置復(fù)雜度高與內(nèi)核網(wǎng)絡(luò)棧結(jié)合天然保留PASS路徑可回退協(xié)議?；竞透邔訁f(xié)議棧隔離部署風(fēng)險相對低掛載/卸載像開關(guān)網(wǎng)卡被接管后常規(guī)協(xié)議棧失效影響面大適用場景流量治理、負載均衡、小包過濾、網(wǎng)關(guān)加速高性能轉(zhuǎn)發(fā)、DPVS、用戶態(tài)協(xié)議棧重構(gòu)一句話我常跟同事說如果目標是“讓現(xiàn)有內(nèi)核網(wǎng)絡(luò)棧跑得更快”優(yōu)先XDP如果目標是“干脆不用內(nèi)核網(wǎng)絡(luò)?！痹偃タ紤]DPDK的工程量。6. 常見問題速查與排坑筆記6.1 XDP程序加載失敗怎么辦最典型的錯誤是驅(qū)動不支持native XDP導(dǎo)致ip命令報“offload”或者驅(qū)動不識別之類的問題。這時候先用generic模式驗證功能ip link set dev eth0 xdpgeneric obj xx.o sec xdp。如果generic能掛上而native掛不上基本可以斷定是網(wǎng)卡驅(qū)動不支持要么換設(shè)備要么保持generic并接受性能損失。還有一種是程序本身被verifier拒了。報錯的字符串里一般會寫明“invalid access”“R1 typectx”之類的信息這就要回到代碼檢查data/data_end邊界判斷。舊內(nèi)核上如果bpf_jit沒開也可能出現(xiàn)一些奇怪的加載失敗用sysctl net.core.bpf_jit_enable確認一下。6.2 程序掛上了但丟包行為不生效掛載成功后丟包不生效我碰到的原因通常有幾種一是程序掛在generic模式上而流量被更高層的東西提前接管了邏輯上繞過了這個hook二是規(guī)則里對IP頭偏移算錯了比如沒考慮VLAN頭或者IPv6流量根本沒進你的匹配分支三是被丟的包其實是在其他網(wǎng)卡或者其他CPU的隊列上處理的而你把程序只掛在了一個網(wǎng)卡。排查思路也很直接先用bpftool net show確認prog確實掛在目標網(wǎng)卡上再用一個最簡單的“見包就DROP”的程序做對照實驗確認路徑通了再逐步加規(guī)則。這樣能最快把問題邊界劃出來。6.3 verifier常見拒絕原因?qū)慩DP程序我最常踩的verifier坑是這幾個忘記檢查包長度導(dǎo)致越界讀取錯誤使用bpf_htonl/htons導(dǎo)致大端小端匹配不上在循環(huán)里使用非固定邊界或者引用了容易被誤判的變量直接把內(nèi)核指針存儲到map以及在helper參數(shù)里傳了錯誤的類型。遇到驗證失敗最重要的事是完整閱讀verifier輸出的寄存器狀態(tài)信息它會明確告訴你“invalid mem access”發(fā)生在第幾行。另一個建議是盡量少用復(fù)雜循環(huán)多用map和helper來簡化邏輯既能讓verifier更輕松也讓程序更穩(wěn)定。6.4 性能不達標的排查思路XDP程序性能不理想別急著懷疑XDP不行先按數(shù)據(jù)面鏈路排查先看是否真的跑在native模式再看網(wǎng)卡接收隊列有沒有打滿ethtool -S eth0里的rx_dropped是否在漲然后用bpftool prog profile或perf采樣看CPU到底在程序哪段邏輯上燃燒最后看內(nèi)存帶寬和NUMA拓撲跨NUMA訪問包數(shù)據(jù)會顯著拖慢處理。一個簡單有效的對照實驗是把程序內(nèi)部邏輯簡化到一個計數(shù)器加XDP_PASS測一遍再把邏輯換成完整匹配再測一遍兩者的差值就是你的業(yè)務(wù)邏輯真實開銷。這樣定位問題要快很多。寫到這里XDP對我來說最大的價值不是某個具體數(shù)字而是一種“能隨時干預(yù)收包路徑、又不用冒內(nèi)核模塊風(fēng)險”的掌控感。本來還想多分享一點AF_XDP用戶態(tài)收包循環(huán)的細節(jié)但那個坑更長留到下次單獨展開更合適。如果你正打算在生產(chǎn)環(huán)境引入XDP我的建議是先用最簡單的DROP/PASS程序把鏈路跑通積累一兩次線上流量治理的實踐經(jīng)驗再去碰REDIRECT和AF_XDP那些高階玩法。