-----"Steve Wise" <swise@xxxxxxxxxxxxxxxxxxxxx> wrote: ----- >To: "'Bernard Metzler'" <bmt@xxxxxxxxxxxxxx>, ><linux-rdma@xxxxxxxxxxxxxxx> >From: "Steve Wise" <swise@xxxxxxxxxxxxxxxxxxxxx> >Date: 01/30/2018 10:27PM >Subject: RE: [PATCH v3 06/13] SoftiWarp connection management > >> >> Signed-off-by: Bernard Metzler <bmt@xxxxxxxxxxxxxx> >> --- >> drivers/infiniband/sw/siw/siw_cm.c | 2184 >> ++++++++++++++++++++++++++++++++++++ >> drivers/infiniband/sw/siw/siw_cm.h | 156 +++ >> 2 files changed, 2340 insertions(+) >> create mode 100644 drivers/infiniband/sw/siw/siw_cm.c >> create mode 100644 drivers/infiniband/sw/siw/siw_cm.h > ><snip> > >> diff --git a/drivers/infiniband/sw/siw/siw_cm.h <snip> >> + >> +/* >> + * Connection initiator waits 10 seconds to receive an >> + * MPA reply after sending out MPA request. Reponder waits for >> + * 5 seconds for MPA request to arrive if new TCP connection >> + * was set up. >> + */ >> +#define MPAREQ_TIMEOUT (HZ*10) >> +#define MPAREP_TIMEOUT (HZ*5) >> + > >These timeout times seem pretty low for a WAN link or even a brief >network >down event during MPA negotiation connection. Any particular reason >for 10 >and 5? > > > i picked those rather small numbers since it covers basically only the latency after the TCP connection went up, so the timer gets started only after the TCP connection was established. at client side, we wait 5 seconds after sending the MPA request to get the reply. on server side, we wait 10 seconds for the MPA request, after we have accepted a new TCP connection. maybe i shall make that longer? but the only real delay we have to deal with is the server side application which thinks too long if it shall 'accept' or 'reject' (maybe that is very artifical, but i had to deal with cases of an application which never rejected/ accepted). thanks Bernard. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
