新聞中心

EEPW首頁 > 嵌入式系統(tǒng) > 設(shè)計(jì)應(yīng)用 > VxWorks下UDP協(xié)議棧效率的研究與改進(jìn)

VxWorks下UDP協(xié)議棧效率的研究與改進(jìn)

作者: 時(shí)間:2007-04-23 來源:網(wǎng)絡(luò) 收藏
摘要 電信網(wǎng)與計(jì)算機(jī)網(wǎng)的融合是一種趨勢。在實(shí)時(shí)嵌入式操作系統(tǒng)環(huán)境下,使用以太網(wǎng)上的,高效傳輸電信業(yè)務(wù)的信令與數(shù)據(jù)。描述在此情況下,根據(jù)實(shí)際需求對以太網(wǎng)傳輸中網(wǎng)絡(luò)設(shè)備驅(qū)動程序與棧進(jìn)行與探索。
關(guān)鍵詞 網(wǎng)絡(luò)設(shè)備驅(qū)動

1 使用標(biāo)準(zhǔn)UDP協(xié)議棧存在的問題
在VxWorks標(biāo)準(zhǔn)的IP協(xié)議實(shí)現(xiàn)的前提下,其UDP協(xié)議的實(shí)現(xiàn)存在于IP層。在VxWorks中有一個(gè)網(wǎng)絡(luò)任務(wù)(亦即進(jìn)程),用于完成以太網(wǎng)包的收發(fā)處理及與各種網(wǎng)絡(luò)協(xié)議的接口,其名為tNetTask,優(yōu)先級低于一般的系統(tǒng)任務(wù)而高于應(yīng)用程序任務(wù)。系統(tǒng)的上層網(wǎng)絡(luò)協(xié)議,如Telnet、FTP等,在服務(wù)器端有一個(gè)相應(yīng)的任務(wù),處理網(wǎng)絡(luò)任務(wù)轉(zhuǎn)交過來的數(shù)據(jù)報(bào)。

應(yīng)用程序想要實(shí)現(xiàn)UDP數(shù)據(jù)報(bào)的收發(fā),就要使用操作系統(tǒng)提供的socket編程接口,主要包括創(chuàng)建socket,綁定socket和源IP與端口號,發(fā)送UDP數(shù)據(jù)報(bào)和接收socket中收到的內(nèi)容。在VxWorks中有4個(gè)函數(shù)與之相對應(yīng),分別是:socket()、bind()、sendto()和recvfrom()。在VxWorks操作系統(tǒng)中,socket號是與文件打開描述符(fd)同樣管理的,一個(gè)socket與源IP和一個(gè)源端口相對應(yīng)。Sendto()函數(shù)調(diào)甩時(shí)指明目的的IP地址和服務(wù)端口號。

本文描述的UDP協(xié)議棧使用背景可簡要描述如下:該系統(tǒng)使用的主要硬件CPU平臺是摩托羅拉公司的MPC860的CPU,主頻為50 MHz;操作系統(tǒng)使用美國WindRiver公司的VxWorks。系統(tǒng)中各個(gè)設(shè)備(均有以太網(wǎng)接口)之間要在以太網(wǎng)上進(jìn)行信令與語音、數(shù)據(jù)業(yè)務(wù)的傳輸,各種數(shù)據(jù)包采用統(tǒng)一的消息頭編碼格式。

使用標(biāo)準(zhǔn)UDP協(xié)議棧最大的問題是。在該系統(tǒng)平臺上,網(wǎng)絡(luò)傳輸?shù)乃俾食蔀樽畲蟮钠款i,并由此影響了系統(tǒng)的容量。根據(jù)測試的極限速率,使用10M以太網(wǎng)的實(shí)際有效傳輸速率僅有1.8 Mb/s,使用100M以太網(wǎng)口電沒有明顯的提高。另外,還有一個(gè)問題,網(wǎng)絡(luò)任務(wù)經(jīng)常會掛起,在開機(jī)運(yùn)行較長時(shí)間后此現(xiàn)象尤為明顯,這對系統(tǒng)的可用性和無故障工作時(shí)間構(gòu)成威脅。而項(xiàng)目的目標(biāo)是實(shí)現(xiàn)高效穩(wěn)定的以太網(wǎng)包處理。

2 UDP協(xié)議棧的思想與理由
根據(jù)對VxWorks操作系統(tǒng)的,發(fā)現(xiàn)它對以太網(wǎng)包的處理與一般的IP協(xié)議棧有所不同。MAC層的控制由硬件寄存器來實(shí)現(xiàn),實(shí)現(xiàn)了發(fā)送方以太網(wǎng)幀的成幀和接收的以太網(wǎng)幀頭確認(rèn)以后,通過DMA方式實(shí)現(xiàn)內(nèi)存與網(wǎng)絡(luò)介質(zhì)間的通信,網(wǎng)絡(luò)任務(wù)與硬件之間通過設(shè)備中斷進(jìn)行通信。在該操作系統(tǒng)中,有一個(gè)MUX層,它提供統(tǒng)一的發(fā)送函數(shù),其參數(shù)為發(fā)送的網(wǎng)絡(luò)設(shè)備管理表指針和發(fā)送的數(shù)據(jù)報(bào)指針。我們知道,在一個(gè)有多個(gè)網(wǎng)絡(luò)設(shè)備同時(shí)工作的計(jì)算機(jī)系統(tǒng)中,標(biāo)準(zhǔn)的IP協(xié)議棧要完成選取從哪個(gè)網(wǎng)絡(luò)設(shè)備端口(gate way)發(fā)送和判斷ARP的Cache中是否有對端的MAC地址,從而決定是否啟動ARP進(jìn)行解析。在VxWorks中。是通過查Route表和ARP表來完成以上兩項(xiàng)工作的。Route表中儲存的是與每一個(gè)通信的子網(wǎng)的gart way,ARP表中儲存的是已知的IP地址與MAC地址的對應(yīng)關(guān)系。另外,數(shù)據(jù)報(bào)接收的處理過程中是在IP數(shù)據(jù)報(bào)存入內(nèi)存后申請MUX層的隊(duì)列緩沖區(qū),然后依次調(diào)用各上層協(xié)議的處理函數(shù)。

根據(jù)以上情況,考慮在MUX層修改UDP協(xié)議棧,在發(fā)送過程中,跳過socket接口,直接使用MUX層的發(fā)送函數(shù)。這樣,可以減少從UDP層網(wǎng)絡(luò)數(shù)據(jù)報(bào)緩沖區(qū)到MUX層緩沖區(qū)之間的復(fù)制工作,從而提高發(fā)送。在接收數(shù)據(jù)包的處理過程中,在MUX層收到數(shù)據(jù)報(bào)后鉤掛(hook)一個(gè)處理函數(shù),對UDP協(xié)議的數(shù)據(jù)包進(jìn)行分檢,優(yōu)先于其他協(xié)議的處理。這樣可減少從MUX層緩沖區(qū)到UDP層網(wǎng)絡(luò)數(shù)據(jù)報(bào)緩沖區(qū)之間的復(fù)制,而且可以不再要求上層使用輪誨的方法檢查socket的緩沖區(qū)中的內(nèi)容,提高了處理的實(shí)時(shí)性。

3 UDP協(xié)議棧出現(xiàn)的新問題
VxWorks的muxLib類庫中允許用戶自己定義一個(gè)協(xié)議棧,將協(xié)議棧綁定到一個(gè)具體的網(wǎng)絡(luò)端口上,同時(shí)要有一個(gè)處理函數(shù)對該網(wǎng)絡(luò)設(shè)備上收到的包進(jìn)行處理。加載改進(jìn)后的協(xié)議棧要先創(chuàng)建一組緩沖區(qū),每種緩沖區(qū)對應(yīng)不同的數(shù)據(jù)報(bào)長。預(yù)先分配一大塊內(nèi)存,可避免發(fā)送數(shù)據(jù)包時(shí)再去分配內(nèi)存,并可根據(jù)各種長度的數(shù)據(jù)報(bào)的使用頻度申請不同個(gè)數(shù)的緩沖區(qū)。發(fā)送過程中,要填寫IP首部的其他內(nèi)容,如協(xié)議版本號、UDP協(xié)議編號、idenfication域、IP首部校驗(yàn)和等等。在填寫的過程中,可以有意識地按照CPU的作業(yè)寬度和整數(shù)邊界進(jìn)行內(nèi)存賦值,提高發(fā)送效率。在接收過程中,要先判斷是否為UDP協(xié)議的數(shù)據(jù)報(bào)(根據(jù)第24字節(jié)為Oxll),然后做合法檢驗(yàn)。對本協(xié)議棧處理的數(shù)據(jù)報(bào),處理后要將其從MUX層的緩沖區(qū)隊(duì)列中刪除,未刪除的數(shù)據(jù)報(bào)由其他協(xié)議的處理函數(shù)處理。

經(jīng)過對協(xié)議棧的改進(jìn)發(fā)現(xiàn),在單向收發(fā)的環(huán)境下,發(fā)送效率提高了3倍左右;但是接收方效率的提高很不盡如人意,而且穩(wěn)定性仍然存在問題,在運(yùn)行幾十小時(shí)后,網(wǎng)絡(luò)任務(wù)的掛起現(xiàn)象出現(xiàn)得仍很頻繁。關(guān)于接收方的問題,原因是:接收方的網(wǎng)絡(luò)任務(wù)每收到一個(gè)包,從設(shè)備緩沖區(qū)搬移到應(yīng)用緩沖區(qū),然后切換到應(yīng)用程序任務(wù)進(jìn)行處理,處理結(jié)束以后再切換到網(wǎng)絡(luò)任務(wù)收下一包,如果接收速度高于處理速度就會造成阻塞。下面舉一個(gè)形象的例子:某個(gè)酒吧只有一個(gè)服務(wù)員,假設(shè)這個(gè)服務(wù)員要做兩件事情,有顧客來的時(shí)候要到門口去給顧客開門,然后再到柜臺為顧客服務(wù),顧客依到達(dá)次序排隊(duì)。假設(shè)門口和柜臺之間的移動時(shí)間不能忽略,并且為顧客開門的優(yōu)先級比較高,就是說如果有新顧客到來,必須先放下正在服務(wù)的顧客去開門。在這種情況下,如果顧客的到來間隔是均勻的,為每一位顧客服務(wù)要服務(wù)員跑兩趟。如果顧客到達(dá)的間隔比較小,就出現(xiàn)服務(wù)員在門口和柜臺之間頻繁移動的情況。假如能使顧客分撥到達(dá),每次有多個(gè)顧客到達(dá),服務(wù)員就可以從柜臺到門口開門讓多個(gè)顧客進(jìn)入,再回柜臺為顧客服務(wù)。試驗(yàn)證明,在這種模型下接收效率能大幅提高,但是對均勻到達(dá)的顧客服務(wù)效率的提高難以得到解決。

4 深入網(wǎng)絡(luò)設(shè)備驅(qū)動
經(jīng)過對操作系統(tǒng)更為深入的發(fā)現(xiàn),MUX層的發(fā)送數(shù)據(jù)包最終是通過調(diào)用網(wǎng)絡(luò)設(shè)備驅(qū)動程序中的發(fā)送函數(shù)實(shí)現(xiàn)的。分析網(wǎng)絡(luò)設(shè)備驅(qū)動的代碼發(fā)現(xiàn),其發(fā)送過程可描述為:

◇檢查設(shè)備緩沖區(qū)(BD表)是否有可用BD;
◇根據(jù)設(shè)備緩沖區(qū)的可用情況與發(fā)送數(shù)據(jù)包的長度,判斷是否需要進(jìn)行分片;
◇根據(jù)設(shè)備緩沖區(qū)的可用情況決定傳輸發(fā)送還是拷貝發(fā)送;
◇置位設(shè)備控制寄存器,啟動DMA傳輸,并引發(fā)設(shè)備收發(fā)中斷;
◇清除使用過的設(shè)備緩沖區(qū)。

另據(jù)分析,在設(shè)備驅(qū)動的安裝過程中完成的工作有:
◇根據(jù)配置數(shù)據(jù)申請內(nèi)存,構(gòu)建設(shè)備緩沖區(qū)表;
◇指定DMA使用的通道與工作方式;
◇配置設(shè)備寄存器(工作方式、幀類型、設(shè)備緩沖區(qū)表指針等);
◇連接設(shè)備中斷處理例程。

接收過程中,是在網(wǎng)絡(luò)設(shè)備收到數(shù)據(jù)包后啟動DMA傳輸至內(nèi)存,并引發(fā)中斷,在中斷處理程序中處理緩沖區(qū)指針,然后將一個(gè)函數(shù)處理指針寫入一個(gè)環(huán)型緩沖區(qū),最后是釋放一個(gè)信號量,通知網(wǎng)絡(luò)任務(wù)對收到的數(shù)據(jù)包進(jìn)行處理。通過對該接收處理函數(shù)的反匯編解讀,發(fā)現(xiàn)它的主要工作是申請MUX層的緩沖區(qū)并復(fù)制,處理設(shè)備緩沖區(qū)的指針,然后調(diào)用各個(gè)協(xié)議的處理函數(shù)。

根據(jù)以上的認(rèn)識,有了一個(gè)更為大膽的設(shè)想:跳過MUX層,直接使用driver的發(fā)函數(shù)進(jìn)行發(fā)送;在接收過程中,對本協(xié)議棧的數(shù)據(jù)包不再申請MUX層的緩沖區(qū),而是直接拷貝到應(yīng)用層緩沖區(qū),并可將處理接口留給用戶。另外一個(gè)想法是,直接在中斷處理例程中進(jìn)行處理,從而徹底拋棄網(wǎng)絡(luò)任務(wù)。據(jù)此在百兆網(wǎng)絡(luò)設(shè)備上完成了修改,其效率又提高將近l倍,滿足了使用的要求;而且更為可喜的是,系統(tǒng)的穩(wěn)定性大幅提高。

5 結(jié)論與數(shù)據(jù)分析
幾種情況下的測試結(jié)果如下:

通過對上述數(shù)據(jù)的分析看出,使用MUX層的協(xié)議棧組發(fā)環(huán)境下,比使用標(biāo)準(zhǔn)協(xié)議棧發(fā)送的效率提高3倍左右,但是在均勻收發(fā)的情況下提高并不明顯。直接使用中斷方式克服了這一缺陷,比均勻收發(fā)的環(huán)境下又提高1倍。

但是這個(gè)測試結(jié)果只是在短包的情況下完成的,包長在100字節(jié)以下。通過對長包的測試,發(fā)現(xiàn)對512字節(jié)以上的長包的影響要稍微小一些。這是因?yàn)樵谕凰俾氏拢褂瞄L包調(diào)用的次數(shù)要少,改進(jìn)的效果也就稍差,特別是在CPU主頻更高的環(huán)境下,這一現(xiàn)象更為明顯。

6 對實(shí)時(shí)操作系統(tǒng)的一點(diǎn)看法
通過對設(shè)備驅(qū)動的研究發(fā)現(xiàn).在實(shí)時(shí)操作系統(tǒng)中,中斷處理例程的處理時(shí)間都比較短,這也是實(shí)現(xiàn)實(shí)時(shí)性的一個(gè)重要思想。在改進(jìn)中,中斷處理例程中加入了執(zhí)行代碼,會影響系統(tǒng)的實(shí)時(shí)性,似乎違背了實(shí)時(shí)操作系統(tǒng)的初衷。但筆者認(rèn)為,這個(gè)問題要在實(shí)際的環(huán)境下進(jìn)行評價(jià),中斷中的通知網(wǎng)絡(luò)任務(wù)與網(wǎng)絡(luò)任務(wù)的執(zhí)行,兩者加起來的時(shí)間一定要比只在中斷中處理需要的時(shí)間要長。這與IP包處理機(jī)的目標(biāo)也是沒有矛盾的,完全不必拘泥陳規(guī)。實(shí)時(shí)系統(tǒng)只是追求平均的響應(yīng)時(shí)間較短,而在最差情況下則遠(yuǎn)低于平均水平。



評論


技術(shù)專區(qū)

關(guān)閉