summaryrefslogtreecommitdiff
path: root/ipc
diff options
context:
space:
mode:
authorSean Hefty <sean.hefty@intel.com>2007-08-01 13:49:53 -0700
committerRoland Dreier <rolandd@cisco.com>2007-10-09 19:59:17 -0700
commitde98b693e9857e183679cd2f49b3c30d2bc57629 (patch)
treebfb31d9109f5057926b8849671e2937df22b37fd /ipc
parent1a1eb6a646f52dc62e3f9ceac4aab9c27e781186 (diff)
downloadlinux-3.10-de98b693e9857e183679cd2f49b3c30d2bc57629.tar.gz
linux-3.10-de98b693e9857e183679cd2f49b3c30d2bc57629.tar.bz2
linux-3.10-de98b693e9857e183679cd2f49b3c30d2bc57629.zip
IB/cm: Modify interface to send MRAs in response to duplicate messages
The IB CM provides a message received acknowledged (MRA) message that can be sent to indicate that a REQ or REP message has been received, but will require more time to process than the timeout specified by those messages. In many cases, the application may not know how long it will take to respond to a CM message, but the majority of the time, it will usually respond before a retry has been sent. Rather than sending an MRA in response to all messages just to handle the case where a longer timeout is needed, it is more efficient to queue the MRA for sending in case a duplicate message is received. This avoids sending an MRA when it is not needed, but limits the number of times that a REQ or REP will be resent. It also provides for a simpler implementation than generating the MRA based on a timer event. (That is, trying to send the MRA after receiving the first REQ or REP if a response has not been generated, so that it is received at the remote side before a duplicate REQ or REP has been received) Signed-off-by: Sean Hefty <sean.hefty@intel.com> Signed-off-by: Roland Dreier <rolandd@cisco.com>
Diffstat (limited to 'ipc')
0 files changed, 0 insertions, 0 deletions