找到了解释如下：
Multi-rail support (multiple ports per adapter and multiple adapters)
看起来有点类似多网卡绑定或是单Infiniband网卡上的多Port绑定。但其实不是这样的，当然，多网卡绑定或者是多端口绑定会提升一部分 的带宽，但是这里的multi-rail不是这么单纯。其实multi-rail这个词本身不局限于Infiniband，以太网，Myrinet都可以 作 Multi-rail。
Multi-rail指的就是同时用多个网卡或是单块网卡上的多个port来同时通讯。目的有两个：第一，提高带宽，跨越带宽瓶颈。第二，增强Fault-tolerance。自然，在HPC上，我们更关注前一点。
在HPC领域，很多时候的通讯是双向的，在单网卡的情况下，一块网卡同时负担接受和发送，效率比较低。但是如果有两块网卡，一块发，一块收，效率就会提高不少，尤其是对双向通讯很频繁的一些HPC应用而言，这就是最典型的一种Multi-rail的应用。
OK，所以，Multi-rail更多讨论，针对的是一种策略，硬件好实现，无非就是多一块网卡或者多一个端口。但是策略上有很多，所谓策略就是 当我们现在需要发送一个message的时候，用哪块网卡，端口（网卡，端口统称为rail）去发？传统的程序是将接受该消息的进程ID除以系统的 rail 数，取得余数，就是发送该message的rail，显然这种做法很有问题，有可能导致有些rail通讯很多，有些rail却没事可作。
于是，现在就有static（基于Round-Robin），local dynamic，dynamic，Hybrid等多种策略来很好的实现Multi-rail，详情请看附件中的PDF，来自拉莫斯实验室，非常不错，里面 有原理介绍，策略介绍和实际测试数据。最后一页的Conclusion指出，static策略最差，但是最好实现；使用Dynamic的策略，通讯带宽和 效率都最佳，特别是对大数据量的message而言，如果对于频繁发送小数据量的应用而言，可以在Dynamic策略的基础上辅以Hybird的策略，就 最棒了！！
反过来再来看MVAPICH提供的带multi-rail support的makefile，和普通的比较，就是在configure的时候多了两个configure定义，应该就是定义在多 Infiniband网卡或多Port上做数据copy的时候，可以效率更高吧。
现在唯一不确定的就是，Multi-rail的硬件很好做，关键是那些策略的实现，因为这些策略的实现对应用是透明的，是实现在地层的。那么，这 些策略的实现是硬件上实现的（比如现在很多Infiniband的switcher都支持Multi-rail），还是软件实现的（比如MVAPICH就 是专门的for multi-rail的版本）。我的基本猜测是双方共同实现的，硬件上应该有一个基础的实现，再辅以软件的优化，比如MVAPICH，就是专门针对MPI （也就是HPC领域）所优化的。
Multi-rail support (multiple ports per adapter and multiple adapters)
看起来有点类似多网卡绑定或是单Infiniband网卡上的多Port绑定。但其实不是这样的，当然，多网卡绑定或者是多端口绑定会提升一部分 的带宽，但是这里的multi-rail不是这么单纯。其实multi-rail这个词本身不局限于Infiniband，以太网，Myrinet都可以 作 Multi-rail。
Multi-rail指的就是同时用多个网卡或是单块网卡上的多个port来同时通讯。目的有两个：第一，提高带宽，跨越带宽瓶颈。第二，增强Fault-tolerance。自然，在HPC上，我们更关注前一点。
在HPC领域，很多时候的通讯是双向的，在单网卡的情况下，一块网卡同时负担接受和发送，效率比较低。但是如果有两块网卡，一块发，一块收，效率就会提高不少，尤其是对双向通讯很频繁的一些HPC应用而言，这就是最典型的一种Multi-rail的应用。
OK，所以，Multi-rail更多讨论，针对的是一种策略，硬件好实现，无非就是多一块网卡或者多一个端口。但是策略上有很多，所谓策略就是 当我们现在需要发送一个message的时候，用哪块网卡，端口（网卡，端口统称为rail）去发？传统的程序是将接受该消息的进程ID除以系统的 rail 数，取得余数，就是发送该message的rail，显然这种做法很有问题，有可能导致有些rail通讯很多，有些rail却没事可作。
于是，现在就有static（基于Round-Robin），local dynamic，dynamic，Hybrid等多种策略来很好的实现Multi-rail，详情请看附件中的PDF，来自拉莫斯实验室，非常不错，里面 有原理介绍，策略介绍和实际测试数据。最后一页的Conclusion指出，static策略最差，但是最好实现；使用Dynamic的策略，通讯带宽和 效率都最佳，特别是对大数据量的message而言，如果对于频繁发送小数据量的应用而言，可以在Dynamic策略的基础上辅以Hybird的策略，就 最棒了！！
反过来再来看MVAPICH提供的带multi-rail support的makefile，和普通的比较，就是在configure的时候多了两个configure定义，应该就是定义在多 Infiniband网卡或多Port上做数据copy的时候，可以效率更高吧。
现在唯一不确定的就是，Multi-rail的硬件很好做，关键是那些策略的实现，因为这些策略的实现对应用是透明的，是实现在地层的。那么，这 些策略的实现是硬件上实现的（比如现在很多Infiniband的switcher都支持Multi-rail），还是软件实现的（比如MVAPICH就 是专门的for multi-rail的版本）。我的基本猜测是双方共同实现的，硬件上应该有一个基础的实现，再辅以软件的优化，比如MVAPICH，就是专门针对MPI （也就是HPC领域）所优化的。
现在想了一下，Multi-rail应该还是主要依靠硬件实现的，原因有这么一些：
1. 因为只有依靠硬件，那些策略实现的overhead才会比较小，如果依靠软件实现，每个message收发的时候都要去决策一下，这个overhead就大了
2. 在google上search，mpich multi-rail，搜索出来的几乎全是infiniband，myrinet，qsnet这些互联网络的方案。而且确实没听说过MPICH有过一个multi rail版本
3. 看了MVAPICH的带multi-rail support的makefile，就是configure的时候多了两个定义，而这两个定义看不出是用来实现multi-rail策略的，更象是为了让 程序在multi-rail support的硬件上运行而做的一些准备。
1. 因为只有依靠硬件，那些策略实现的overhead才会比较小，如果依靠软件实现，每个message收发的时候都要去决策一下，这个overhead就大了
2. 在google上search，mpich multi-rail，搜索出来的几乎全是infiniband，myrinet，qsnet这些互联网络的方案。而且确实没听说过MPICH有过一个multi rail版本
3. 看了MVAPICH的带multi-rail support的makefile，就是configure的时候多了两个定义，而这两个定义看不出是用来实现multi-rail策略的，更象是为了让 程序在multi-rail support的硬件上运行而做的一些准备。