On 6/16/22 5:07 PM, Stefan Metzmacher wrote:
Hi Bernard,
Hi Stefan, much appreciated! I think the erdma driver
did a good job implementing something similar, but w/o
the need to look into MPA v2 specifics, especially the
extra handshake in RDMA mode.
As far as I see they introduce a dedicated
ERDMA_CM_WORK_CONNECTTIMEOUT and the timeouts
are:
> +#define MPAREQ_TIMEOUT (HZ * 20)
> +#define MPAREP_TIMEOUT (HZ * 10)
> +#define CONNECT_TIMEOUT (HZ * 10)
If I read the code correct that would be 10 + 20 seconds
before a RDMA_CM_EVENT_ESTABLISHED must be posted.
You are right.
I'm using just one timer (#define MPAREQ_TIMEOUT (HZ * 10)) that spans
the tcp connect
as well as the MPA handshare.
I don't think we should care in what portion the time was spend
between tcp and mpa, what matters for the caller is the overall timeout
to get a valid connection. So I think a single timeout is better.
Indeed one timer is enough and works fine. But in erdma, our consider
is:
TCP connection establishment and iWarp MPA negotiation are two stages.
tcp connect timeout often means the server is offline. And how long the
MPA negotiation takes is influenced by the server's load (client will
wait longer if many clients connect to it due to more RDMA resources
need being allocated).
We want to distinguish these two situations. A shorter TCP expired time
and a longer MPA expired time allow clients can try to connect another
server fast if the current server is unreachable, and also have
enough time to wait the MPA negotiation finished. This solves some
issues in our internal scenarios.
Thanks,
Cheng Xu