IT系統的性能永遠是企業IT人員關注熱點，而隨着Linux系統應用的增多，一些應用方面的問題也隨之增多，本文將爲大家介紹Linux內核下如何進行網絡性能優化。
首先我們先看下網絡的行爲，可以簡單劃分爲3條路徑：發送路徑、轉發路徑、接收路徑，而網絡性能的優化則可基於這3條路徑來考慮。本文集中於發送路徑和接收路徑上的優化方法分析，其中的NAPI本質上是接收路徑上的優化，但因爲它在Linux的內核出現時間較早，而它也是後續出現的各種優化方法的基礎，所以將其單獨分析。
最爲基本的 NAPI
NAPI 的核心在於：在一個繁忙網絡，每次有網絡數據包到達時，不需要都引發中斷，因爲高頻率的中斷可能會影響系統的整體效率，假象一個場景，我們此時使用標準的 100M 網卡，可能實際達到的接收速率爲 80MBits/s，而此時數據包平均長度爲 1500Bytes，則每秒產生的中斷數目爲：
80M bits/s / (8 Bits/Byte * 1500 Byte) = 6667 箇中斷 /s
每秒 6667 箇中斷，對於系統是個很大的壓力，此時其實可以轉爲使用輪詢 (polling) 來處理，而不是中斷;但輪詢在網絡流量較小的時沒有效率，因此低流量時，基於中斷的方式則比較合適，這就是 NAPI 出現的原因，在低流量時候使用中斷接收數據包，而在高流量時候則使用基於輪詢的方式接收。
現在內核中 NIC 基本上已經全部支持 NAPI 功能，由前面的敘述可知，NAPI 適合處理高速率數據包的處理，而帶來的好處則是：
1、中斷緩和 (Interrupt mitigation)，由上面的例子可以看到，在高流量下，網卡產生的中斷可能達到每秒幾千次，而如果每次中斷都需要系統來處理，是一個很大的壓力，而 NAPI 使用輪詢時是禁止了網卡的接收中斷的，這樣會減小系統處理中斷的壓力；
2、數據包節流 (Packet throttling)，NAPI 之前的 Linux NIC 驅動總在接收到數據包之後產生一個 IRQ，接着在中斷服務例程裏將這個 skb 加入本地的 softnet，然後觸發本地 NET_RX_SOFTIRQ 軟中斷後續處理。如果包速過高，因爲 IRQ 的優先級高於 SoftIRQ，導致系統的大部分資源都在響應中斷，但 softnet 的隊列大小有限，接收到的超額數據包也只能丟掉，所以這時這個模型是在用寶貴的系統資源做無用功。而 NAPI 則在這樣的情況下，直接把包丟掉，不會繼續將需要丟掉的數據包扔給內核去處理，這樣，網卡將需要丟掉的數據包儘可能的早丟棄掉，內核將不可見需要丟掉的數據包，這樣也減少了內核的壓力。
對NAPI 的使用，一般包括以下的幾個步驟：
1、在中斷處理函數中，先禁止接收中斷，且告訴網絡子系統，將以輪詢方式快速收包，其中禁止接收中斷完全由硬件功能決定，而告訴內核將以輪詢方式處理包則是使用函數 netif_rx_schedule()，也可以使用下面的方式，其中的 netif_rx_schedule_prep 是爲了判定現在是否已經進入了輪詢模式：
將網卡預定爲輪詢模式
或者
if (netif_rx_schedule_prep(dev))
__netif_rx_schedule(dev);
2、在驅動中創建輪詢函數，它的工作是從網卡獲取數據包並將其送入到網絡子系統，其原型是：
NAPI 的輪詢方法
這裏的輪詢函數用於在將網卡切換爲輪詢模式之後，用 poll() 方法處理接收隊列中的數據包，如隊列爲空，則重新切換爲中斷模式。切換回中斷模式需要先關閉輪詢模式，使用的是函數 netif_rx_complete ()，接着開啓網卡接收中斷 .。
退出輪詢模式
3、在驅動中創建輪詢函數，需要和實際的網絡設備 struct net_device 關聯起來，這一般在網卡的初始化時候完成，示例代碼如下：
設置網卡支持輪詢模式
dev->weight = 64;
裏面另外一個字段爲權重 (weight)，該值並沒有一個非常嚴格的要求，實際上是個經驗數據，一般 10Mb 的網卡，我們設置爲 16，而更快的網卡，我們則設置爲 64。
NAPI的一些相關Interface
下面是 NAPI 功能的一些接口，在前面都基本有涉及，我們簡單看看：
netif_rx_schedule(dev)
在網卡的中斷處理函數中調用，用於將網卡的接收模式切換爲輪詢
netif_rx_schedule_prep(dev)
在網卡是 Up 且運行狀態時，將該網卡設置爲準備將其加入到輪詢列表的狀態，可以將該函數看做是 netif_rx_schedule(dev) 的前半部分
__netif_rx_schedule(dev)
將設備加入輪詢列表，前提是需要 netif_schedule_prep(dev) 函數已經返回了 1
__netif_rx_schedule_prep(dev)
與 netif_rx_schedule_prep(dev) 相似，但是沒有判斷網卡設備是否 Up 及運行，不建議使用
netif_rx_complete(dev)
用於將網卡接口從輪詢列表中移除，一般在輪詢函數完成之後調用該函數。
__netif_rx_complete(dev)
Newer newer NAPI
其實之前的 NAPI(New API) 這樣的命名已經有點讓人忍俊不禁了，可見 Linux 的內核極客們對名字的掌控，比對代碼的掌控差太多，於是乎，連續的兩次對 NAPI 的重構，被戲稱爲 Newer newer NAPI 了。
與 netif_rx_complete(dev) 類似，但是需要確保本地中斷被禁止
Newer newer NAPI
在最初實現的 NAPI 中，有 2 個字段在結構體 net_device 中，分別爲輪詢函數 poll() 和權重 weight，而所謂的 Newer newer NAPI，是在 2.6.24 版內核之後，對原有的 NAPI 實現的幾次重構，其核心是將 NAPI 相關功能和 net_device 分離，這樣減少了耦合，代碼更加的靈活，因爲 NAPI 的相關信息已經從特定的網絡設備剝離了，不再是以前的一對一的關係了。例如有些網絡適配器，可能提供了多個 port，但所有的 port 卻是共用同一個接受數據包的中斷，這時候，分離的 NAPI 信息只用存一份，同時被所有的 port 來共享，這樣，代碼框架上更好地適應了真實的硬件能力。Newer newer NAPI 的中心結構體是napi_struct:
NAPI 結構體
* Structure for NAPI scheduling similar to tasklet but with weighting
*/
struct napi_struct {
/* The poll_list must only be managed by the entity which
* changes the state of the NAPI_STATE_SCHED bit. This means
* whoever atomically sets that bit can add this napi_struct
* to the per-cpu poll_list, and whoever clears that bit
* can remove from the list right before clearing the bit.
*/
struct list_head poll_list;
unsigned long state;
int weight;
int (*poll)(struct napi_struct *, int);
#ifdef CONFIG_NETPOLL
spinlock_t poll_lock;
int poll_owner;
#endif
unsigned int gro_count;
struct net_device *dev;
struct list_head dev_list;
struct sk_buff *gro_list;
struct sk_buff *skb;
};
熟悉老的 NAPI 接口實現的話，裏面的字段 poll_list、state、weight、poll、dev、沒什麼好說的，gro_count 和 gro_list 會在後面講述 GRO 時候會講述。需要注意的是，與之前的 NAPI 實現的最大的區別是該結構體不再是 net_device 的一部分，事實上，現在希望網卡驅動自己單獨分配與管理 napi 實例，通常將其放在了網卡驅動的私有信息，這樣最主要的好處在於，如果驅動願意，可以創建多個 napi_struct，因爲現在越來越多的硬件已經開始支持多接收隊列 (multiple receive queues)，這樣，多個 napi_struct 的實現使得多隊列的使用也更加的有效。
與最初的 NAPI 相比較，輪詢函數的註冊有些變化，現在使用的新接口是：
int (*poll)(struct napi_struct *, int), int weight)
熟悉老的 NAPI 接口的話，這個函數也沒什麼好說的。
值得注意的是，前面的輪詢 poll() 方法原型也開始需要一些小小的改變：
大部分 NAPI 相關的函數也需要改變之前的原型，下面是打開輪詢功能的 API：
struct napi_struct *napi);
/* ...or... */
int netif_rx_schedule_prep(struct net_device *dev,
struct napi_struct *napi);
void __netif_rx_schedule(struct net_device *dev,
struct napi_struct *napi);
輪詢功能的關閉則需要使用：
struct napi_struct *napi);
因爲可能存在多個 napi_struct 的實例，要求每個實例能夠獨立的使能或者禁止，因此，需要驅動作者保證在網卡接口關閉時，禁止所有的 napi_struct 的實例。
函數 netif_poll_enable() 和 netif_poll_disable() 不再需要，因爲輪詢管理不再和 net_device 直接管理，取而代之的是下面的兩個函數：
void napi_disable(struct napi *napi);
發送路徑上的優化
TSO (TCP Segmentation Offload)
TSO (TCP Segmentation Offload) 是一種利用網卡分割大數據包，減小 CPU 負荷的一種技術，也被叫做 LSO (Large segment offload) ，如果數據包的類型只能是 TCP，則被稱之爲 TSO，如果硬件支持 TSO 功能的話，也需要同時支持硬件的 TCP 校驗計算和分散 - 聚集 (Scatter Gather) 功能。
可以看到 TSO 的實現，需要一些基本條件，而這些其實是由軟件和硬件結合起來完成的，對於硬件，具體說來，硬件能夠對大的數據包進行分片，分片之後，還要能夠對每個分片附着相關的頭部。TSO 的支持主要有需要以下幾步：
1、如果網路適配器支持 TSO 功能，需要聲明網卡的能力支持 TSO，這是通過以 NETIF_F_TSO 標誌設置 net_device structure 的 features 字段來表明，例如，在 benet(drivers/net/benet/be_main.c) 網卡的驅動程序中，設置 NETIF_F_TSO 的代碼如下：
benet 網卡驅動聲明支持 TSO 功能
{
struct be_adapter *adapter = netdev_priv(netdev);
netdev->features |= NETIF_F_SG | NETIF_F_HW_VLAN_RX | NETIF_F_TSO |
NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_FILTER | NETIF_F_HW_CSUM |
NETIF_F_GRO | NETIF_F_TSO6;
netdev->vlan_features |= NETIF_F_SG | NETIF_F_TSO | NETIF_F_HW_CSUM;
netdev->flags |= IFF_MULTICAST;
adapter->rx_csum = true;
/* Default settings for Rx and Tx flow control */
adapter->rx_fc = true;
adapter->tx_fc = true;
netif_set_gso_max_size(netdev, 65535);
BE_SET_NETDEV_OPS(netdev, &be_netdev_ops);
SET_ETHTOOL_OPS(netdev, &be_ethtool_ops);
netif_napi_add(netdev, &adapter->rx_eq.napi, be_poll_rx,
BE_NAPI_WEIGHT);
netif_napi_add(netdev, &adapter->tx_eq.napi, be_poll_tx_mcc,
BE_NAPI_WEIGHT);
netif_carrier_off(netdev);
netif_stop_queue(netdev);
}
在代碼中，同時也用 netif_set_gso_max_size 函數設置了 net_device 的 gso_max_size 字段。該字段表明網絡接口一次能處理的最大 buffer 大小，一般該值爲 64Kb，這意味着只要 TCP 的數據大小不超過 64Kb，就不用在內核中分片，而只需一次性的推送到網絡接口，由網絡接口去執行分片功能。
2、當一個 TCP 的 socket 被創建，其中一個職責是設置該連接的能力，在網絡層的 socket 的表示是 struck sock，其中有一個字段 sk_route_caps 標示該連接的能力，在 TCP 的三路握手完成之後，將基於網絡接口的能力和連接來設置該字段。
網路層對 TSO 功能支持的設定
int tcp_v4_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
{
……
/* OK, now commit destination to socket. */
sk->sk_gso_type = SKB_GSO_TCPV4;
sk_setup_caps(sk, &rt->dst);
……
}
代碼中的 sk_setup_caps() 函數則設置了上面所說的 sk_route_caps 字段，同時也檢查了硬件是否支持分散 - 聚集功能和硬件校驗計算功能。需要這 2 個功能的原因是：Buffer 可能不在一個內存頁面上，所以需要分散 - 聚集功能，而分片後的每個分段需要重新計算 checksum，因此需要硬件支持校驗計算。
3、現在，一切的準備工作都已經做好了，當實際的數據需要傳輸時，需要使用我們設置好的 gso_max_size，我們知道，TCP 向 IP 層發送數據會考慮 mss，使得發送的 IP 包在 MTU 內，不用分片。而 TSO 設置的 gso_max_size 就影響該過程，這主要是在計算 mss_now 字段時使用。如果內核不支持 TSO 功能，mss_now 的最大值爲“MTU – HLENS”，而在支持 TSO 的情況下，mss_now 的最大值爲“gso_max_size -HLENS”，這樣，從網絡層帶驅動的路徑就被打通了。
GSO (Generic Segmentation Offload)
TSO 是使得網絡協議棧能夠將大塊 buffer 推送至網卡，然後網卡執行分片工作，這樣減輕了 CPU 的負荷，但 TSO 需要硬件來實現分片功能;而性能上的提高，主要是因爲延緩分片而減輕了 CPU 的負載，因此，可以考慮將 TSO 技術一般化，因爲其本質實際是延緩分片，這種技術，在 Linux 中被叫做 GSO(Generic Segmentation Offload)，它比 TSO 更通用，原因在於它不需要硬件的支持分片就可使用，對於支持 TSO 功能的硬件，則先經過 GSO 功能，然後使用網卡的硬件分片能力執行分片;而對於不支持 TSO 功能的網卡，將分片的執行，放在了將數據推送的網卡的前一刻，也就是在調用驅動的 xmit 函數前。
我們再來看看內核中數據包的分片都有可能在哪些時刻：
1、在傳輸協議中，當構造 skb 用於排隊的時候
2、在傳輸協議中，但是使用了 NETIF_F_GSO 功能，當即將傳遞個網卡驅動的時候
3、在驅動程序裏，此時驅動支持 TSO 功能 ( 設置了 NETIF_F_TSO 標誌 )
對於支持 GSO 的情況，主要使用了情況 2 或者是情況 2.、3，其中情況二是在硬件不支持 TSO 的情況下，而情況 2、3 則是在硬件支持 TSO 的情況下。
代碼中是在 dev_hard_start_xmit 函數裏調用 dev_gso_segment 執行分片，這樣儘量推遲分片的時間以提高性能：
GSO 中的分片
struct netdev_queue *txq)
{
……
if (netif_needs_gso(dev, skb)) {
if (unlikely(dev_gso_segment(skb)))
goto out_kfree_skb;
if (skb->next)
goto gso;
} else {
……
}
……
}
接收路徑上的優化
LRO (Large Receive Offload)
Linux 在 2.6.24 中加入了支持 IPv4 TCP 協議的 LRO (Large Receive Offload) ，它通過將多個 TCP 數據聚合在一個 skb 結構，在稍後的某個時刻作爲一個大數據包交付給上層的網絡協議棧，以減少上層協議棧處理 skb 的開銷，提高系統接收 TCP 數據包的能力。
當然，這一切都需要網卡驅動程序支持。理解 LRO 的工作原理，需要理解 sk_buff 結構體對於負載的存儲方式，在內核中，sk_buff 可以有三種方式保存真實的負載：
1、數據被保存在 skb->data 指向的由 kmalloc 申請的內存緩衝區中，這個數據區通常被稱爲線性數據區，數據區長度由函數 skb_headlen 給出
2、數據被保存在緊隨 skb 線性數據區尾部的共享結構體 skb_shared_info 中的成員 frags 所表示的內存頁面中，skb_frag_t 的數目由 nr_frags 給出，skb_frags_t 中有數據在內存頁面中的偏移量和數據區的大小
3、數據被保存於 skb_shared_info 中的成員 frag_list 所表示的 skb 分片隊列中
合併了多個 skb 的超級 skb，能夠一次性通過網絡協議棧，而不是多次，這對 CPU 負荷的減輕是顯然的。
LRO 的核心結構體如下：
LRO 的核心結構體
* Large Receive Offload (LRO) Manager
*
* Fields must be set by driver
*/
struct net_lro_mgr {
struct net_device *dev;
struct net_lro_stats stats;
/* LRO features */
unsigned long features;
#define LRO_F_NAPI 1 /* Pass packets to stack via NAPI */
#define LRO_F_EXTRACT_VLAN_ID 2 /* Set flag if VLAN IDs are extracted
from received packets and eth protocol
is still ETH_P_8021Q */
/*
* Set for generated SKBs that are not added to
* the frag list in fragmented mode
*/
u32 ip_summed;
u32 ip_summed_aggr; /* Set in aggregated SKBs: CHECKSUM_UNNECESSARY
* or CHECKSUM_NONE */
int max_desc; /* Max number of LRO descriptors */
int max_aggr; /* Max number of LRO packets to be aggregated */
int frag_align_pad; /* Padding required to properly align layer 3
* headers in generated skb when using frags */
struct net_lro_desc *lro_arr; /* Array of LRO descriptors */
/*
* Optimized driver functions
*
* get_skb_header: returns tcp and ip header for packet in SKB
*/
int (*get_skb_header)(struct sk_buff *skb, void **ip_hdr,
void **tcpudp_hdr, u64 *hdr_flags, void *priv);
/* hdr_flags: */
#define LRO_IPV4 1 /* ip_hdr is IPv4 header */
#define LRO_TCP 2 /* tcpudp_hdr is TCP header */
/*
* get_frag_header: returns mac, tcp and ip header for packet in SKB
*
* @hdr_flags: Indicate what kind of LRO has to be done
* (IPv4/IPv6/TCP/UDP)
*/
int (*get_frag_header)(struct skb_frag_struct *frag, void **mac_hdr,
void **ip_hdr, void **tcpudp_hdr, u64 *hdr_flags,
void *priv);
};
在該結構體中：
dev：指向支持 LRO 功能的網絡設備
stats：包含一些統計信息，用於查看 LRO 功能的運行情況
features：控制 LRO 如何將包送給網絡協議棧，其中的 LRO_F_NAPI 表明驅動是 NAPI 兼容的，應該使用 netif_receive_skb() 函數，而 LRO_F_EXTRACT_VLAN_ID 表明驅動支持 VLAN
ip_summed：表明是否需要網絡協議棧支持 checksum 校驗
ip_summed_aggr：表明聚集起來的大數據包是否需要網絡協議棧去支持 checksum 校驗
max_desc：表明最大數目的 LRO 描述符，注意，每個 LRO 的描述符描述了一路 TCP 流，所以該值表明了做多同時能處理的 TCP 流的數量
max_aggr：是最大數目的包將被聚集成一個超級數據包
lro_arr：是描述符數組，需要驅動自己提供足夠的內存或者在內存不足時處理異常
get_skb_header()/get_frag_header()：用於快速定位 IP 或者 TCP 的頭，一般驅動只提供其中的一個實現
一般在驅動中收包，使用的函數是 netif_rx 或者 netif_receive_skb，但在支持 LRO 的驅動中，需要使用下面的函數，這兩個函數將進來的數據包根據 LRO 描述符進行分類，如果可以進行聚集，則聚集爲一個超級數據包，否者直接傳遞給內核，走正常途徑。需要 lro_receive_frags 函數的原因是某些驅動直接將數據包放入了內存頁，之後去構造 sk_buff，對於這樣的驅動，應該使用下面的接口：
LRO 收包函數
struct sk_buff *skb,
void *priv);
void lro_receive_frags(struct net_lro_mgr *lro_mgr,
struct skb_frag_struct *frags,
int len, int true_size,
void *priv, __wsum sum);
因爲 LRO 需要聚集到 max_aggr 數目的數據包，但有些情況下可能導致延遲比較大，這種情況下，可以在聚集了部分包之後，直接傳遞給網絡協議棧處理，這時可以使用下面的函數，也可以在收到某個特殊的包之後，不經過 LRO，直接傳遞個網絡協議棧：
LRO flush 函數
struct sk_buff *skb,
void *priv);
void lro_receive_frags(struct net_lro_mgr *lro_mgr,
struct skb_frag_struct *frags,
int len, int true_size,
void *priv, __wsum sum);
GRO (Generic Receive Offload)
前面的 LRO 的核心在於：在接收路徑上，將多個數據包聚合成一個大的數據包，然後傳遞給網絡協議棧處理，但 LRO 的實現中存在一些瑕疵：
1、數據包合併可能會破壞一些狀態；
2、數據包合併條件過於寬泛，導致某些情況下本來需要區分的數據包也被合併了，這對於路由器是不可接收的；
3、在虛擬化條件下，需要使用橋接功能，但 LRO 使得橋接功能無法使用；
4、實現中，只支持 IPv4 的 TCP 協議。
而解決這些問題的辦法就是新提出的 GRO(Generic Receive Offload)，首先，GRO 的合併條件更加的嚴格和靈活，並且在設計時，就考慮支持所有的傳輸協議，因此，後續的驅動，都應該使用 GRO 的接口，而不是 LRO，內核可能在所有先有驅動遷移到 GRO 接口之後將 LRO 從內核中移除。而 Linux 網絡子系統的維護者 David S. Miller 就明確指出，現在的網卡驅動，有 2 個功能需要使用，一是使用 NAPI 接口以使得中斷緩和 (interrupt mitigation) ，以及簡單的互斥，二是使用 GRO 的 NAPI 接口去傳遞數據包給網路協議棧。
在 NAPI 實例中，有一個 GRO 的包的列表 gro_list，用堆積收到的包，GRO 層用它來將聚集的包分發到網絡協議層，而每個支持 GRO 功能的網絡協議層，則需要實現 gro_receive 和 gro_complete 方法。
協議層支持 GRO/GSO 的接口
__be16 type; /* This is really htons(ether_type). */
struct net_device *dev; /* NULL is wildcarded here */
int (*func) (struct sk_buff *,
struct net_device *,
struct packet_type *,
struct net_device *);
struct sk_buff *(*gso_segment)(struct sk_buff *skb,
int features);
int (*gso_send_check)(struct sk_buff *skb);
struct sk_buff **(*gro_receive)(struct sk_buff **head,
struct sk_buff *skb);
int (*gro_complete)(struct sk_buff *skb);
void *af_packet_priv;
struct list_head list;
};
其中，gro_receive 用於嘗試匹配進來的數據包到已經排隊的 gro_list 列表，而 IP 和 TCP 的頭部則在匹配之後被丟棄;而一旦我們需要向上層協議提交數據包，則調用 gro_complete 方法，將 gro_list 的包合併成一個大包，同時 checksum 也被更新。在實現中，並沒要求 GRO 長時間的去實現聚合，而是在每次 NAPI 輪詢操作中，強制傳遞 GRO 包列表跑到上層協議。GRO 和 LRO 的最大區別在於，GRO 保留了每個接收到的數據包的熵信息，這對於像路由器這樣的應用至關重要，並且實現了對各種協議的支持。以 IPv4 的 TCP 爲例，匹配的條件有：
1、源 / 目的地址匹配；
2、TOS/ 協議字段匹配；
3、源 / 目的端口匹配。
而很多其它事件將導致 GRO 列表向上層協議傳遞聚合的數據包，例如 TCP 的 ACK 不匹配或者 TCP 的序列號沒有按序等等。
GRO 提供的接口和 LRO 提供的接口非常的類似，但更加的簡潔，對於驅動，明確可見的只有 GRO 的收包函數了 , 因爲大部分的工作實際是在協議層做掉了：
GRO 收包接口
gro_result_t napi_gro_frags(struct napi_struct *napi)
小結
從上面的分析，可以看到，Linux 網絡性能優化方法，就像一部進化史，但每步的演化，都讓解決問題的辦法更加的通用，更加的靈活;從 NAPI 到 Newer newer NAPI，從 TSO 到 GSO，從 LRO 到 GRO，都是一個從特例到一個更通用的解決辦法的演化，正是這種漸進但連續的演化，讓 Linux 保有了如此的活力。