Bug 764949 (GLUSTER-3217) - [FEAT] Design the better Receive-buffer management in RDMA transport
Summary: [FEAT] Design the better Receive-buffer management in RDMA transport
Keywords:
Status: CLOSED EOL
Alias: GLUSTER-3217
Product: GlusterFS
Classification: Community
Component: rdma
Version: mainline
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Raghavendra G
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-22 05:00 UTC by Raghavendra G
Modified: 2015-10-22 15:46 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-10-22 15:46:38 UTC
Regression: RTNR
Mount Type: All
Documentation: DNR
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Raghavendra G 2011-07-22 05:00:09 UTC
Rdma pre-allocates a set of buffers and registers them with infiniband to be used to store the incoming data on the wire. Whenever there are no such free buffers on receiver's end, send from the sender will fail. Currently rdma manages this with client and server exchanging the number of recv-buffers they have during handshake. After handshake, with client and server knowing how many buffers the other end have and with the fact the each send would consume a buffer on receiver end (which, the receiver puts back to infiniband once it is done with processing the contents), can implement a quota based mechanism so that we would not run into send failures. However, as of now the queue of receive buffers is stored per-device but not per-transport. Hence the no of buffers advertised by the server to each of the client should be (nuber-of-buffers/number-of-clients - assuming equal allocation of buffers, which need not be the case). Instead we are advertising to each client that the server has all the receive buffers exclusively for the client, which is not the case.

However the problem with sharing a global queue of receive buffers with all the clients is that we don't know upfront how many clients will connect to a server. Hence it'll be difficult to find out how many buffers each client should be allocated. An alternative solution would be to maintain a separate queue of receive buffers for each transport.

regards,
Raghavendra.

Comment 1 Amar Tumballi 2012-02-27 10:35:55 UTC
This is the priority for immediate future (before 3.3.0 GA release). Will bump the priority up once we take RDMA related tasks.

Comment 2 Kaleb KEITHLEY 2015-10-22 15:46:38 UTC
because of the large number of bugs filed against mainline version\ is ambiguous and about to be removed as a choice.

If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.


Note You need to log in before you can comment on or make changes to this bug.