Version: 1
-Previous: 590dcd2580933003e4fb7816ba23343bfcedf385
-Head: 59cddb8c2cd143ffe205716eef276b9c502e1eb5
+Previous: f6ea75d1fe6bed58f49784f07cca5bf655ed6cf6
+Head: 8ba3be5f12ffff6818c394d0b0589cb713f68841
Applied:
cma-rm-pd: 2ffda7f2991395570b9e776ff5ae256ca9684771
transpose: 3e52eb22f44eafaefa95c4674bc5665a94e15694
init-getname: 7d988863b218d1b66e3739ec4b6f51acc72b2334
rs-ftp: 28e0744eb89227fbeded485fbad64010b9edf0f6
check-id: 59cddb8c2cd143ffe205716eef276b9c502e1eb5
+ fast-disc: 8ba3be5f12ffff6818c394d0b0589cb713f68841
Unapplied:
dbg: 0c269855776d3001e37da8c8afe283c20e1d6cd6
waitall-buggy: c49c6b56c55385774065f5aa2704078e6ae0ceb8
--- /dev/null
+Bottom: b5df9cc04d6e7629ae937bfe9bbc3c7da5193ea0
+Top: b5df9cc04d6e7629ae937bfe9bbc3c7da5193ea0
+Author: Sean Hefty <sean.hefty@intel.com>
+Date: 2012-07-27 10:46:42 -0700
+
+rsocket: Improve disconnect time under normal conditions
+
+When both sides of a connection attempt to close at the same
+time, one of the two sides can easily get an error when sending
+a disconnect message. This results in that side hanging
+during close until the send times out. (The time out is caused
+by the remote side destroying its QP.)
+
+We can reduce the chance of this occurring by immediately
+assuming that the disconnect has been successful once we've
+received the remote side's disconnect message.
+
+Signed-off-by: Sean Hefty <sean.hefty@intel.com>
+
+
+---
+
+