且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

NTB EEPROM设置与跨节点数据传输

更新时间:2022-09-28 21:56:58

NTB EEPROM设置与跨节点数据传输


双控双活系统中除了需要监测系统状态的心跳之外,还需要能够跨节点传输数据的通道。PCIE非透明桥(NTB)由于其基于标准的PCIE规范,软件依赖少,速度快,配置简便,受到许多人的青睐。基于PCIE NTB进行跨节点数据传输的原理很简单,如下图所示意:

NTB EEPROM设置与跨节点数据传输


较之于普通的PCIE/PCI设备的配置空间寄存器,NTB上多了bar2/3,bar4/bar5的地址转换寄存器,本地节点发送过来的命中bar2/bar3或者bar4/bar5的TLP的地址高位会转换成相应的地址转换寄存器里的值,然后转发到对方节点。



在本人最近的一次NTB调试过程中,发现数据能从link port端写到virtual port一侧指定的内存地址中去,并且virtual port这侧能从指定的地址读回link port端写回的数据;但是类似的程序交换在virtual port端和link port端上执行时,发现virtual port端能把数据写到link port端,并且从link port端读回的数据和之前写的数据一致,但是link port端却无法从指定的地址读回期望的数据。


为了分析这一问题,笔者首先用GDB跟踪了代码,没有发现程序逻辑上的问题;然后把两端的程序统一到一个文件中,用不同的输入参数控制是做远程读写还是本地读写,重新测试,还是能够看到同样的现象。正在百思不得其解的时候,突然想起了地址转换的原理,脑海里浮现出地址转换的过程:

首先,判断NT接受到的TLP的地址是否命中它对应的Bar,在我所使用的实际例子当中,实际用到了Bar3/Bar2组成的一个64 bit的基地址。检查之后,确定CPU是往这一地址访问数据;

接着,检查地址转换寄存器里的值是否是期望的值。正确的值应该是跨节点要访问的内存在所在它所在节点的总线地址,在intel x86的体系结构当中,这个总线地址就是内存的物理地址。检查这个寄存器的值也没问题,如下它的值是:0x0d6d80007800003

[root@localhost bin]#  lspci -xxxxx -s 06:00.0 | grep "c30"

c30: 00 00 00 00 0b 00 01 b7 03 00 80 07 00 00 80 6d

[root@localhost bin]#  lspci -xxxxx -s 06:00.0 | grep "c40"

c40:0d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


既然基地址寄存器和地址转换寄存器都没有问题,那问题到底在哪里呢?Request ID的值也设置过,也没有问题。到底问题出在哪呢?


正在百思不得其解的时候,想起来了地址转换寄存器的高位的位段长短也是由setup寄存器设置的,setup寄存器最高为直到从高到低位出现的第一个不为1的bit作为mask,后面的bit全为0,与地址转换寄存器中的值进行与就得到转换后的地址高位。


根据上面的转换方式,发现在virtual port这一侧,Bar3/Bar2的setup寄存器是0xfffffffe00000000,因此转换后的地址是:

0xfffffffe00000000 & 0x0d6d80007800003 = 0x0d6d800000000000。实际我使用的地址窗口只有2M,因此期望转换后地址的高位应是:0x0d6d80007800000。这就难怪为什么总感觉数据能写道对方节点去,但在对方期望的地址总是读不会指望的数据。因此setup的寄存器必须改成:0xffffffffffe000000。按照上面的设置,利用下面命令重新设置下寄存器的值: 

[root@localhost bin]# setpci -s 06:00.0 d8.l=0xffffffff

接着进行测试,完全通过。继续分析为何setup寄存器出现问题,原来它的值是由NTB EEPROM初始化的,在我维护的EEPROM固件的一个中间颁布中出现问题导致f变成了e。


这次给我的教训就是一定要深刻理解NTB数据传输的原理,只有对它进行地址转换的过程和相关寄存器了然于胸,才能刨根到底。
















本文转自存储之厨51CTO博客,原文链接:http://blog.51cto.com/xiamachao/1750055 ,如需转载请自行联系原作者