<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.45">
<TITLE>RE: [Openib-windows] RE: Errors handeling on Winsock direct</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>Hi Fab,</FONT>
</P>
<P><FONT SIZE=2>Error handling is probably one of the most complicated areas in programming (or should I say computer science?). I don't want to start an entire discussion about how it should be handled as there are many approaches to this problem, but I do want to give some few guidelines:</FONT></P>
<P><FONT SIZE=2>1) The first thing to understand is that there are two types of operations: the first is a must succeed one, while the other is a "might" succeed. Examples for the first type are (the list is very short):</FONT></P>
<P><FONT SIZE=2>int a;</FONT>
</P>
<P><FONT SIZE=2>a = 5;</FONT>
</P>
<P><FONT SIZE=2>or SpinLock Lock1</FONT>
<BR><FONT SIZE=2>Lock1.lock()</FONT>
</P>
<P><FONT SIZE=2>Examples for the second are almost all other functions. Please note that each function that depends on allocating memory might fail. And there for each function that calls it might also fail and so on. Depending on your hardware model you might have to assume that operations that you do on your hardware might also fail. I believe that this is the case with InfiniBand operations, in which operations might fail due to errors that are in the firmware, the cable or in the HCA.</FONT></P>
<P><FONT SIZE=2>Generally speaking a never fail functions are very hard to design, but writing a program without them is impossible. On the other hand if a function might fail, the failure has to be reported.</FONT></P>
<P><FONT SIZE=2>In general a component like WSD should pass an error that it detects to upper layers. These errors should be propagated to be winsock errors later. Applications have some freedom on what to do, but they too can't ignore errors. </FONT></P>
<P><FONT SIZE=2>In any case, back to our problem - the function ib_poll_cq() is a "might" fail function, and therefore I don't see a way that it callers are not (that is the callers should return some kind of an error). Please note that deciding that it is a must succeed means that all the functions that it uses (and so on recursively) are must succeed. It also means that we have to verify that there are no errors that can be returned from the hardware (for example if we have a problem with a cable). More, we also have to verify that also in future implementations all this functions will remain must succeed.</FONT></P>
<P><FONT SIZE=2>As a consequence to all of this, I believe that the interface (and implementation) of ib_cq_comp() should also change to return some error. Of course, this doesn't have to happen immediately.</FONT></P>
<P><FONT SIZE=2>Thanks</FONT>
<BR><FONT SIZE=2>Tzachi</FONT>
<BR><FONT SIZE=2>>-----Original Message-----</FONT>
<BR><FONT SIZE=2>>From: Fab Tillier [<A HREF="mailto:ftillier@silverstorm.com">mailto:ftillier@silverstorm.com</A>]</FONT>
<BR><FONT SIZE=2>>Sent: Friday, October 28, 2005 2:07 AM</FONT>
<BR><FONT SIZE=2>>To: 'Dror Goldenberg'; Tzachi Dar; openib-windows@openib.org</FONT>
<BR><FONT SIZE=2>>Subject: RE: [Openib-windows] RE: Errors handeling on Winsock direct</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>> From: Dror Goldenberg [<A HREF="mailto:gdror@mellanox.co.il">mailto:gdror@mellanox.co.il</A>]</FONT>
<BR><FONT SIZE=2>>> Sent: Thursday, October 27, 2005 3:50 PM</FONT>
<BR><FONT SIZE=2>>></FONT>
<BR><FONT SIZE=2>>> > From: Fab Tillier [<A HREF="mailto:ftillier@silverstorm.com">mailto:ftillier@silverstorm.com</A>]</FONT>
<BR><FONT SIZE=2>>> ></FONT>
<BR><FONT SIZE=2>>> > > As a meter of fact the problem is harder, since the function</FONT>
<BR><FONT SIZE=2>>> > > ib_cq_comp doesn't have a way to return an error. Please note</FONT>
<BR><FONT SIZE=2>>> > > that returning 0 is not enough because 0 is a legal option if</FONT>
<BR><FONT SIZE=2>>> > > nothing was found. As a result, there is a need to change all</FONT>
<BR><FONT SIZE=2>>> > > the callers of this function, so that the error will be</FONT>
<BR><FONT SIZE=2>>> > > propagated to there caller.</FONT>
<BR><FONT SIZE=2>>> ></FONT>
<BR><FONT SIZE=2>>> > What will the callers do with the propagated value? Would all</FONT>
<BR><FONT SIZE=2>>> > cases of errors on the CQ be accompanied by async affiliated</FONT>
<BR><FONT SIZE=2>>> > error notification for that CQ? What about for the QP?</FONT>
<BR><FONT SIZE=2>>></FONT>
<BR><FONT SIZE=2>>> Not sure I understand the question, but in general there are</FONT>
<BR><FONT SIZE=2>>> problems that are:</FONT>
<BR><FONT SIZE=2>>> - reported to the CQ (without async error), those are errors</FONT>
<BR><FONT SIZE=2>>> that have a WQE affiliated with them</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>These will result in a work completion being retrieved by ib_poll_cq and</FONT>
<BR><FONT SIZE=2>>are</FONT>
<BR><FONT SIZE=2>>handled.</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>> - reported as async errors, no CQE generated because there is no WQE</FONT>
<BR><FONT SIZE=2>>> affiliated with them</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>Async CQ errors aren't currently handled, but should be. Handling these is</FONT>
<BR><FONT SIZE=2>>going to be somewhat complicated, but certainly not impossible, due to the</FONT>
<BR><FONT SIZE=2>>one</FONT>
<BR><FONT SIZE=2>>to many CQ to QP relationship.</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>> - reported as async errors because CQ overflows</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>CQ overflow cannot happen due to the design of the provider.</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>>- Fab</FONT>
</P>
</BODY>
</HTML>