關鍵詞 VxWorks UDP 協議棧效率 網絡設備驅動
1 使用VxWorks標準UDP協議棧存在的問題
在VxWorks標準的IP協議實現的前提下，其UDP協議的實現存在于IP層。在VxWorks中有一個網絡任務(亦即進程)，用于完成以太網包的收發(fā)處理及與各種網絡協議的接口，其名為tNetTask，優(yōu)先級低于一般的系統(tǒng)任務而高于應用程序任務。系統(tǒng)的上層網絡協議，如Telnet、FTP等，在服務器端有一個相應的任務，處理網絡任務轉交過來的數據報。
應用程序想要實現UDP數據報的收發(fā)，就要使用操作系統(tǒng)提供的socket編程接口，主要包括創(chuàng)建socket，綁定socket和源IP與端口號，發(fā)送UDP數據報和接收socket中收到的內容。在VxWorks中有4個函數與之相對應，分別是：socket()、bind()、sendto()和recvfrom()。在VxWorks操作系統(tǒng)中，socket號是與文件打開描述符(fd)同樣管理的，一個socket與源IP和一個源端口相對應。Sendto()函數調甩時指明目的的IP地址和服務端口號。
本文描述的UDP協議棧使用背景可簡要描述如下：該系統(tǒng)使用的主要硬件CPU平臺是摩托羅拉公司的MPC860的CPU，主頻為50 MHz；操作系統(tǒng)使用美國WindRiver公司的VxWorks。系統(tǒng)中各個設備(均有以太網接口)之間要在以太網上進行信令與語音、數據業(yè)務的傳輸，各種數據包采用統(tǒng)一的消息頭編碼格式。
使用標準UDP協議棧最大的問題是效率。在該系統(tǒng)平臺上，網絡傳輸的速率成為最大的瓶頸，并由此影響了系統(tǒng)的容量。根據測試的極限速率，使用10M以太網的實際有效傳輸速率僅有1.8 Mb／s，使用100M以太網口電沒有明顯的提高。另外，還有一個問題，網絡任務經常會掛起，在開機運行較長時間后此現象尤為明顯，這對系統(tǒng)的可用性和無故障工作時間構成威脅。而項目的目標是實現高效穩(wěn)定的以太網包處理。
2 改進UDP協議棧的思想與理由
根據對VxWorks操作系統(tǒng)的研究，發(fā)現它對以太網包的處理與一般的IP協議棧有所不同。MAC層的控制由硬件寄存器來實現，實現了發(fā)送方以太網幀的成幀和接收的以太網幀頭確認以后，通過DMA方式實現內存與網絡介質間的通信，網絡任務與硬件之間通過設備中斷進行通信。在該操作系統(tǒng)中，有一個MUX層，它提供統(tǒng)一的發(fā)送函數，其參數為發(fā)送的網絡設備管理表指針和發(fā)送的數據報指針。我們知道，在一個有多個網絡設備同時工作的計算機系統(tǒng)中，標準的IP協議棧要完成選取從哪個網絡設備端口(gate way)發(fā)送和判斷ARP的Cache中是否有對端的MAC地址，從而決定是否啟動ARP進行解析。在VxWorks中。是通過查Route表和ARP表來完成以上兩項工作的。Route表中儲存的是與每一個通信的子網的gart way，ARP表中儲存的是已知的IP地址與MAC地址的對應關系。另外，數據報接收的處理過程中是在IP數據報存入內存后申請MUX層的隊列緩沖區(qū)，然后依次調用各上層協議的處理函數。
根據以上情況，考慮在MUX層修改UDP協議棧，在發(fā)送過程中，跳過socket接口，直接使用MUX層的發(fā)送函數。這樣，可以減少從UDP層網絡數據報緩沖區(qū)到MUX層緩沖區(qū)之間的復制工作，從而提高發(fā)送效率。在接收數據包的處理過程中，在MUX層收到數據報后鉤掛(hook)一個處理函數，對UDP協議的數據包進行分檢，優(yōu)先于其他協議的處理。這樣可減少從MUX層緩沖區(qū)到UDP層網絡數據報緩沖區(qū)之間的復制，而且可以不再要求上層使用輪誨的方法檢查socket的緩沖區(qū)中的內容，提高了處理的實時性。
3 改進UDP協議棧出現的新問題
VxWorks的muxLib類庫中允許用戶自己定義一個協議棧，將協議棧綁定到一個具體的網絡端口上，同時要有一個處理函數對該網絡設備上收到的包進行處理。加載改進后的協議棧要先創(chuàng)建一組緩沖區(qū)，每種緩沖區(qū)對應不同的數據報長。預先分配一大塊內存，可避免發(fā)送數據包時再去分配內存，并可根據各種長度的數據報的使用頻度申請不同個數的緩沖區(qū)。發(fā)送過程中，要填寫IP首部的其他內容，如協議版本號、UDP協議編號、idenfication域、IP首部校驗和等等。在填寫的過程中，可以有意識地按照CPU的作業(yè)寬度和整數邊界進行內存賦值，提高發(fā)送效率。在接收過程中，要先判斷是否為UDP協議的數據報(根據第24字節(jié)為Oxll)，然后做合法檢驗。對本協議棧處理的數據報，處理后要將其從MUX層的緩沖區(qū)隊列中刪除，未刪除的數據報由其他協議的處理函數處理。
經過對協議棧的改進發(fā)現，在單向收發(fā)的環(huán)境下，發(fā)送效率提高了3倍左右；但是接收方效率的提高很不盡如人意，而且穩(wěn)定性仍然存在問題，在運行幾十小時后，網絡任務的掛起現象出現得仍很頻繁。關于接收方的問題，原因是：接收方的網絡任務每收到一個包，從設備緩沖區(qū)搬移到應用緩沖區(qū)，然后切換到應用程序任務進行處理，處理結束以后再切換到網絡任務收下一包，如果接收速度高于處理速度就會造成阻塞。下面舉一個形象的例子：某個酒吧只有一個服務員，假設這個服務員要做兩件事情，有顧客來的時候要到門口去給顧客開門，然后再到柜臺為顧客服務，顧客依到達次序排隊。假設門口和柜臺之間的移動時間不能忽略，并且為顧客開門的優(yōu)先級比較高，就是說如果有新顧客到來，必須先放下正在服務的顧客去開門。在這種情況下，如果顧客的到來間隔是均勻的，為每一位顧客服務要服務員跑兩趟。如果顧客到達的間隔比較小，就出現服務員在門口和柜臺之間頻繁移動的情況。假如能使顧客分撥到達，每次有多個顧客到達，服務員就可以從柜臺到門口開門讓多個顧客進入，再回柜臺為顧客服務。試驗證明，在這種模型下接收效率能大幅提高，但是對均勻到達的顧客服務效率的提高難以得到解決。
4 深入網絡設備驅動
經過對操作系統(tǒng)更為深入的研究發(fā)現，MUX層的發(fā)送數據包最終是通過調用網絡設備驅動程序中的發(fā)送函數實現的。分析網絡設備驅動的代碼發(fā)現，其發(fā)送過程可描述為：
◇檢查設備緩沖區(qū)(BD表)是否有可用BD；
◇根據設備緩沖區(qū)的可用情況與發(fā)送數據包的長度，判斷是否需要進行分片；
◇根據設備緩沖區(qū)的可用情況決定傳輸發(fā)送還是拷貝發(fā)送；
◇置位設備控制寄存器，啟動DMA傳輸，并引發(fā)設備收發(fā)中斷；
◇清除使用過的設備緩沖區(qū)。
另據分析，在設備驅動的安裝過程中完成的工作有：
◇根據配置數據申請內存，構建設備緩沖區(qū)表；
◇指定DMA使用的通道與工作方式；
◇配置設備寄存器(工作方式、幀類型、設備緩沖區(qū)表指針等)；
◇連接設備中斷處理例程。
接收過程中，是在網絡設備收到數據包后啟動DMA傳輸至內存，并引發(fā)中斷，在中斷處理程序中處理緩沖區(qū)指針，然后將一個函數處理指針寫入一個環(huán)型緩沖區(qū)，最后是釋放一個信號量，通知網絡任務對收到的數據包進行處理。通過對該接收處理函數的反匯編解讀，發(fā)現它的主要工作是申請MUX層的緩沖區(qū)并復制，處理設備緩沖區(qū)的指針，然后調用各個協議的處理函數。
根據以上的認識，有了一個更為大膽的設想：跳過MUX層，直接使用driver的發(fā)函數進行發(fā)送；在接收過程中，對本協議棧的數據包不再申請MUX層的緩沖區(qū)，而是直接拷貝到應用層緩沖區(qū)，并可將處理接口留給用戶。另外一個想法是，直接在中斷處理例程中進行處理，從而徹底拋棄網絡任務。據此在百兆網絡設備上完成了修改，其效率又提高將近l倍，滿足了使用的要求；而且更為可喜的是，系統(tǒng)的穩(wěn)定性大幅提高。
5 結論與數據分析
幾種情況下的測試結果如下：
通過對上述數據的分析看出，使用MUX層的協議棧組發(fā)環(huán)境下，比使用標準協議棧發(fā)送的效率提高3倍左右，但是在均勻收發(fā)的情況下提高并不明顯。直接使用中斷方式克服了這一缺陷，比均勻收發(fā)的環(huán)境下又提高1倍。
但是這個測試結果只是在短包的情況下完成的，包長在100字節(jié)以下。通過對長包的測試，發(fā)現對512字節(jié)以上的長包的影響要稍微小一些。這是因為在同一速率下，使用長包調用的次數要少，改進的效果也就稍差，特別是在CPU主頻更高的環(huán)境下，這一現象更為明顯。
6 對實時操作系統(tǒng)的一點看法
通過對設備驅動的研究發(fā)現．在實時操作系統(tǒng)中，中斷處理例程的處理時間都比較短，這也是實現實時性的一個重要思想。在改進中，中斷處理例程中加入了執(zhí)行代碼，會影響系統(tǒng)的實時性，似乎違背了實時操作系統(tǒng)的初衷。但筆者認為，這個問題要在實際的環(huán)境下進行評價，中斷中的通知網絡任務與網絡任務的執(zhí)行，兩者加起來的時間一定要比只在中斷中處理需要的時間要長。這與IP包處理機的目標也是沒有矛盾的，完全不必拘泥陳規(guī)。實時系統(tǒng)只是追求平均的響應時間較短，而在最差情況下則遠低于平均水平。
下載文檔
