
<html>

<body>

<font size=3>At 01:24 PM 11/9/2005, Greg Lindahl wrote:<br>

<blockquote type=cite class=cite cite="">On Wed, Nov 09, 2005 at

12:18:28PM -0800, Michael Krause wrote:<br><br>

> So, things like HCA failure are not transparent and one cannot

simply <br>

> replay the operations since you don't know what was really seen by

the <br>

> other side unless the application performs the resync

itself.<br><br>

I think you are over-stating the case. On the remote end, the kernel<br>

piece of RDS knows what it presented to the remote application,

ditto<br>

on the local end. If only an HCA fails, and not the sending and<br>

receiving kernels or applications, that knowledge is not lost.<br><br>

Perhaps you were assuming that RDS would be implemented only in<br>

firmware on the HCA, and there is no kernel piece that knows what's<br>

going on. I hadn't seen that stated by anyone, and of course there

are<br>

several existing and contemplated OpenIB devices that are

considerably<br>

different from the usual offload engine. You could also choose to<br>

implement RDS using an offload engine and still keep enough state in<br>

the kernel to recover.</blockquote><br>

I hadn't assumed anything.  I'm simply trying to understand the

assertions concerning availability and recovery.  What you indicate

above is that RDS will implement a resync of the two sides of the

association to determine what has been successfully sent.  It will

then retransmit what has not transparent to the application.  This

then implies that the reliability of the underlying interconnect isn't as

critical per se as the end-to-end RDS protocol will assure that data is

delivered to the RDS components in the face of hardware

failures.   Correct?<br><br>

Mike</font></body>

</html>