ACM has two ways that it can complete address resolution. The
first is to receive a response to an address resolution query.
The second is to receive a multicast message carrying an address
resolution request. In the second case, the address request
may be between two other nodes.
When this occurs, ACM will record the address information of
the source of the multicast message. However, it's possible
for ACM to be in the process of trying to resolve that address.
After it records the address, it must see if there's an
outstanding request against that address, so that it can kick
off route resolution.
This fixes an issue where ACM will hang resolving addresses
found during scale-up testing.
Signed-off-by: Sean Hefty <sean.he...@intel.com>
---
src/acm.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/acm.c b/src/acm.c
index 404d2b5..77194ff 100644
--- a/src/acm.c
+++ b/src/acm.c
@@ -1027,7 +1027,7 @@ acm_process_addr_req(struct acm_ep *ep, struct ibv_wc
*wc, struct acm_mad *mad)
status = acm_record_acm_route(ep, dest);
break;
}
- if (addr_index >= 0) {
+ if (addr_index >= 0 || !DListEmpty(&dest->req_queue)) {
status = acm_resolve_path(ep, dest,
acm_resolve_sa_resp);
if (status)
break;
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
