理解 Linux 網(wǎng)絡(luò)棧（2）：非虛擬化Linux 環(huán)境中的 Segmentation Offloading 技術(shù)

本系列文章總結(jié) Linux 網(wǎng)絡(luò)棧，包括：

（1）Linux 網(wǎng)絡(luò)協(xié)議?？偨Y(jié)

（2）非虛擬化Linux環(huán)境中的網(wǎng)絡(luò)分段卸載技術(shù) GSO/TSO/UFO/LRO/GRO

（3）QEMU/KVM + VxLAN 環(huán)境下的 Segmentation Offloading 技術(shù)（發(fā)送端） 

（4）QEMU/KVM + VxLAN 環(huán)境下的 Segmentation Offloading 技術(shù)（接收端）

第一篇文章總結(jié)了Linux 網(wǎng)絡(luò)協(xié)議棧的概括和功能。本文總結(jié)非虛擬化環(huán)境中的各種 Segmentation Offloading 技術(shù)。

1. 為什么需要 Segmentation offloading

   從第一篇文章的介紹中我們知道，Linux 內(nèi)核傳輸層和網(wǎng)絡(luò)層都要做大量的計(jì)算工作，具體見上圖，這些計(jì)算都在服務(wù)器的主 CPU 中進(jìn)行。這里有一些網(wǎng)絡(luò)協(xié)議棧計(jì)算所需要的 CPU 資源的一些參考數(shù)據(jù)。大體上，發(fā)送或者接收 1 bit/s 的數(shù)據(jù)需要 1 赫茲的 CPU 處理能力，也就是說，5 Git/s （625 MB/s） 的網(wǎng)絡(luò)流量大概需要 5 GHz 的 CPU 處理能力，相當(dāng)于此時(shí)需要 2 個(gè) 2.5 Ghz 的多核處理器。因?yàn)橐蕴W(wǎng)是單向的，發(fā)送和接收 10 Gbit/s （吞吐量就是 20 10 Gbit/s）時(shí)，大概需要 8 個(gè) 2.5 GHz 的 CPU 內(nèi)核。

   這些計(jì)算大概可以分為兩類：（1）數(shù)據(jù)計(jì)算，比如校驗(yàn)和計(jì)算和驗(yàn)證、分包和組包等，這個(gè)和所處理的 packets 的數(shù)量有關(guān)（2）數(shù)據(jù)傳輸和上下文切換帶來的 overhead，這個(gè)和傳輸和切換的次數(shù)有關(guān)。

  為了解決問題，考慮到越來越多的物理網(wǎng)卡具有較強(qiáng)的處理能力，就出現(xiàn)了兩個(gè)思路：

（1）如果網(wǎng)卡能夠支持某些 Linux 內(nèi)核協(xié)議棧所承擔(dān)的計(jì)算任務(wù)，那么就可以將這些計(jì)算從協(xié)議棧 offload （卸載）到物理網(wǎng)卡。

（2）如果網(wǎng)卡不能支持這些計(jì)算，那么盡可能地將這些計(jì)算在 Linux 內(nèi)核網(wǎng)絡(luò)棧中延后（傳輸過程）和提前（接收過程）來減少 overhead。以 TCP 分組或者 IP 分片為例，延遲該過程，可以減少在網(wǎng)絡(luò)棧中傳輸和處理的 packets 的數(shù)目，從而減少數(shù)據(jù)傳輸和上下文切換所需要的主 CPU 計(jì)算能力。

2.  Segmentation offloading 技術(shù)

2.1 TSO （TCP Segmentation Offloading）

2.1.1 TCP Segmentation （TCP 分段）

  MSS（Maxium Segment Size）： MSS 是 TCP 數(shù)據(jù)段每次能夠傳輸?shù)淖畲髷?shù)據(jù)分段的長(zhǎng)度。為了達(dá)到最佳的傳輸效能，TCP 協(xié)議在建立連接的時(shí)候通常要協(xié)商雙方的 MSS 值，這個(gè)值 TCP 協(xié)議在實(shí)現(xiàn)的時(shí)候往往用 MTU 值代替（ MSS = MTU - IP 數(shù)據(jù)包包頭大小20Bytes - TCP 數(shù)據(jù)段的包頭大小20Bytes），所以在默認(rèn)以太網(wǎng) MTU 為 1500 bytes 時(shí)，MSS為 1460。

  TCP 分段：當(dāng)網(wǎng)絡(luò)應(yīng)用發(fā)給 TCP 的 message 的長(zhǎng)度超過 MSS 時(shí)，TCP 會(huì)對(duì)它按照 MSS 的大小將其分為多個(gè)小的 packet，并且在每個(gè) packet 上添加 TCP Header 成為一個(gè) TCP 段（segement）。

2.1.2 TSO  

  TSO 是一種利用網(wǎng)卡分割大數(shù)據(jù)包，減小 CPU 負(fù)荷的一種技術(shù)，也被叫做 LSO (Large segment offload) ，如果數(shù)據(jù)包的類型只能是 TCP，則被稱之為 TSO，如果硬件支持 TSO 功能的話，也需要同時(shí)支持硬件的 TCP 校驗(yàn)計(jì)算和分散 - 聚集 (Scatter Gather) 功能?？梢钥吹?TSO 的實(shí)現(xiàn)，需要一些基本條件，而這些其實(shí)是由軟件和硬件結(jié)合起來完成的，對(duì)于硬件，具體說來，硬件能夠?qū)Υ蟮臄?shù)據(jù)包進(jìn)行分片，分片之后，還要能夠?qū)γ總€(gè)分片附著相關(guān)的頭部。

  TSO 就是將由 TCP 協(xié)議棧所做的 TCP 分段交給具有這種能力的物理網(wǎng)卡去做，因此它需要如下支持：

• 物理網(wǎng)卡支持。
• Linux 網(wǎng)卡驅(qū)動(dòng)支持。可以使用 ethtool -K ethX tso on 命令打開網(wǎng)卡和驅(qū)動(dòng)對(duì) TSO 的支持，如果返回錯(cuò)誤則表示不支持。
• 還需要 Net:TCP checksum offloading and Net:Scatter Gather 支持。

  使用 TSO 以后，應(yīng)用發(fā)出的大的數(shù)據(jù)塊在不超過 64k 的情況下，將會(huì)直接經(jīng)過Linux 網(wǎng)絡(luò)棧發(fā)到網(wǎng)卡的驅(qū)動(dòng)的 driver queue，然后在網(wǎng)卡中根據(jù) skb 中的預(yù)設(shè)分組數(shù)據(jù)（主要是 MSS）對(duì)它執(zhí)行 TCP 分段。下圖是使用 TSO 和不使用 TSO 的情形的對(duì)比：

2.2 UFO - UDP Fragmentation Offload

   UDP 數(shù)據(jù)報(bào)，由于它不會(huì)自己進(jìn)行分段，因此當(dāng)長(zhǎng)度超過了 MTU 時(shí)，會(huì)在網(wǎng)絡(luò)層進(jìn)行 IP 分片。同樣，ICMP（在網(wǎng)絡(luò)層中）同樣會(huì)出現(xiàn)IP分片情況。

2.2.1 IP fragmentation （分片）

MTU 和 IP 分片：

• MTU：上文已經(jīng)說過了，MTU 是鏈路層中的網(wǎng)絡(luò)對(duì)數(shù)據(jù)幀的一個(gè)限制，依然以以太網(wǎng)為例，默認(rèn) MTU 為1500字節(jié)。
• IP 分片：一個(gè) IP 數(shù)據(jù)報(bào)在以太網(wǎng)中傳輸，如果它的長(zhǎng)度大于該 MTU 值，就要進(jìn)行分片傳輸，使得每片數(shù)據(jù)報(bào)的長(zhǎng)度小于MTU。分片傳輸?shù)?IP 數(shù)據(jù)報(bào)不一定按序到達(dá)，但 IP 首部中的信息能讓這些數(shù)據(jù)報(bào)片按序組裝。IP數(shù)據(jù)報(bào)的分片與重組是在網(wǎng)絡(luò)層進(jìn)完成的。

IP 分片和 TCP 分段的區(qū)別：

• IP 數(shù)據(jù)報(bào)分片后，只有第一片帶有UDP首部或ICMP首部，其余的分片只有IP頭部，到了端點(diǎn)后根據(jù)IP頭部中的信息再網(wǎng)絡(luò)層進(jìn)行重組。而 TCP 報(bào)文段的每個(gè)分段中都有TCP 首部，到了端點(diǎn)后根據(jù) TCP 首部的信息在傳輸層進(jìn)行重組。IP數(shù)據(jù)報(bào)分片后，只有到達(dá)目的地后才進(jìn)行重組，而不是向其他網(wǎng)絡(luò)協(xié)議，在下一站就要進(jìn)行重組。
• 對(duì) IP 分片的 TCP segment （段）來說，即使只丟失一片數(shù)據(jù)， TCP 層也要重新傳整個(gè)數(shù)據(jù)報(bào)。這是因?yàn)镮P層本身沒有超時(shí)重傳機(jī)制------由更高層（比如TCP）來負(fù)責(zé)超時(shí)和重傳。當(dāng)來自TCP報(bào)文段的某一段（在IP數(shù)據(jù)報(bào)的某一片中）丟失后，TCP在超時(shí)后會(huì)重發(fā)整個(gè)TCP報(bào)文段，該報(bào)文段對(duì)應(yīng)于一份IP數(shù)據(jù)報(bào)（可能有多個(gè)IP分片），沒有辦法只重傳數(shù)據(jù)報(bào)中的一個(gè)數(shù)據(jù)分片。這就是為什么對(duì) TCP 來說要盡量避免 IP 分片的原因。

IP 分片和 TCP 分段的關(guān)系：

• 在非虛擬化環(huán)境中，MSS 肯定是要比 MTU 小的，因此，每個(gè) TCP 分組不再需要 IP 分片就可以直接交給網(wǎng)卡去傳輸。
• 在虛擬戶環(huán)境中，如果配置不當(dāng)，虛機(jī)網(wǎng)絡(luò)應(yīng)用的 TCP 連接的 MSS 比宿主機(jī)物理網(wǎng)卡的 MTU 大的情況下，宿主機(jī)上還是會(huì)執(zhí)行 IP 分片的。

2.2.2 UFO

  UDP 協(xié)議層本身不對(duì)大的數(shù)據(jù)報(bào)進(jìn)行分片，而是交給 IP 層去做。因此，UFO 就是將 IP 分片 offload 到網(wǎng)卡（NIC）中進(jìn)行。其原理同 TSO。

  "IPv4/IPv6: UFO (UDP Fragmentation Offload) Scatter-gather approach: UFO is a feature wherein the Linux kernel network stack will offload the IP fragmentation functionality of large UDP datagram to hardware. This will reduce the overhead of stack in fragmenting the large UDP datagram to MTU sized packets"

2.3 GSO - Generic Segemetation Offload

   TSO 是使得網(wǎng)絡(luò)協(xié)議棧能夠?qū)⒋髩K buffer 推送至網(wǎng)卡，然后網(wǎng)卡執(zhí)行分片工作，這樣減輕了 CPU 的負(fù)荷，但 TSO 需要硬件來實(shí)現(xiàn)分片功能；而性能上的提高，主要是因?yàn)檠泳彿制鴾p輕了 CPU 的負(fù)載，因此，可以考慮將 TSO 技術(shù)一般化，因?yàn)槠浔举|(zhì)實(shí)際是延緩分片，這種技術(shù)，在 Linux 中被叫做 GSO(Generic Segmentation Offload)。它比 TSO 更通用，原因在于它不需要硬件的支持分片就可使用，對(duì)于支持 TSO 功能的硬件，則先經(jīng)過 GSO 功能，然后使用網(wǎng)卡的硬件分片能力執(zhí)行分片；而對(duì)于不支持 TSO 功能的網(wǎng)卡，將分片的執(zhí)行，放在了將數(shù)據(jù)推送的網(wǎng)卡的前一刻，也就是在調(diào)用驅(qū)動(dòng)的 xmit 函數(shù)前。 

2.3.1 對(duì)于 UDP，在物理網(wǎng)卡不支持 UFO 時(shí)，使用和不使用 GSO 的情形

注意這兩者中間的重要區(qū)別：

• 當(dāng)沒有 GSO 時(shí)，UDP 包會(huì)在 IP 層做 IP 分片，這會(huì)帶來比較嚴(yán)重的問題，包括：依賴于 PMTU，這個(gè)技術(shù)在很多的實(shí)際網(wǎng)絡(luò)中有時(shí)候無法工作；在高速網(wǎng)絡(luò)中，IPv4 packet ID 有時(shí)候會(huì)重復(fù)而導(dǎo)致數(shù)據(jù)損壞（Breaks down on high-bandwidth links because the IPv4 16-bit packet ID value can wrap around, causing data corruption）；它將 UDP 頭算在 payload 內(nèi)，因此只有第一個(gè)分片有 UDP 頭，因此一個(gè)分片丟失會(huì)導(dǎo)致整個(gè)IP包的損失。
• 當(dāng)有 GSO 時(shí)，由 Linux UDP 協(xié)議棧提供 UDP 分片邏輯而不是 IP 分片邏輯，這使得每個(gè)分片都有完整的 UDP 包頭，然后繼續(xù) IP 層的 GSO 分片。所以 GSO 本身是對(duì) UFO 的優(yōu)化。

2.3.2 GSO for UDP 代碼分析

GSO for UDP 代碼在 http://www.mit.edu/afs.new/sipb/contrib/linux/net/ipv4/udp_offload.c：

• UDP GSO 回調(diào)函數(shù)：

static const struct net_offload udpv4_offload = {
    .callbacks = {
        .gso_segment = udp4_ufo_fragment,
        .gro_receive  =    udp4_gro_receive,
        .gro_complete =    udp4_gro_complete,
    },
}

函數(shù) udp4_ufo_fragment 最終調(diào)用 skb_segment 函數(shù)進(jìn)行分片：

     /**
  *      skb_segment - Perform protocol segmentation on skb.
  *      @head_skb: buffer to segment
  *      @features: features for the output path (see dev->features)
  *
  *      This function performs segmentation on the given skb.  It returns
  *      a pointer to the first in a list of new skbs for the segments.
  *      In case of error it returns ERR_PTR(err).
  */
 struct sk_buff *skb_segment(struct sk_buff *head_skb,
                             netdev_features_t features)

• 在函數(shù) static int ip_finish_output_gso(struct net *net, struct sock *sk,  struct sk_buff *skb, unsigned int mtu) 中能看到，首先按照 MSS 做 GSO，然后在調(diào)用 ip_fragment 做 IP 分片。可見，在通常情況下（虛機(jī) TCP MSS 要比物理網(wǎng)卡 MTU ?。?，只做 UDP GSO 分段，IP 分片是不需要做的；只有在特殊情況下 （虛機(jī) TCP MSS 超過了宿主機(jī)物理網(wǎng)卡 MTU），IP 分片才會(huì)做。這個(gè)和試驗(yàn)中看到的效果是相同的。

2.3.3 對(duì) TCP，在網(wǎng)卡不支持 TSO 時(shí)，使用和不使用 GSO 的情形

兩者都是 TCP 分片，只是位置不同。

2.3.4 GSO for TCP 代碼邏輯分析

（1）tcp_output 函數(shù)

1. Checks if GSO is enabled:
    sysctl net.inet.tcp.gso = 1
    sysctl net.gso.”ifname”.enable_gso = 1
2. Checks if the packet length exceeds the MTU

If 1 and 2 are true, sets GSO flag： m->m_pkthdr.csum_flags |= GSO_TO_CSUM(GSO_TCP4);

（2）ip_output 函數(shù)

If GSO is enabled and required, then avoids checksum (IP & TCP) and avoids IP Fragmentation

（3）ether_output 函數(shù)

If GSO is enabled and required: calls gso_dispatch() instead of ifp->transmit()

（4）gso_dispatch 函數(shù)

int gso_dispatch(struct ifnet *ifp, struct mbuf *m, u_int mac_hlen)
{
  …
  gso_flags = CSUM_TO_GSO(m->m_pkthdr.csum_flags);
  …
  error = gso_functions[gso_flags](ifp, m, mac_hlen);
  return error;
}

（5）gso_functions 函數(shù)

gso_functions[GSO_TCP4]
 gso_ip4_tcp(…) - GSO on TCP/IPv4 packet
 
1. m_seg(struct mbuf *m0, int hdr_len, int mss, …)
   returns the mbuf queue that contains the segments of the original packet (m0).
   hdr_len - first bytes of m0 that are copied in each new segments
   mss - maximum segment size
2. fixes TCP and IP headers in each new segments
3. sends new segments to the device driver [ifp->if_transmit()] 

2.4 LRO （Large Receive Offload）   

    Linux 在 2.6.24 中加入了支持 IPv4 TCP 協(xié)議的 LRO (Large Receive Offload) ，它通過將多個(gè) TCP 數(shù)據(jù)聚合在一個(gè) skb 結(jié)構(gòu)，在稍后的某個(gè)時(shí)刻作為一個(gè)大數(shù)據(jù)包交付給上層的網(wǎng)絡(luò)協(xié)議棧，以減少上層協(xié)議棧處理 skb 的開銷，提高系統(tǒng)接收 TCP 數(shù)據(jù)包的能力。當(dāng)然，這一切都需要網(wǎng)卡驅(qū)動(dòng)程序支持。理解 LRO 的工作原理，需要理解 sk_buff 結(jié)構(gòu)體對(duì)于負(fù)載的存儲(chǔ)方式，在內(nèi)核中，sk_buff 可以有三種方式保存真實(shí)的負(fù)載：

1. 數(shù)據(jù)被保存在 skb->data 指向的由 kmalloc 申請(qǐng)的內(nèi)存緩沖區(qū)中，這個(gè)數(shù)據(jù)區(qū)通常被稱為線性數(shù)據(jù)區(qū)，數(shù)據(jù)區(qū)長(zhǎng)度由函數(shù) skb_headlen 給出
2. 數(shù)據(jù)被保存在緊隨 skb 線性數(shù)據(jù)區(qū)尾部的共享結(jié)構(gòu)體 skb_shared_info 中的成員 frags 所表示的內(nèi)存頁面中，skb_frag_t 的數(shù)目由 nr_frags 給出，skb_frags_t 中有數(shù)據(jù)在內(nèi)存頁面中的偏移量和數(shù)據(jù)區(qū)的大小
3. 數(shù)據(jù)被保存于 skb_shared_info 中的成員 frag_list 所表示的 skb 分片隊(duì)列中

    合并了多個(gè) skb 的超級(jí) skb，能夠一次性通過網(wǎng)絡(luò)協(xié)議棧，而不是多次，這對(duì) CPU 負(fù)荷的減輕是顯然的。

2.5 GRO （Generic Receive Offloading）

  前面的 LRO 的核心在于：在接收路徑上，將多個(gè)數(shù)據(jù)包聚合成一個(gè)大的數(shù)據(jù)包，然后傳遞給網(wǎng)絡(luò)協(xié)議棧處理，但 LRO 的實(shí)現(xiàn)中存在一些瑕疵：

• 數(shù)據(jù)包合并可能會(huì)破壞一些狀態(tài)
• 數(shù)據(jù)包合并條件過于寬泛，導(dǎo)致某些情況下本來需要區(qū)分的數(shù)據(jù)包也被合并了，這對(duì)于路由器是不可接收的
• 在虛擬化條件下，需要使用橋接功能，但 LRO 使得橋接功能無法使用
• 實(shí)現(xiàn)中，只支持 IPv4 的 TCP 協(xié)議

  而解決這些問題的辦法就是新提出的 GRO。首先，GRO 的合并條件更加的嚴(yán)格和靈活，并且在設(shè)計(jì)時(shí)，就考慮支持所有的傳輸協(xié)議，因此，后續(xù)的驅(qū)動(dòng)，都應(yīng)該使用 GRO 的接口，而不是 LRO，內(nèi)核可能在所有先有驅(qū)動(dòng)遷移到 GRO 接口之后將 LRO 從內(nèi)核中移除。GRO 和 LRO 的最大區(qū)別在于，GRO 保留了每個(gè)接收到的數(shù)據(jù)包的熵信息，這對(duì)于像路由器這樣的應(yīng)用至關(guān)重要，并且實(shí)現(xiàn)了對(duì)各種協(xié)議的支持。以 IPv4 的 TCP 為例，匹配的條件有：

• 源 / 目的地址匹配
• TOS/ 協(xié)議字段匹配
• 源 / 目的端口匹配

  這篇文章 linux kernel 網(wǎng)絡(luò)協(xié)議棧之GRO(Generic receive offload) 詳細(xì)分析了 GRO 代碼。

2.5.1 在不支持 LRO 的情況下，對(duì) TCP 使用和不使用 GRO 的情形

2.6 TCP/UDP Segementation Offload 小結(jié)

2.6.1 小結(jié)

2.6.2 性能對(duì)比 

                              [TSO/GSO for TCP/IPv4]                                                                [GSO for UDP/IPv4]

從這圖也可以看出：

• 對(duì) TCP 來說，在 CPU 資源充足的情況下，TSO/GSO 能帶來的效果不大，但是在CPU資源不足的情況下，其帶來的改觀還是很大的。
• 對(duì) UDP 來說，其改進(jìn)效果一般，改進(jìn)效果不超過 20%。所以在 VxLAN 環(huán)境中，其實(shí)是可以把 GSO 關(guān)閉，從而避免它帶來的一些潛在問題。

2.6.3  Offloading 帶來的潛在問題

  分段offloading 可能會(huì)帶來潛在的問題，比如網(wǎng)絡(luò)傳輸?shù)难舆t latency，因?yàn)?packets 的大小的增加，大大增加了 driver queue 的容量（capacity）。比如說，系統(tǒng)一方面在使用大的 packet size 傳輸大量的數(shù)據(jù)，同時(shí)在運(yùn)行許多的交換式應(yīng)用（interactive application）。因?yàn)榻换ナ綉?yīng)用會(huì)定時(shí)發(fā)送許多小的packet，這時(shí)候可能會(huì)應(yīng)為這些小的 packets 被淹沒在大的 packets 之中，需要等待較長(zhǎng)的時(shí)間才能被處理，這可能會(huì)帶來不可接受的延遲。

  在網(wǎng)絡(luò)上也能看到一些建議，在使用這些 offloading 技術(shù)時(shí)如果發(fā)現(xiàn)莫名的網(wǎng)絡(luò)問題，建議先將這些技術(shù)關(guān)閉后再看看情況有沒有改變。

參考鏈接：

• http://www.slideshare.net/eurobsdcon/20140928-gso-eurobsdcon2014
• Linux 下網(wǎng)絡(luò)性能優(yōu)化方法簡(jiǎn)析