Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > The CM timeout/retry options are used by uDAPL, but the fix to increase the > default retry count to the maximum may help. The RDMA CM uses the data from > the > path record, but the ULP has the most data about how long the remote side > might > take to respond to a CM REQ message (remote_cm_response_timeout). We might be > able to have the RDMA CM make clever use of the MRA to avoid the issue, and > even > in the short term, dumb use of the MRA may help. (The issue is that as > connections are formed, they begin being used, which can greatly affect how > quickly new connections can be created. We've seen them take up to 60 > seconds.)
Connections taking 60 sec to create is an issue. Can you please explain how the fact that some connections are used affect the time it takes to send the response? Why would sending MRA be faster than sending the response? > >> * IB multicast module > > > >Last time I tested this, there still were crashes with the IPoIB. > >If there's a patch that adds just this change, I might be able to test it. > >OTOH, I'm still not sure why are we touching IPoIB at all since > >it seems unlikely any other ULP will want to share in the IPoIB mcast group. > > Personally, I think ipoib should use it to reduce code duplication. I did not notice any significant reduction in ipoib LOC, but maybe I'm mistaken. Let's see the updated patch. -- MST -- MST _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
