On 7/2/07, <b class="gmail_sendername">Michael S. Tsirkin</b> <<a href="mailto:mst@dev.mellanox.co.il">mst@dev.mellanox.co.il</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> > Quoting Or Gerlitz <<a href="mailto:or.gerlitz@gmail.com">or.gerlitz@gmail.com</a>>:</blockquote><div><br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Thanks for the info. Can you please elaborate a little more on the LAP based<br>
> liveness detection mechanism you were thinking about? I might want to deploy<br>> it in another app.<br><br>With UC, if the remote side looses our QP, we get no indication whatsoever.  But<br>we don't want to destroy/recreate connections unless strictly necessary.
</blockquote><div><br>
why do we care if remote side lost our QP? my thinking is that we (TX QP) should care if <br>
the remote side (RX QP) is still there, and this is achieved by RC as you explain below.<br>
<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">So we must send something that will force remote side to respond. One such<br>message is LAP with current primary path used as proposed alternate path.
<br>Remote will respond with APR with AP status 5 if the connection is there, and<br>status 1 if it is not.</blockquote><div><br>
got it. the current app i was referring to uses UD and not UC, so I guess LAP is not possible.<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Actually, looking on IPoIB-CM RC based implementation I don't really<br>> understand its "liveness detection" mechanism... In ipoib_cm_send_req() I see
<br>> that the code sets both the RC QP retries AND rnr retries to 0... doesn't this<br>> mean that a single RNR NAK would cause a TX QP to move to ERROR?<br><br>Yes, this is from spec, BTW.<br>More importantly, a timeout will cause error, and we'll retry connection
<br>on next packet.</blockquote><div><br>
so with the current IPoIB-CM implementation, single RNR NAK and/or single ACK loss <br>
would cause re-connection, wow... this does not sound like very ready much for production...<br>
<br>
My understanding is that <br>
<br>
A) as the IP layer is seen as unreliable, RC buys us nothing <br>
B)  the current code usage of RC <br>
B.1) is ineffecient by nature since it loads the IB fabrics with ACKs and NAKs<br>
B.2) reconnects on each loss/nak - adds more ineffeciency<br>
<br>
we should move to UC<br>
<br>
am i missing something, what does RC buys us that UC does not?<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> can you<br>> clarify how do you use the "R" of "RC" here?
<br><br>The two reasons I used RC is because<br>1. UC does not support SRQ yet.<br>2. It's easier to detect connection is alive.<br></blockquote></div><br>
I wanted to understand the "how" in detail and not high-level (2 above) or env reasons (1 above)<br>
<br>
thanks anyway,<br>
<br>
Or.<br>