andy/glusterfs
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

doc: Avoid duplicate rdma notes.

Browse Source 
Change-Id: I5ede0ffad3870d8d86cb5d551ce188c649b04b44
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>
Reviewed-on: http://review.gluster.org/8826
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
This commit is contained in:
Humble Chirammal 2014-09-23 23:05:16 +05:30 committed by Vijay Bellur
parent 7f7dabd7d0
commit 6c5b74c66c
2 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
doc/features/rdma-cm-in-3.4.0.txt
View File

@ -1,9 +0,0 @@
Following is the impact of http://review.gluster.org/#change,149.
New userspace packages needed:
librdmacm
librdmacm-devel
rdmacm needs an IPoIB address for connection establishment. This requirement results in following issues:
* Because of bug #890502, we've to probe the peer on an IPoIB address. This imposes a restriction that all volumes created in the future have to communicate over IPoIB address (irrespective of whether they use gluster's tcp or rdma transport).
* Currently client has an independence to choose b/w tcp and rdma transports while communicating with the server (by creating volumes with transport-type tcp,rdma). This independence was a byproduct of our ability use the normal channel used with transport-type tcp for rdma connectiion establishment handshake too. However, with new requirement of IPoIB address for connection establishment, we loose this independence (till we bring in multi-network support - where a brick can be identified by a set of ip-addresses and we can choose different pairs of ip-addresses for communication based on our requirements - in glusterd).

9
doc/features/rdmacm.md
View File

@ -8,7 +8,16 @@ Infiniband requires addresses of end points to be exchanged using an out-of-band
* [rdma cm kernel module](http://pkg-ofed.alioth.debian.org/howto/infiniband-howto-4.html#ss4.4)
* [user space rdmacm library - librdmacm](https://www.openfabrics.org/downloads/rdmacm)
### rdma-cm in >= GlusterFs 3.4 ###
Following is the impact of http://review.gluster.org/#change,149.
New userspace packages needed:
librdmacm
librdmacm-devel
### Limitations ###
* Because of bug [890502](https://bugzilla.redhat.com/show_bug.cgi?id=890502), we've to probe the peer on an IPoIB address. This imposes a restriction that all volumes created in the future have to communicate over IPoIB address (irrespective of whether they use gluster's tcp or rdma transport).
* Currently client has independence to choose b/w tcp and rdma transports while communicating with the server (by creating volumes with **transport-type tcp,rdma**). This independence was a by-product of our ability to use the tcp/ip channel - transports with *option transport-type tcp* - for rdma connection establishment handshake too. However, with new requirement of IPoIB address for connection establishment, we loose this independence (till we bring in [multi-network support](https://bugzilla.redhat.com/show_bug.cgi?id=765437) - where a brick can be identified by a set of ip-addresses and we can choose different pairs of ip-addresses for communication based on our requirements - in glusterd).