其次，需要解決DMA通道的使用分配。在多線程機制下對DMA通道請求隊列的管理有2種方案，隊列管理方案如圖4所示。

在方案一中，每個虛擬通道的線程把自己的DMA請求(DMA_Req)放入DMA請求隊列(DAM_Queue)中，Oueue Read負(fù)責(zé)從隊列中取出DMA請求。在此使用鎖機制，將隊列寫操作作為臨界區(qū)，在鎖定的臨界區(qū)只允許讓一個線程訪問，其它線程排隊等待。這樣的方案設(shè)計簡單易懂好管理，然而在實際的測試中，由于線程資源及調(diào)度是由操作系統(tǒng)來完成的，測試結(jié)果表明各個通道的DMA_Req并不能公平地寫入隊列，DMA物理通道并不能公平的服務(wù)于每一路虛擬通道，導(dǎo)致了各個通道間傳輸速率不均衡。

在方案二中，各個虛擬通道把自己的DMAReq寫入自己的DMA_Queue中，Queue_Read通過輪詢的方式讀取各個DMA_Queue的DMA 請求，測試結(jié)果表明DMA物理通道資源能被公平的分配且請求處理效率更高。因此傳輸系統(tǒng)的DMA請求隊列管理采用方案二實現(xiàn)。

3.2.3 系統(tǒng)通信模塊

主機與從機兩個處理器系統(tǒng)天然的分離特性，使得性能與正確性產(chǎn)生矛盾，如果兩端的消息通信只是簡單的發(fā)送/接收和處理，不能保證兩端不同時使用同一資源。因此為傳輸系統(tǒng)規(guī)定了一個有順序語義的通信機制如圖5所示。

圖5中黑色箭頭表示的是程序的執(zhí)行順序，白色部分代表了對主機端消息的處理，黑色部分代表了對從機端消息的處理。主從機端皆有一個消息隊列，所有需要發(fā)送的消息(msgQ)都先存入消息隊列中，主機和從機端通過令牌機制來輪流向?qū)Ψ竭f送消息。如果一方消息隊列為空，也需要讓度令牌，使得對方能繼續(xù)遞送消息。以主機機端為例，其消息處理過程如下：(1)等待從機端發(fā)送讓度令牌的消息Ack;(2)收到Ack后接收從機端的發(fā)送的消息Req;(3)對消息進行處理并且準(zhǔn)備要發(fā)送給對方的Ack和從消息隊列中取出msgQ(若消息隊列為空，則填入NULL);(4)向?qū)Ψ桨l(fā)送Ack和msgQ。從機端的消息處理與主機端是一一對應(yīng)的。

系統(tǒng)中使用NT橋的8個32位的MailBox寄存器來實現(xiàn)主從機的消息通信，MailBox寄存器是NT橋的鏈路端口和虛擬端口共有的，都可見可讀可寫。

令牌跳躍式的消息傳遞機制是否會成為整個傳輸系統(tǒng)提升傳輸速率的瓶頸，將在下文的實驗測試中給出結(jié)論。

3.2.4 客戶端通信模塊

使用“Abstract”樣式。為了提供一個簡易通用的客戶端接口，Plx_Server和Client_Register的進程間通信使用Socket實現(xiàn)。傳輸系統(tǒng)的主程序Plx_Server通過創(chuàng)建服務(wù)器(Server Socket)未向連接服務(wù)器的客戶端(Client Register)提供服務(wù)。服務(wù)包括了數(shù)據(jù)收發(fā)請求，連接建立/端開請求等。Plx_Server處理Client_Register連接請求的流程如圖6所示。

在圖6中客戶端的連接注冊、客戶端配對和建立傳輸通道都是由主機端完成的，從機端的連接注冊需要交付給主機端來完成。

3.2.5 客戶端API

調(diào)用客戶端API(Client_Register)完成連接配對請求后，Client_Register將返回一個Socket描述符。用戶只需要參考標(biāo)準(zhǔn)Socket編程規(guī)范，即可使用Socket標(biāo)準(zhǔn)函數(shù)接口，比如read、write、close等進行數(shù)據(jù)通信。

4 系統(tǒng)性能優(yōu)化分析

為滿足視頻轉(zhuǎn)碼設(shè)備對數(shù)據(jù)傳輸性能的要求，傳輸系統(tǒng)除了要滿足傳輸速率、速率均衡的要求外，CPU資源使用率也要作為考慮的因素。在測試中當(dāng)處理器系統(tǒng)的 CPU使用率超過50%后，傳輸系統(tǒng)的總帶寬隨之下降。為此，傳輸系統(tǒng)做了以下優(yōu)化：(1)設(shè)置Plx_Server的CPU相關(guān)性，使進程同時關(guān)聯(lián)多個 CPU;(2)線程在等待或空閑時適當(dāng)掛起以釋放占用的CPU資源。

5 實驗結(jié)果分析

本傳輸系統(tǒng)結(jié)合視頻轉(zhuǎn)碼設(shè)備的使用做了大量的測試，首先測試傳輸系統(tǒng)數(shù)據(jù)傳輸帶寬，測試結(jié)果如圖7所示。實驗結(jié)果表明了系統(tǒng)傳輸性能穩(wěn)定，傳輸總帶寬約為1100MB /s。隨著傳輸通道數(shù)的增加，每一對正在傳輸?shù)耐ǖ缹⒅匦鹿椒峙滟Y源，分配到的資源將減少，使得單路傳輸帶寬將減小，但總帶寬基本保持不變。

另外驗證傳輸系統(tǒng)消息通信機制是否會成為限制傳輸速率的瓶頸。測試數(shù)據(jù)如表2所示。傳輸系統(tǒng)最少每秒可發(fā)送/接收一共1776個消息，完成一次傳輸(每次 DMA傳輸可發(fā)送4MB大小數(shù)據(jù))一共需要發(fā)送/接收5個消息，則經(jīng)換算傳輸系統(tǒng)消息通信帶寬為1776/5x4=2220MB/s，遠遠超過了傳輸系統(tǒng)數(shù)據(jù)傳輸總帶寬，不會成為限制傳輸速率的瓶頸。

在處理器型號為Intel Core i5系列，雙核4線程的主機上運行傳輸系統(tǒng)進程時，進程對主機CPU使用率低于20%，這使得主機在使用從機(視頻轉(zhuǎn)碼設(shè)備)時還有足夠的余力處理其它任務(wù)。

6 結(jié)語

本文基于PEx8619的PCIe接口芯片完成了跨PCIe NT橋的傳輸系統(tǒng)的設(shè)計，實現(xiàn)了雙處理器間的多通道數(shù)據(jù)傳輸功能。經(jīng)試驗測試，傳輸系統(tǒng)總帶寬達到1100MB/s，實時性好，性能優(yōu)越且可移植性強，在需要高速傳輸系統(tǒng)的領(lǐng)域如視頻實時轉(zhuǎn)碼等有很好的應(yīng)用前景。