On 04/25/14 04:59, Hefty, Sean wrote: >> Sean, can't we have CMA to follow the same practice used in the CM where >> we derive the RC QP timeout based on the packet life time retrieved in >> path queries? e.g base the cm response time out on this value too? > > We could. The timeout that's being modified by the patch is the time needed > by the remote peer to process the incoming message and send a response. This > time is in addition to the packet life time value that gets used. > > For a remote kernel agent, the time needed to respond to a CM message may be > fairly small. For a user space client, the time may be significant, on the > order to seconds to minutes. We can probably make due with a fairly short > timeout, provided that MRAs are used by the remote side. > > There's no great solution that I can think of. Maybe the RDMA CM can adjust > the timeout based on the remote address, assuming that it can determine if > the remote address is a user space or kernel agent.
Another possible approach is to make the CM timeout configurable for kernel clients only. How about creating two versions of struct rdma_conn_param - the existing version for communication between user space and kernel and a second version for in-kernel clients only ? In that second version a field could be added that allows to specify the CM timeout. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
