多功能PCIE交換機之五: 基于NTB的DMA

    如果說PCIE多功能橋中的NTB為跨節點的資料傳輸鋪好路、架好橋的話，那麼PCIE多功能橋中的DMA就是多個節點之間的高鐵和航班。沒有NTB打通資料通道，DMA也不可能跨越節點。但沒有DMA的話，NTB還是可以依賴CPU來在多個節點之間搬運資料。是以DMA對NTB而言是如虎添翼、錦上添花。

    和NTB的單NT和雙NTB配置相比，DMA可配置的選項比較多，但不管是中斷模式、查詢模式，也無論描述符是在DMA控制器片上還是片外，亦或配置成單個還是多個DMA channel，都有現成的代碼可供參考或寄存器可以直接設定。那麼多功能PCIE橋中基于NTB的DMA有哪些方面需要額外關注的呢？

１、資料一緻性

    當CPU或者DMA往本地記憶體（包括裝置記憶體）讀寫資料的時候，可以使用的memory cache屬性有write back,write combining, write through和uncache，具體要使用哪一種需要根據具體記憶體的屬性和平台架構來選擇。比如在ARM和龍芯2F/2HSOC上，由于硬體不支援自動維護cache一緻性，是以用作ＤＭＡ的源或者目的位址的那片記憶體區域的cache屬性，需要設定成uncache；而在Intel的架構中，由于硬體能夠自動維護cache一緻性，是以無論設定成哪一種cache屬性理論上都可以，但考慮到對性能的最小影響，可以設定成cache模式。但是涉及到基于NTB的跨節點的ＤＭＡ資料傳輸，由于其資料鍊路既要穿越本地節點的link port/virtual port，又要穿過對側節點的virtual port/link port，而且目前節點所看到的對方節點映射過來的記憶體可能被修改過，是以一定不能用cache模式。而且對于資料完整性要求苛刻的場景下，為了盡可能減少突然掉電對資料寫的影響，write combining也不值得推薦，因為write combining會暫存部分可以合并的寫請求直到超過硬體buffer的限制才一起寫到記憶體，在此期間的突然掉電将會導緻資料丢失。

２、對post write的額外處理

    利用NTB打通兩個節點間的通道之後，不管是通過CPU還是DMA的跨節點的讀寫都是PCIE事務。特别的如果PCIE事務是post write transaction,　沒等資料傳到對方節點的實體記憶體，post write事務就直接傳回了，requester此後就認為此次事務傳輸結束，顯然如果後續對方節點到那塊記憶體上去讀資料，很可能無法得到最新的資料。是以，需要對post write事務進行額外的處理，以確定資料确實跨越NTB達到了實體記憶體。PCIE規範裡對這點已經有額外的說明和建議。感興趣的讀者，可以仔細閱讀PCIE規範1.0中第2.2.5章節和其他章節中關于PCIE事務order的要求。

３、對DMA描述符的清空

    DMA控制器本身不簡單，但暴露給使用者的接口卻相當簡單。一般說來，按照手冊要求的格式構造好描述符、初始化好相應寄存器，然後往控制寄存器中的特殊位(比如DMA的控制器寄存器中的start bit)置１即可啟動DMA傳輸，接着等待狀态寄存器中的類似done bit被置位，就可認為所有的描述符都處理完。但是雖然DMA控制器處理完了所有的DMA描述符，所有的DMA操作就都完全完成了麼？如何保證之前的所有DMA操作都完成，需要參考相應DMA子產品的晶片手冊、程式設計指南。有的手冊會給出flush之前DMA描述符的方法。

４、DMA的恢複

在NTB/DMA實際使用的過程中，可能由于virtual port重新開機、系統掉電，或者DMA的描述符

錯誤等異常情況導緻NTB/DMA無法再正常使用，比如下面的這些情況：

a.  virtual port所在節點和link port節點都掉電之後系統又重新啟動，但是link port

早于virtual port被系統枚舉到；

b. virtual port和link port都正常工作時，virtual port突然重新開機 (reboot, reset,　

c. chassis power cycle, chassis power reset等）

d. virtual port和link port一側往mailbox寫資料，但另一側始終無法從對應mailbox

讀到期望的值；

e. DMA傳輸開始後，DMA控制狀态寄存器始終無法收到Normal  Done信号或中斷；

f. 上層軟體接受到異常的資料，認為需要reset NTB/DMA，發出recover指令

是以有必要在在盡可能減少系統當機和對其他子產品的影響的前提下，自動恢複NTB/DMA。

隻要對NTB和PCIE深刻的了解，就不難實作對NTB/DMA的自動恢複機制。

本文轉自存儲之廚51CTO部落格，原文連結：http://blog.51cto.com/xiamachao/1734775 ，如需轉載請自行聯系原作者