[Gluster-devel] What tranpsort type in glfs_set_volfile_server() exactly mean ?

[Raghavendra G]

On Mon, Jul 18, 2016 at 4:35 PM, Raghavendra Talur <rtalur at redhat.com>
wrote:

>
>
> On Mon, Jul 18, 2016 at 4:10 PM, Prasanna Kalever <pkalever at redhat.com>
> wrote:
>
>> Hey Team,
>>
>>
>> My understanding is that @transport argumet in
>> glfs_set_volfile_server() is meant for specifying transport used in
>> fetching volfile server,
>>
>
> Yes, @transport arg here is transport to use for fetching volfile.
>
>
>> IIRC which currently supports tcp and unix only...
>>
> Yes, this is correct too.
>
>
>>
>> The doc here
>> https://github.com/gluster/glusterfs/blob/master/api/src/glfs.h
>> +166 shows the rdma as well, which is something I cannot digest.
>>
> This is doc written with assumption that rdma would work too.
>
>
>>
>>
>> Can someone correct me ?
>>
>> Have we ever supported volfile fetch over rdma ?
>>
>
> I think no. To test, you would have to set rdma as only transport option
> in glusterd.vol and see what happens in volfile fetch.
>
>
> IMO, fetching volfile over rdma is an overkill and would not be required.
> RDMA should be kept only for IO operations.
>

+1. Actually there is no point in having infiniband to fetch volfile as
* RDMA/infiniband is useful for large data transfer
* Even when using RDMA/infiniband, we use a tcp/ip socket for initial
handshake (specifically an IPoIB stack) - RDMA connection manager
(librdmacm). So, a tcp/ip based address or pathway is necessary even while
using RDMA.

So, its a overkill to use RDMA for fetching volfiles.


>
> We should just remove it from the docs.
>
> Thanks,
> Raghavendra Talur
>
>
>>
>> Thanks,
>> --
>> Prasanna
>>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160725/2afc8ae2/attachment.html>