基于ARM的嵌入式Linux網(wǎng)絡(luò)數(shù)據(jù)傳輸性能分析

宋洪治 武杰 張杰 孔陽 馬毅超

1(中國(guó)科學(xué)技術(shù)大學(xué)物理系 合肥 230026)

2(中國(guó)科學(xué)技術(shù)大學(xué)近代物理系 合肥 230026)

作為一種通用可靠的網(wǎng)絡(luò)傳輸技術(shù)，以太網(wǎng)技術(shù)幾乎存在于所有實(shí)驗(yàn)中[1]，很多實(shí)驗(yàn)采用以太網(wǎng)將讀出電子學(xué)模塊的數(shù)據(jù)傳送到更高級(jí)別系統(tǒng)[2–5]。為完成網(wǎng)絡(luò)數(shù)據(jù)傳輸任務(wù)，一般需操作系統(tǒng)的支持，采用的操作系統(tǒng)主要有 VxWorks[3]和 Linux[2,6]。其中，Linux系統(tǒng)開源低成本，為研究者所熟知，且有成熟穩(wěn)定的網(wǎng)絡(luò)協(xié)議棧，非常適合網(wǎng)絡(luò)通信。

本文基于ARM處理器用Linux 2.4內(nèi)核構(gòu)建了用于數(shù)據(jù)傳輸?shù)那度胧较到y(tǒng)。結(jié)合具體數(shù)據(jù)分析了系統(tǒng)數(shù)據(jù)接收過程，給出系統(tǒng)性能變化的原因及優(yōu)化的方向。

1 系統(tǒng)結(jié)構(gòu)和分析

系統(tǒng)以ARM處理器為核心，使用以太網(wǎng)傳輸數(shù)據(jù)。為保證數(shù)據(jù)傳輸?shù)目煽啃裕W(wǎng)絡(luò)傳輸使用TCP/IP協(xié)議。在不考慮EMAC(Ethernet MAC)和物理層操作情況下，用TCP發(fā)送數(shù)據(jù)消耗的處理器周期為接收數(shù)據(jù)的～4/5[7]。為測(cè)試系統(tǒng)在更大壓力下的表現(xiàn)，采用TCP接收數(shù)據(jù)的方式。

1.1 硬件系統(tǒng)

1.2 Linux網(wǎng)絡(luò)數(shù)據(jù)包的接收

系統(tǒng)接收數(shù)據(jù)包過程[8–11]如圖1。網(wǎng)絡(luò)質(zhì)量很好而大量接收數(shù)據(jù)時(shí)，可忽略失序的TCP報(bào)文。

圖1 Linux網(wǎng)絡(luò)子系統(tǒng)TCP協(xié)議收包過程Fig.1 The packet receiving process of Linux networking subsystem for TCP.

Linux網(wǎng)絡(luò)子系統(tǒng)通過軟中斷[8,9]機(jī)制處理接收的數(shù)據(jù)包。鏈路層收到的數(shù)據(jù)幀由 EMAC通過DMA(Direct Memory Access)操作復(fù)制到環(huán)形緩存。環(huán)形緩存由多個(gè)能容納最大鏈路幀長(zhǎng)的接收緩存構(gòu)成。一個(gè)接收緩存有“準(zhǔn)備”和“使用”兩種狀態(tài)。EMAC只可向“準(zhǔn)備”態(tài)的接收緩存復(fù)制數(shù)據(jù)幀；處于“使用”態(tài)的接收緩存只有被網(wǎng)絡(luò)驅(qū)動(dòng)讀取，并重置為“準(zhǔn)備”態(tài)后才能重新被EMAC使用。通常TCP數(shù)據(jù)包接收分為如下三階段。

1.2.1 以太網(wǎng)數(shù)據(jù)幀通過物理層到達(dá)MAC層

此時(shí)，EMAC自動(dòng)檢查數(shù)據(jù)幀的前導(dǎo)、目的物理地址和循環(huán)冗余校驗(yàn)(CRC)，并啟動(dòng)DMA操作將其復(fù)制到一個(gè)處“準(zhǔn)備”態(tài)的接收緩存中。如數(shù)據(jù)幀有效，EMAC會(huì)將該接收緩存置為“使用”態(tài)，并產(chǎn)生收到數(shù)據(jù)幀的中斷。網(wǎng)絡(luò)驅(qū)動(dòng)響應(yīng)這個(gè)中斷并做如下操作：(1) 分配 sk_buff[8,9,12]對(duì)象；(2) 復(fù)制接收緩存中內(nèi)容到sk_buff對(duì)象；(3) 根據(jù)數(shù)據(jù)幀封裝協(xié)議更新sk_buff對(duì)象中的控制信息；(4) 將sk_buff對(duì)象添加到當(dāng)前處理器的接收隊(duì)列中；(5) 產(chǎn)生軟中斷通知協(xié)議棧新數(shù)據(jù)幀的到來；(6) 重置接收緩存為“準(zhǔn)備”態(tài)。為避免中斷響應(yīng)不及時(shí)，設(shè)備驅(qū)動(dòng)在每次收到中斷時(shí)對(duì)所有處于“使用”態(tài)的接收緩存使用上述操作。如果沒有可用接收緩存，EMAC將丟棄收到的幀。同樣，在EMAC成功接收數(shù)據(jù)幀，但分配 sk_buff失敗情況下，設(shè)備驅(qū)動(dòng)也會(huì)丟棄對(duì)應(yīng)的幀。TCP連接有流量控制[13]機(jī)制，所以通常不出現(xiàn)分配 sk_buff失敗的情況。出于效率的考慮，一個(gè) sk_buff對(duì)象包含足夠大空間來容納協(xié)議棧中每一層添加的控制信息，且一直處于內(nèi)存中同一位置，從而避免了數(shù)據(jù)的跨層復(fù)制操作。

1.2.2 協(xié)議棧響應(yīng)軟中斷，在系統(tǒng)的中斷上下文中處理收到的數(shù)據(jù)幀

網(wǎng)絡(luò)層的IP協(xié)議處理完數(shù)據(jù)幀后，將數(shù)據(jù)包送到傳輸層交給TCP協(xié)議處理。Linux 2.4的TCP用預(yù)收隊(duì)列、接收隊(duì)列、候補(bǔ)隊(duì)列或失序隊(duì)列處理收到的數(shù)據(jù)包。這里數(shù)據(jù)包有三種可能的傳輸路徑：

(1) 如果軟中斷發(fā)生時(shí)，進(jìn)程正在內(nèi)核空間中操作隊(duì)列接收數(shù)據(jù)，則數(shù)據(jù)包會(huì)被放到候補(bǔ)隊(duì)列中等待進(jìn)程進(jìn)一步處理。

（最新消息：經(jīng)過作者修訂的第四版《養(yǎng)生三記》，增補(bǔ)了很多精彩篇章，新版已由黑龍江科技出版社出版發(fā)行，各地新華書店將陸續(xù)到貨。辦理郵購(gòu)的地點(diǎn)為：哈爾濱市南崗區(qū)人和街93號(hào)，收款人：彭祖補(bǔ)品屋。勿寄私人，以免延誤。書價(jià)40元，免收郵費(fèi)。免費(fèi)聯(lián)系電話：400-609-2883，匯款單附言請(qǐng)寫明您的詳細(xì)地址和電話，以便給您寄書。）

(2) 如果此時(shí)接收數(shù)據(jù)的進(jìn)程正因?yàn)榈却谕臄?shù)據(jù)而睡眠，數(shù)據(jù)包會(huì)被放到進(jìn)程的預(yù)收隊(duì)列中。預(yù)收隊(duì)列主要為實(shí)現(xiàn)計(jì)算校驗(yàn)和并復(fù)制到用戶空間的操作[14]，以節(jié)省CPU周期。預(yù)收隊(duì)列無溢出時(shí)，其中的數(shù)據(jù)包在進(jìn)程上下文中處理。若送到預(yù)收隊(duì)列中的sk_buff對(duì)象的總緩存長(zhǎng)度超過TCP協(xié)議棧預(yù)先設(shè)定的接收緩存大小，系統(tǒng)判定預(yù)收隊(duì)列溢出。此時(shí)，預(yù)收隊(duì)列中的數(shù)據(jù)包將在中斷上下文中處理。

如滿足快速路徑條件：TCP包沒有失序、當(dāng)前進(jìn)程正是讀取當(dāng)前套接字的進(jìn)程、應(yīng)用程序提供足夠大用戶空間接收緩存能容納當(dāng)前 TCP數(shù)據(jù)包所有數(shù)據(jù)，則數(shù)據(jù)包將通過快速路徑，以計(jì)算校驗(yàn)和并復(fù)制的方式直接到達(dá)用戶緩存。否則TCP數(shù)據(jù)包將通過慢速路徑。

慢速路徑中，未失序TCP包經(jīng)處理后被發(fā)送到接收隊(duì)列，失序者則送到失序隊(duì)列。若能大量連續(xù)地接收數(shù)據(jù)，則認(rèn)為網(wǎng)絡(luò)條件很好，可忽略TCP數(shù)據(jù)包失序，故圖1未給出失序時(shí)的數(shù)據(jù)傳輸路徑。

(3) 如在軟中斷時(shí)，進(jìn)程既不在操作隊(duì)列，也不在等待網(wǎng)絡(luò)數(shù)據(jù)，說明進(jìn)程此時(shí)正運(yùn)行或休眠在與網(wǎng)絡(luò)接收無關(guān)的地方。此時(shí)，收到的數(shù)據(jù)包會(huì)依據(jù)快速路徑條件通過快速或慢速路徑。

1.2.3 用戶進(jìn)程通過系統(tǒng)調(diào)用在進(jìn)程上下文中處理接收到的數(shù)據(jù)

進(jìn)程上下文中，將按先預(yù)收隊(duì)列、再接收隊(duì)列、最后候補(bǔ)隊(duì)列的優(yōu)先次序處理數(shù)據(jù)。接收隊(duì)列中數(shù)據(jù)被直接復(fù)制到用戶空間接收緩存。與軟中斷中預(yù)收隊(duì)列溢出時(shí)數(shù)據(jù)的流向類似，預(yù)收和候補(bǔ)隊(duì)列中的數(shù)據(jù)將通過快速或慢速路徑到達(dá)用戶空間或接收隊(duì)列。與軟中斷中情況不同的是，慢速路徑中如滿足當(dāng)前進(jìn)程是接收當(dāng)前數(shù)據(jù)包的進(jìn)程，當(dāng)前數(shù)據(jù)包序號(hào)是期望的序號(hào)，且有足夠的用戶空間接收緩存，則數(shù)據(jù)被復(fù)制到用戶空間，而非接收隊(duì)列中。

2 測(cè)試和分析

為測(cè)量系統(tǒng)用 TCP/IP協(xié)議從以太網(wǎng)接收數(shù)據(jù)時(shí)各部分消耗的處理器時(shí)間，用AT91RM9200三個(gè)定時(shí)計(jì)數(shù)器級(jí)聯(lián)成一個(gè)運(yùn)行在30 MHz頻率下的48位計(jì)數(shù)器，統(tǒng)計(jì)內(nèi)核相關(guān)部分的運(yùn)行時(shí)間。

根據(jù)Linux 2.4內(nèi)核TCP/IP協(xié)議棧結(jié)構(gòu)特點(diǎn)，將計(jì)時(shí)區(qū)段劃分為：(1) 不在中斷響應(yīng)中運(yùn)行的驅(qū)動(dòng)程序時(shí)間，(2) 中斷響應(yīng)中運(yùn)行的驅(qū)動(dòng)程序時(shí)間，(3) 軟中斷中運(yùn)行的協(xié)議棧發(fā)送數(shù)據(jù)代碼的運(yùn)行時(shí)間，(4) 軟中斷中運(yùn)行的協(xié)議棧接收數(shù)據(jù)代碼的運(yùn)行時(shí)間，(5) 不在軟中斷中運(yùn)行的協(xié)議棧接收數(shù)據(jù)代碼的運(yùn)行時(shí)間，(6) 不在軟中斷中運(yùn)行的發(fā)送數(shù)據(jù)代碼的運(yùn)行時(shí)間，(7) TCP重傳定時(shí)器運(yùn)行時(shí)間，(8) TCP延遲確認(rèn)定時(shí)器運(yùn)行時(shí)間，(9) TCP?；疃〞r(shí)器運(yùn)行時(shí)間，(10) 總運(yùn)行時(shí)間。

根據(jù)測(cè)得各個(gè)時(shí)間的值，得到網(wǎng)絡(luò)驅(qū)動(dòng)程序及TCP/IP協(xié)議棧的運(yùn)行時(shí)間和系統(tǒng)其它部分運(yùn)行所需時(shí)間：

除測(cè)量協(xié)議棧消耗時(shí)間外，還記錄了TCP接收相關(guān)的其它信息。

測(cè)試時(shí)，數(shù)據(jù)從PC送出，直接到達(dá)目標(biāo)板。測(cè)試條件為：網(wǎng)絡(luò)用TCP連接，發(fā)送方發(fā)送256 MB數(shù)據(jù)，接收方用64 KB協(xié)議棧接收緩存，用recv系統(tǒng)調(diào)用配合 MSG_WAITALL選項(xiàng)使用不同用戶緩存接收數(shù)據(jù)。

圖2是有無使用性能測(cè)試代碼時(shí)不同用戶空間接收緩存下系統(tǒng)接收數(shù)據(jù)的速率。

圖2 不同用戶空間接收緩存下的接收速率Fig.2 Rx throughput with various Rx buffer in user space.

系統(tǒng)接收數(shù)據(jù)時(shí)，無論何種情況，處理器使用率都一直處于100%。由圖2，接收速率隨用戶空間緩存增大而增大。沒用測(cè)試代碼、用戶空間緩存達(dá)64 K字節(jié)時(shí)，系統(tǒng)的接收速率飽和。即對(duì)200 MHz的 ARM9處理器能力，如其配置和 AT91RM9200相當(dāng)，想要充分發(fā)揮百兆以太網(wǎng)數(shù)據(jù)傳輸速度，至少需開辟64 K字節(jié)用戶空間緩存。使用性能測(cè)試代碼、用戶空間緩存4 M字節(jié)時(shí)，接收速率飽和。

圖3是不同用戶空間接收緩存下各計(jì)時(shí)區(qū)段占用的時(shí)間。對(duì)當(dāng)前測(cè)試，目標(biāo)板不發(fā)送數(shù)據(jù)，則重傳定時(shí)器不運(yùn)行。由于目標(biāo)板連續(xù)接收數(shù)據(jù)，延時(shí)確認(rèn)定時(shí)器超時(shí)前就被重置。而且并沒使能保活定時(shí)器(Keep-alive timer)，故圖3未給出這三個(gè)運(yùn)行時(shí)間為零的定時(shí)器的運(yùn)行時(shí)間數(shù)據(jù)。

圖3 不同用戶空間接收緩存下TCP處理的時(shí)間分布Fig.3 TCP processing time distribution with various Rx buffer in user space.

表1給出與TCP接收相關(guān)的其它一些測(cè)量值。在進(jìn)程上下文即將處理接收隊(duì)列前，接收隊(duì)列中sk_buff對(duì)象的數(shù)目被累加。將累加的結(jié)果與接收隊(duì)列的處理次數(shù)相比就得到了接收隊(duì)列中 sk_buff的平均個(gè)數(shù)。TCP直接復(fù)制比率是指從預(yù)收或候補(bǔ)隊(duì)列中以計(jì)算校驗(yàn)和并復(fù)制操作直接復(fù)制到用戶空間緩存的數(shù)據(jù)占總接收數(shù)據(jù)的百分比。歸一化回應(yīng)包個(gè)數(shù)是目標(biāo)板發(fā)送給PC回應(yīng)包個(gè)數(shù)與TCP層接收到sk_buff對(duì)象數(shù)目的比值。測(cè)試結(jié)果顯示TCP層收到sk_buff對(duì)象的數(shù)目不變。

表1 不同用戶空間緩存下TCP接收相關(guān)測(cè)量值Table 1 Measured items related to TCP receiving process with various user space Rx buffer.

由測(cè)試條件可知，系統(tǒng)調(diào)用只有復(fù)制了足夠數(shù)據(jù)到用戶空間后才會(huì)返回，所以小用戶空間接收緩存會(huì)造成更多的系統(tǒng)調(diào)用次數(shù)，這不僅增加不在軟中斷中運(yùn)行的協(xié)議棧接收代碼的時(shí)間，還大幅增加系統(tǒng)的額外開銷。當(dāng)應(yīng)用程序用套接字讀取數(shù)據(jù)時(shí)，首先會(huì)通過 C庫(kù)執(zhí)行 Linux系統(tǒng)調(diào)用進(jìn)入內(nèi)核空間；然后在內(nèi)核空間通過文件系統(tǒng)抽象層得到該操作對(duì)應(yīng)的對(duì)象，即套接字層；最后，在套接字層數(shù)據(jù)被復(fù)制到用戶空間。因每一次操作都產(chǎn)生一個(gè)層層遞進(jìn)的額外開銷，所以圖3顯示小接收緩存下系統(tǒng)額外開銷占很大比例。

目標(biāo)板收到數(shù)據(jù)后需發(fā)送回應(yīng)包給PC。由表1平均通告窗口大小和歸一化回應(yīng)包個(gè)數(shù)知，相對(duì)大用戶空間緩存情況，小用戶空間緩存下目標(biāo)板將發(fā)送更多有更小通告窗口大小的回應(yīng)包。更多的回應(yīng)包，增加了軟中斷中運(yùn)行協(xié)議棧發(fā)送數(shù)據(jù)代碼和網(wǎng)絡(luò)驅(qū)動(dòng)非中斷響應(yīng)部分的運(yùn)行時(shí)間。由于EMAC發(fā)完數(shù)據(jù)后會(huì)產(chǎn)生中斷，所以這也意味著更多中斷，即更多的網(wǎng)絡(luò)驅(qū)動(dòng)中斷響應(yīng)代碼的運(yùn)行時(shí)間。

由圖1，若在軟中斷上下文中處理了sk_buff對(duì)象，只有兩種情況：預(yù)收隊(duì)列溢出，或使用當(dāng)前套接字的應(yīng)用程序運(yùn)行或休眠在 TCP接收無關(guān)的地方。TCP有流量控制機(jī)制，所以當(dāng)前測(cè)試條件下接收數(shù)據(jù)時(shí)不應(yīng)出現(xiàn)預(yù)收隊(duì)列溢出的情況。測(cè)試表明預(yù)收隊(duì)列溢出的次數(shù)為0，證實(shí)預(yù)收隊(duì)列不會(huì)溢出。結(jié)合表1和圖3，在系統(tǒng)其它開銷很大，即小用戶空間緩存情況下，軟中斷發(fā)生時(shí)應(yīng)用程序運(yùn)行于TCP接收相關(guān)代碼處的概率降低，導(dǎo)致軟中斷處理sk_buff對(duì)象比例增大，增加了系統(tǒng)在軟中斷上下文中接收數(shù)據(jù)的時(shí)間。

表1的TCP直接復(fù)制比率表明，小用戶空間接收緩存下收到的數(shù)據(jù)沒有直接達(dá)用戶空間，而是通過接收隊(duì)列進(jìn)行了一次中轉(zhuǎn)。測(cè)試表明，每個(gè)sk_buff對(duì)象均包含1448字節(jié)用戶數(shù)據(jù)(包含時(shí)間戳選項(xiàng)的TCP包)，結(jié)合表1接收隊(duì)列中sk_buff的平均個(gè)數(shù)算出，用戶緩存小于64 K時(shí)，接收隊(duì)列中平均數(shù)據(jù)量大于用戶緩存大小。這導(dǎo)致接收隊(duì)列不能為空，由圖 1，此時(shí)進(jìn)程不會(huì)休眠等待網(wǎng)絡(luò)數(shù)據(jù)，則收到的數(shù)據(jù)要么到候補(bǔ)隊(duì)列延遲到進(jìn)程上下文中處理，要么直接在軟中斷中處理。在進(jìn)程上下文中處理數(shù)據(jù)時(shí)，接收隊(duì)列先于候補(bǔ)隊(duì)列處理，則處理候補(bǔ)隊(duì)列時(shí)，用戶緩存已被接收隊(duì)列填滿，不滿足快速路徑條件，數(shù)據(jù)只能送到接收隊(duì)列。同樣，軟中斷中滿足快速路徑條件的概率降低，基本上所有數(shù)據(jù)被送到接收隊(duì)列。用戶緩存不小于64 K時(shí)，接收隊(duì)列中平均數(shù)據(jù)量小于用戶緩存，快速路徑條件易滿足，基本上所有數(shù)據(jù)被直接復(fù)制到用戶空間。

由圖 3，不同用戶緩存條件下，在非軟中斷中運(yùn)行的接收代碼和網(wǎng)絡(luò)驅(qū)動(dòng)中斷響應(yīng)部分占用了系統(tǒng)大部分處理器時(shí)間。非軟中斷中接收代碼的大部分時(shí)間都消耗在sk_buff對(duì)象的處理上。由圖1，如進(jìn)程長(zhǎng)時(shí)間運(yùn)行在網(wǎng)絡(luò)接收無關(guān)的地方，則這部分時(shí)間會(huì)被轉(zhuǎn)移到軟中斷中運(yùn)行的接收代碼處。所以作為非內(nèi)核開發(fā)者，對(duì)Linux 2.4內(nèi)核接收性能優(yōu)化在內(nèi)核層面主要是對(duì)網(wǎng)絡(luò)驅(qū)動(dòng)中斷響應(yīng)部分的優(yōu)化。

結(jié)合上面分析，在應(yīng)用程序?qū)用鎸?duì)系統(tǒng)性能優(yōu)化主要是盡量減少系統(tǒng)調(diào)用次數(shù)，盡量增加直接復(fù)制到用戶空間數(shù)據(jù)的比例，即綜合考慮系統(tǒng)資源和性能前提下，選用合適大小的用戶空間接收緩存。

3 結(jié)論

本文從數(shù)據(jù)流角度分析了 Linux 2.4內(nèi)核TCP/IP協(xié)議棧接收數(shù)據(jù)的過程，并結(jié)合具體測(cè)試結(jié)果分析了不同用戶空間緩存條件下系統(tǒng)網(wǎng)絡(luò)接收性能的變化及具體原因，并給出優(yōu)化系統(tǒng)性能的方向。

1 Denis Calvet.IEEE Trans Nucl Sci, 2006, 53(3): 789–794

2 Youichi Igarashi, Hirofumi Fujii, Takeo Higuchi, et al.IEEE Nucl Sci Symp Conf Rec, 2004, 2: 1122–1126

3 Tao N, Chu Y P, Jin G, et al.Plasma Sci Technol, 2005,7(5): 3065–3068

4 Giuseppe Avolio.IEEE Trans Nucl Sci, 2004, 51(5):2081–2085

5 Artur Barczyk, Jean-Pierre Dufey, Clara Gaspar, et al.IEEE Trans Nucl Sci, 2004, 51(3):456–460

6 Ji X L, Li F, Ye M, et al.IEEE Nucl Sci Symp Conf Rec,2008, 2119–2121

7 Won Chulho, Lee Ben, Yu C S, et al.J High Speed Networks, 2004, 13(3): 169–182

8 Bovet D P, Cesati M.Understanding the Linux Kernel.2nd ed, O'Reilly Media, 2002.ISBN: 0-596-00213-0

9 Christian Benvenuti.Understanding Linux Network Internals.O'Reilly Media, 2005.ISBN: 0-596-00255-6

10 Wu W J, Crawford M, Bowden M.Comput Commun,2007, 30(5): 1044–1057

11 Wu W J, Crawford M.International J Commun Syst, 2007,20: 1263–1283

12 Jonathan Corbet, Alessandro Rubini.Linux Device Drivers.2nd ed, O'Reilly Media, 2001.ISBN:0-596-0008-1

13 Stevens W R.TCP/IP Illustrated.Vol 1, The Protocols,Addison-Wesley Professional, 1994.ISBN: 0201633469

14 Clark D D, Van Jacobson, Romkey J, et al.IEEE Commun Mag, 1989, 27(6): 23–29