summaryrefslogtreecommitdiff
path: root/REPORTING-BUGS
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2015-10-25 00:26:45 +0300
committerAnna Schumaker <Anna.Schumaker@Netapp.com>2015-11-02 21:45:15 +0300
commit4220a07264c0517006a534aed201e29c8d297306 (patch)
tree08e527549cda9af62cabb81412623bed7f7c8a3f /REPORTING-BUGS
parent7b3d770c67bc07db5035999e4f864c5f2ff7b10e (diff)
downloadlinux-4220a07264c0517006a534aed201e29c8d297306.tar.xz
xprtrdma: Prevent loss of completion signals
Commit 8301a2c047cc ("xprtrdma: Limit work done by completion handler") was supposed to prevent xprtrdma's upcall handlers from starving other softIRQ work by letting them return to the provider before all CQEs have been polled. The logic assumes the provider will call the upcall handler again immediately if the CQ is re-armed while there are still queued CQEs. This assumption is invalid. The IBTA spec says that after a CQ is armed, the hardware must interrupt only when a new CQE is inserted. xprtrdma can't rely on the provider calling again, even though some providers do. Therefore, leaving CQEs on queue makes sense only when there is another mechanism that ensures all remaining CQEs are consumed in a timely fashion. xprtrdma does not have such a mechanism. If a CQE remains queued, the transport can wait forever to send the next RPC. Finally, move the wcs array back onto the stack to ensure that the poll array is always local to the CPU where the completion upcall is running. Fixes: 8301a2c047cc ("xprtrdma: Limit work done by completion ...") Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-by: Sagi Grimberg <sagig@mellanox.com> Reviewed-by: Devesh Sharma <devesh.sharma@avagotech.com> Tested-By: Devesh Sharma <devesh.sharma@avagotech.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Diffstat (limited to 'REPORTING-BUGS')
0 files changed, 0 insertions, 0 deletions