6ae45b34fc
Previously, we were only checking connectivity upon first ''send'' to a peer. But this ignores the case where the first communication to a peer is actually an ACK -- i.e., we successfully received something from the peer and we need to send an ACK back. So we need to verify that the ACK will actually get there. Specifically, certain asymmetric routing cases can lead to a hang if we don't check the connectivity in both directions. E.g., if the sender is able to get traffic to the receiver, but the receiver is unable to get traffic back to the sender because it made a different routing decision than the sender. In this case, the connectivity checker from the sender could succeed (because the connectivity checker will ACK along the same path in which the ping was received), but sending a BTL ACK could fail (because the BTL ACK will be sent back along the path chosen by the graph algorithm, which, in an erroneous asymmetric routing scenario, may be different/wrong). Hence, we want to trigger the connectivity checker at the first communication from A->B, which may either be a BTL send or an ACK. Reviewed by Dave Goodell. cmr=v1.8.2:reviewer=ompi-rm1.8 This commit was SVN r32309. |
||
---|---|---|
.. | ||
allocator | ||
bcol | ||
bml | ||
btl | ||
coll | ||
common | ||
crcp | ||
dpm | ||
fbtl | ||
fcoll | ||
fs | ||
io | ||
mpool | ||
mtl | ||
op | ||
osc | ||
pml | ||
pubsub | ||
rcache | ||
rte | ||
sbgp | ||
sharedfp | ||
topo | ||
vprotocol |