glusterfs.git/rpc, branch v3.6.3beta2

rdma: RDMA_OPTION_ID_REUSEADDR undeclared on Ubuntu Precise (LTS)

2015-03-27T11:37:15+00:00

Very old release of Ubuntu LTSwq

Change-Id: Ib6fb4493f1f34ba853bd74c8037da7663639f40e
BUG: 1201484
Signed-off-by: kkeithle 
Reviewed-on: http://review.gluster.org/10014
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos 
Reviewed-by: Raghavendra Bhat

rdma:changing list iteration to safe mode

2015-03-27T11:35:31+00:00

        Bck port of : http://review.gluster.org/9872

Change-Id: I2299378f02a5577a8bf2874664ba79e92c3811b5
BUG: 1202212
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/9872
Reviewed-by: Krishnan Parthasarathi 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra Talur 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/9891
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Raghavendra Bhat

rdma:setting wrong remote memory.

2015-03-27T11:34:39+00:00

        Back port of : http://review.gluster.org/9794

when we send more than one work request in a single call,
the remote addr is always setting as the first address of
the vector.

Change-Id: I55aea7bd6542abe22916719a139f7c8f73334d26
BUG: 1202212
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/9794
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/9890
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Raghavendra Bhat

rdma: pre-register iobuf_pool with rdma devices.

2015-03-27T11:34:08+00:00

        Back port pf : http://review.gluster.org/9506

registring buffers with rdma device is a time consuming
operation. So performing registration in code path will
decrease the performance.
Using a pre registered memory will give a bettor performance,
ie, register iobuf_pool during rdma initialization. For
dynamically created arena, we can register with all the
device.

Change-Id: Ic79183e2efd014c43faf5911fdb6d5cfbcee64ca
BUG: 1202212
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/9506
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/9889
Reviewed-by: Raghavendra Bhat

rdma:read multiple wr from cq and ack them in one call

2015-03-27T11:33:47+00:00

        Back port of : http://review.gluster.org/9329

we are reading one work completion request at a time
from cq, though we can read multiple work completion
requests from cq. Also we can acknowledge them in
one call itself. Both will give a better performance
because of less mutual exclusion locks are being performed.

Change-Id: Ib5664cab25c87db7f575d482eee4dcd2b5005c04
BUG: 1202212
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/9329
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/9888
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Raghavendra Bhat

rdma: post multiple work request in a single call.

2015-03-27T11:33:28+00:00

        Back port of : http://review.gluster.org/9327

ibv_post-send will allow to send multiple work request
in a single call posting as linked list.

So if the payload count > 1, we can perform the data
operation in a single call to ibv_post_send.

Change-Id: Ib2e485cbbe6887919109e73e17d4fab595d5e65e
BUG: 1202212
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/9327
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/9887
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Raghavendra Bhat

rdma : agregate a vectored read as one

2015-03-27T11:33:11+00:00

        Back port of : http://review.gluster.org/9321

For a vectored read with payload count>1 will make two read
requests and to hold that a single contiguous memory is allocated.
So after completing the read request, instead of sending as vector
we will aggregate all the reads one.

Change-Id: I15e7d7bddc1a62d5097a39392575f47cfff3d3a8
BUG: 1202212
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/9321
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/9886
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Raghavendra Bhat

rdma:vectored write fails for rdma.

2015-01-07T05:41:17+00:00

        Backport of http://review.gluster.org/9247

For rdma write with payload count greater than one
will fail due to insuffient memory to hold the
buffers in rpc transport layer. It was expecting
only one vector in payload, So it can only able
to decode the first iovec from payload, and the
rest will be discarded.

Thnaks to Raghavendra Gowdappa for fixing the
same.

BUG: 1166515
Change-Id: I5e44d240366af78df35df326fe0660ef8497147b
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/9247
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/9392
Reviewed-by: Raghavendra Bhat

rdma:client process will hang if server is started to send the request before completing connection establishment

2015-01-06T09:46:06+00:00

        Backport of http://review.gluster.org/9003

in rdma, client and server will interchange their available
buffers during the handshake to post incoming messages.
Initially the available buffer is set to one, for the first message
during handshake,when first message is received, quota for the
buffer will set to proper value. So before receiving the message
if server started to send the message, then the reserverd buffer for
handshake will be utilised, then the handshake will fail because
of lack of buffers. So we should block sending messages by server
before proper connection establishment.

Change-Id: I1797ae8a25163864c338641d74cd4eef6fb34bb5
BUG: 1166515
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/9003
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/9178
Reviewed-by: Raghavendra Bhat

rdma: client connection establishment takes more time

2015-01-06T09:43:45+00:00

        Backport of http://review.gluster.org/8934

For rdma type only volume client connection establishment
with server takes more than three seconds. Because for
tcp,rdma type volume, will have 2 ports one for tcp and
one for rdma, tcp port is stored with brickname and rdma
port is stored as "brickname.rdma" during pamap_sighin.
During the handshake when trying to get the brick port
for rdma clients, since we are not aware of server
transport type, we will append '.rdma' with brick name.
So for tcp,rdma volume there will be an entry with
'.rdma', but it will fail for rdma type only volume.
So we will try again, this time without appending '.rdma'
using a flag variable need_different_port, and it will succeed,
but the reconnection happens only after 3 seconds.
In this patch for rdma only type volume
we will append '.rdma' during the pmap_signin. So during the
handshake we will get the correct port for first try itself.
Since we don't need to retry , we can remove the
need_different_port flag variable.

Change-Id: I82a8a27f0e65a2e287f321e5e8292d86c6baf5b4
BUG: 1166515
Signed-off-by: Mohammed Rafi KC 
Reviewed-on: http://review.gluster.org/8934
Tested-by: Gluster Build System 
Reviewed-by: Krishnan Parthasarathi 
Reviewed-by: Raghavendra G 
Tested-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/9177
Reviewed-by: Raghavendra Bhat