如圖，兩臺(tái)設(shè)備 Node-A/B 通過(guò) eth1 直連，網(wǎng)段為 192.168.1.0/24。

Node-A/B 中分別創(chuàng)建容器 Pod-A/B，容器網(wǎng)卡名為 ve0，是 veth 設(shè)備，網(wǎng)段為172.17.0.0/16。

Node-A/B 中分別創(chuàng)建橋接口 br0，網(wǎng)段為 172.17.0.0/16，通過(guò) lxc0（veth 設(shè)備）與 Pod-A/B 連通。

在 Node、Pod 網(wǎng)絡(luò) namespace 中，分別設(shè)置靜態(tài)路由；其中，Pod 中靜態(tài)路由網(wǎng)關(guān)為 br0，Node 中靜態(tài)路由網(wǎng)關(guān)為對(duì)端 Node 接口地址。

為了方便測(cè)試與分析，我們將 eth1 的網(wǎng)卡隊(duì)列設(shè)置為 1，并且將網(wǎng)卡中斷綁定到 CPU0。

# ethtool -L eth1 combined 1
# echo 0 > /proc/irq/$(cat /proc/interrupts | awk -F ':' '/eth1/ {gsub(/ /,""); print $1}')/smp_affinity_list

bridge

bridge + veth 是容器網(wǎng)絡(luò)最早的轉(zhuǎn)發(fā)模式，我們結(jié)合上面的網(wǎng)絡(luò)拓?fù)洌治鲆幌戮W(wǎng)絡(luò)數(shù)據(jù)包的轉(zhuǎn)發(fā)路徑。

在上面網(wǎng)絡(luò)拓?fù)渲校琫th1 收到目的地址為 172.17.0.0/16 網(wǎng)段的報(bào)文，會(huì)經(jīng)過(guò)路由查找，走到 br0 的發(fā)包流程。

br0 的發(fā)包流程，會(huì)根據(jù) FDB 表查找目的 MAC 地址歸屬的子接口，如果沒(méi)有查找到，就洪泛（遍歷所有子接口，發(fā)送報(bào)文）；否則，選擇特定子接口，發(fā)送報(bào)文。在本例中，會(huì)選擇 lxc0 接口，發(fā)送報(bào)文。

lxc0 口是 veth 口，內(nèi)核的實(shí)現(xiàn)是 veth 口發(fā)包，對(duì)端（peer）的 veth 口就會(huì)收包。在本例中，Pod-A/B 中的 ve0 口會(huì)收到報(bào)文。

至此，完成收包方向的主要流程。

當(dāng)報(bào)文從 Pod-A/B 中發(fā)出，會(huì)先在 Pod 的網(wǎng)絡(luò) namespace 中查找路由，假設(shè)流量從 Pod-A 發(fā)往 Pod-B，那么會(huì)命中我們之前設(shè)置的靜態(tài)路由：172.17.0.200 via 172.17.0.1 dev ve0，最終報(bào)文會(huì)從 ve0 口發(fā)出，目的 MAC 地址為 Node-A 上面 br0 的地址。

ve0 口是 veth 口，和收包方向類(lèi)似，對(duì)端的 veth 口 lxc0 會(huì)收到報(bào)文。

lxc0 口是 br0 的子接口，由于報(bào)文目的 MAC 地址為 br0 的接口地址，報(bào)文會(huì)經(jīng)過(guò)br0 口上送到 3 層協(xié)議棧處理。

3 層協(xié)議棧會(huì)查找路由，命中我們之前設(shè)置的靜態(tài)路由：172.17.0.200 via 192.168.1.20 dev eth1，最終報(bào)文會(huì)從 eth1 口發(fā)出，發(fā)給 Node-B。

至此，完成發(fā)包方向的主要流程。

上面的流程比較抽象，我們用 perf ftrace 可以非常直觀(guān)地看到報(bào)文都經(jīng)過(guò)了哪些內(nèi)核協(xié)議棧路徑。

收包路徑

# perf ftrace -C0 -G '__netif_receive_skb_list_core' -g 'smp_*'

?

?

如圖，收包路徑主要經(jīng)歷路由查找、橋轉(zhuǎn)發(fā)、veth 轉(zhuǎn)發(fā)、veth 收包等階段，中間多次經(jīng)過(guò) netfilter 的 hook 點(diǎn)。

最終調(diào)用 enqueue_to_backlog 函數(shù)，數(shù)據(jù)包暫存到每個(gè) ?CPU 私有的 input_pkt_queue中，一次軟中斷結(jié)束，總耗時(shí) 79us。

但是報(bào)文并沒(méi)有到達(dá)終點(diǎn)，后續(xù)軟中斷到來(lái)時(shí)，會(huì)有機(jī)會(huì)調(diào)用 process_backlog，處理每個(gè) CPU 私有的 input_pkt_queue，將報(bào)文丟入 Pod 網(wǎng)絡(luò) namespace 的協(xié)議棧繼續(xù)處理，直到將報(bào)文送往 socket 的隊(duì)列，才算是到達(dá)了終點(diǎn)。

綜上，收包路徑要消耗2個(gè)軟中斷，才能將報(bào)文送達(dá)終點(diǎn)。

發(fā)包路徑

# perf ftrace -C0 -G '__netif_receive_skb_core' -g 'smp_*'

?

?

如圖，發(fā)包路徑主要經(jīng)歷 veth 收包、橋上送、路由查找、物理網(wǎng)卡轉(zhuǎn)發(fā)等階段，中間多次經(jīng)過(guò) netfilter 的 hook點(diǎn) 。

最終調(diào)用網(wǎng)卡驅(qū)動(dòng)發(fā)包函數(shù)，一次軟中斷結(jié)束，總耗時(shí) 62us。

分析

由 perf ftrace 的結(jié)果可以看出，利用 bridge + veth 的轉(zhuǎn)發(fā)模式，會(huì)多次經(jīng)歷netfilter、路由等子系統(tǒng)，過(guò)程非常冗長(zhǎng)，導(dǎo)致了轉(zhuǎn)發(fā)性能的下降。

我們接下來(lái)看一下，如何用eBPF跳過(guò)非必須的流程，加速網(wǎng)絡(luò)轉(zhuǎn)發(fā)。

TC redirect

首先，我們先看一下內(nèi)核協(xié)議棧主要支持的 eBPF hook 點(diǎn)，在這些 hook 點(diǎn)我們可以注入 eBPF 程序，實(shí)現(xiàn)具體的業(yè)務(wù)需求。

我們可以看到，與網(wǎng)絡(luò)轉(zhuǎn)發(fā)相關(guān)的 hook 點(diǎn)主要有 XDP（eXpress Data Path）、TC（Traffic Control）、LWT（Light Weight Tunnel）等。

針對(duì)于容器網(wǎng)絡(luò)轉(zhuǎn)發(fā)的場(chǎng)景，比較合適的 hook 點(diǎn)是 TC。因?yàn)?TC hook 點(diǎn)是協(xié)議棧的入口和出口，比較底層，eBPF 程序能夠獲取非常全面的上下文（如：socket、cgroup 信息等），這點(diǎn)是 XDP 沒(méi)有辦法做到的。而 LWT 則比較靠上層，報(bào)文到達(dá)這個(gè) hook 點(diǎn)，會(huì)經(jīng)過(guò)很多子系統(tǒng)（如：netfilter）。

加速收包路徑

如圖，在 eth1 的 TC hook 點(diǎn)（收包方向）掛載 eBPF 程序。

# tc qdisc add dev eth1 clsact
#?tc?filter?add?dev?eth1?ingress?bpf?da?obj?ingress_redirect.o?sec?classifier-redirect

eBPF 程序如下所示，其中 lxc0 接口的 index 為 2。bpf_redirect 函數(shù)為內(nèi)核提供的 helper 函數(shù)，該函數(shù)會(huì)將 eth1 收到的數(shù)據(jù)包，直接轉(zhuǎn)發(fā)至 lxc0 接口。

SEC("classifier-redirect") 
int cls_redirect(struct __sk_buff *skb) { 
   /* The ifindex of lxc0 is 2 */    
   return bpf_redirect(2, 0); 
}

加速發(fā)包路徑

如圖，在 lxc0 的 TC hook 點(diǎn)（收包方向）掛載 eBPF 程序。

# tc qdisc add dev lxc0 clsact 
# tc filter add dev lxc0 ingress bpf da obj egress_redirect.o sec classifier-redirect

eBPF 程序如下所示，其中 eth1 接口的 index 為 1。bpf_redirect 函數(shù)會(huì)將 lxc0 收到的數(shù)據(jù)包，直接轉(zhuǎn)發(fā)至 eth1 接口。

SEC("classifier-redirect") 
int cls_redirect(struct __sk_buff *skb) {
    /* The ifindex of eth1 is 1 */    
    return bpf_redirect(1, 0); 
}

分析

由上面的操作可以看到，我們直接跳過(guò)了 bridge 的轉(zhuǎn)發(fā)，利用 eBPF 程序，將 eth1 與 lxc0 之間建立了一個(gè)快速轉(zhuǎn)發(fā)通路。下面我們用 perf ftrace 看一下加速效果。

收包路徑

# perf ftrace -C0 -G '__netif_receive_skb_list_core' -g 'smp_*'

?

?

如圖，在收包路徑的 TC 子系統(tǒng)中，由 bpf_redirect 函數(shù)設(shè)置轉(zhuǎn)發(fā)信息（ lxc0 接口 index），由 skb_do_redirect 函數(shù)直接調(diào)用了 lxc0 接口的 veth_xmit 函數(shù)；略過(guò)了路由、bridge、netfilter 等子系統(tǒng)。

最終調(diào)用 enqueue_to_backlog 函數(shù)，數(shù)據(jù)包暫存到每個(gè) CPU 私有的input_pkt_queue 中，一次軟中斷結(jié)束，總耗時(shí) 43us；比 bridge 轉(zhuǎn)發(fā)模式的 79us，耗時(shí)減少約 45%。

但是，收包路徑仍然要消耗 2 個(gè)軟中斷，才能將報(bào)文送達(dá)終點(diǎn)。

發(fā)包路徑

如圖，在發(fā)包路徑的 TC 子系統(tǒng)中，由 bpf_redirect 函數(shù)設(shè)置轉(zhuǎn)發(fā)信息（ eth1 接口 index ），由 skb_do_redirect 函數(shù)直接調(diào)用了 eth1 接口的 xmit 函數(shù)；略過(guò)了路由、bridge、netfilter 等子系統(tǒng)。

最終調(diào)用網(wǎng)卡驅(qū)動(dòng)發(fā)包函數(shù)，一次軟中斷結(jié)束，總耗時(shí) 36us，相比 bridge 模式 62us，耗時(shí)減少了約 42%。

小結(jié)

由 perf ftrace 的結(jié)果可以看出，利用 eBPF 在 TC 子系統(tǒng)注入轉(zhuǎn)發(fā)邏輯，可以跳過(guò)內(nèi)核協(xié)議棧非必須的流程，實(shí)現(xiàn)加速轉(zhuǎn)發(fā)。收發(fā)兩個(gè)方向的耗時(shí)分別減少40%左右，性能提升非常可觀(guān)。

但是，我們?cè)谑瞻窂缴厦嫒匀恍枰?2 個(gè)軟中斷，才能將報(bào)文送往目的地。接下來(lái)我們看，如何利用 redirect peer 技術(shù)來(lái)優(yōu)化這個(gè)流程。

TC redirect peer

加速收包路徑

如圖，在 eth1 的 TC hook 點(diǎn)（收包方向）掛載 eBPF 程序。

# tc qdisc add dev eth1 clsact 
# tc filter add dev eth1 ingress bpf da obj ingress_redirect_peer.o sec classifier-redirect

eBPF 程序如下所示，其中 lxc0 接口的 index 為 2。bpf_redirect_peer 函數(shù)為內(nèi)核提供的 helper 函數(shù)，該函數(shù)會(huì)將 eth1 收到的數(shù)據(jù)包，直接轉(zhuǎn)發(fā)至 lxc0 接口的 peer 接口，即 ve0 接口。

SEC("classifier-redirect") 
int cls_redirect(struct __sk_buff *skb) {
    /* The ifindex of lxc0 is 2 */    
    return bpf_redirect_peer(2, 0); 
}

分析

由于 bpf_redirect_peer 會(huì)直接將數(shù)據(jù)包轉(zhuǎn)發(fā)到 Pod 網(wǎng)絡(luò) namespace 中，避免了enqueue_to_backlog 操作，節(jié)省了一次軟中斷，性能理論上會(huì)有提升。我們用 perf ftrace 驗(yàn)證一下。

# perf ftrace -C0 -G '__netif_receive_skb_list_core' -g 'smp_*

?

?

'

如圖，在收包路徑的 TC 子系統(tǒng)中，由 bpf_redirect_peer 函數(shù)設(shè)置轉(zhuǎn)發(fā)信息（ lxc0 接口 index），由 skb_do_redirect 函數(shù)調(diào)用 veth_peer_dev 查找 lxc0 的 peer 接口，設(shè)置 skb->dev = ve0，返回 EAGAIN 給 tcf_classify 函數(shù)。

tcf_classify 函數(shù)會(huì)判斷 skb_do_redirect 的返回值，如果是 EAGAIN，則觸發(fā) __netif_receive_skb_core 函數(shù)偽遞歸調(diào)用（通過(guò) goto ?實(shí)現(xiàn)）。這樣，就非常巧妙地實(shí)現(xiàn)了網(wǎng)絡(luò) namespace 的切換（在一次軟中斷上下文中）。

最終，通過(guò) tcp_v4_rcv 函數(shù)到達(dá)報(bào)文的終點(diǎn)，整個(gè)轉(zhuǎn)發(fā)流程耗時(shí) 75us。從上面的函數(shù)耗時(shí)可以看到，ip_list_rcv 函數(shù)相當(dāng)于 Pod 網(wǎng)絡(luò) namespace 的耗時(shí)，本文描述的 3 種轉(zhuǎn)發(fā)模式，這段轉(zhuǎn)發(fā)路徑是相同的。所以，將 ip_list_rcv 函數(shù)耗時(shí)減去，轉(zhuǎn)發(fā)耗時(shí)約為 14us（這里還忽略了2次軟中斷調(diào)度的時(shí)間）。比 TC redirect 模式的 43us、bridge 模式的 79us，轉(zhuǎn)發(fā)耗時(shí)分別減少為 67%、82%。

總結(jié)

本文以容器網(wǎng)絡(luò)為例，對(duì)比了 3 種容器網(wǎng)絡(luò)轉(zhuǎn)發(fā)模式的性能差異。通過(guò) perf ftrace 的函數(shù)調(diào)用關(guān)系以及耗時(shí)情況，詳細(xì)分析了導(dǎo)致性能差異的原因。我們演示了僅僅通過(guò)幾行 eBPF 代碼，就可以大大縮短報(bào)文轉(zhuǎn)發(fā)路徑，加速內(nèi)核網(wǎng)絡(luò)轉(zhuǎn)發(fā)的效率，網(wǎng)絡(luò)轉(zhuǎn)發(fā)耗時(shí)最多可減少82%。

目前 eBPF 技術(shù)在開(kāi)源社區(qū)非常流行，在 tracing、安全、網(wǎng)絡(luò)等領(lǐng)域有廣泛應(yīng)用，我們可以利用這項(xiàng)技術(shù)做很多有意思的事情。感興趣的朋友可以加入我們，一起討論交流。

作者：王棟棟，字節(jié)跳動(dòng)系統(tǒng)技術(shù)與工程團(tuán)隊(duì)內(nèi)核工程師，10年系統(tǒng)工程師工作經(jīng)驗(yàn)，關(guān)注Linux networking、eBPF等領(lǐng)域。目前在字節(jié)跳動(dòng)，主要負(fù)責(zé)eBPF、內(nèi)核網(wǎng)絡(luò)協(xié)議棧相關(guān)的開(kāi)發(fā)工作。

編輯：黃飛

?