summaryrefslogtreecommitdiffstats
path: root/net/sunrpc/svcsock.c
diff options
context:
space:
mode:
authorTom Tucker <tom@opengridcomputing.com>2008-10-09 15:00:30 -0400
committerTrond Myklebust <Trond.Myklebust@netapp.com>2008-10-10 15:09:56 -0400
commitb334eaabf4f92226d2df13c613888a507f03da99 (patch)
treeda3ce699ec10898dd41483e52c6e99805be6f363 /net/sunrpc/svcsock.c
parent3197d309f5fb042499b2c4c8f2fcb67372df5201 (diff)
downloadop-kernel-dev-b334eaabf4f92226d2df13c613888a507f03da99.zip
op-kernel-dev-b334eaabf4f92226d2df13c613888a507f03da99.tar.gz
RPC/RDMA: fix connection IRD/ORD setting
This logic sets the connection parameter that configures the local device and informs the remote peer how many concurrent incoming RDMA_READ requests are supported. The original logic didn't really do what was intended for two reasons: - The max number supported by the device is typically smaller than any one factor in the calculation used, and - The field in the connection parameter structure where the value is stored is a u8 and always overflows for the default settings. So what really happens is the value requested for responder resources is the left over 8 bits from the "desired value". If the desired value happened to be a multiple of 256, the result was zero and it wouldn't connect at all. Given the above and the fact that max_requests is almost always larger than the max responder resources supported by the adapter, this patch simplifies this logic and simply requests the max supported by the device, subject to a reasonable limit. This bug was found by Jim Schutt at Sandia. Signed-off-by: Tom Tucker <tom@opengridcomputing.com> Acked-by: Tom Talpey <talpey@netapp.com> Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Diffstat (limited to 'net/sunrpc/svcsock.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud