如果说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的自动恢复机制。
