RE: Freeing QN=1 State

> 
> Is there a window where the Data Sink ORRQ doesn't match the 
> Data Source IRRQ?  For example, a compliant Data Sink 
> completes the RDMA Read as you describe and sends a new one.  
> However, the Data Source doesn't have its implementation 
> specific criteria met for considering the Read in Queue 1 to 
> be complete.  The new RDMA Read from the Data Sink results in 
> the session being terminated.  Both sides claim they comply.
> 

Essentially you are asking, can the Data Sink have received
the completion of its RDMA Read Reply, and then submit a new
RDMA Read Request which will reach the peer *before* the
ack of the RDMA Read Reply does?

The answer is that it cannot because, the completion of the
RDMA Read Reply cannot be delivered to the Data Sink ULP before
The LLP has committed to LLP Ack that TCP Segment / SCTP chunk.

The next RDMA Read Request, being submitted *later* than the
decision to LLP Ack, cannot reach the other side *earlier*
than the LLP ack. From the LLP's perspective the ack must
occur earlier, or at worst get blurred to the "same time".
The order cannot get reversed.

If the Data Sink ULP cheats and peaks at memory to determine
When the RDMA Read has finished rather than waiting for the
Completion you could indeed get that type of race condidtion.
That's one of many reasons why all warranties are void if the
ULP acts upon buffers before they are delivered.

--
Caitlin Bestler
Director Software Architecture
Siliquent Technologies
[email protected]