Subject: RE: [rddp] Freeing QN=1 State

From: "Caitlin Bestler" <[email-masked]>
Date: Fri, 10 Dec 2004 12:04:18 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Michael C. Cambria
> Sent: Friday, December 10, 2004 9:50 AM
> To: [email-masked]
> Subject: [rddp] Freeing QN=1 State
> 
> 
> When does draft-ietf-rddp-rdmap-02.txt consider an inbound 
> RDMA Read Request Message finished such that the state 
> associated with QN=1 (the
> IRRQ) for the RDMA Read Request can be freed?
> 
> Put another way, if IRRQ is 1 (for simplicity), when is it 
> legal for a new RDMA Read Request to be received?  Is it:
> 
> a) Once the RDMA Read Response Message has been given to DDP?
> b) Once the RDMA Read Response Message has been "acked" by 
> the data sink?
> c) up to the implementation?
> d) specified somewhere that I just missed?
> 
The other side must not consider its RDMA Read Request complete
until it receives the RDMA Read Response. When the Data Source
considers it complete is a matter of implementation.

But conceptually, you should imagine that the RDMA Read engine
is simply an alternate ULP:

- it pre-posts receive buffers to accept RDMA Read Requests. It
  posts enough buffers for the number of credits it has been told
  were issued.
- it posts send requests to transmit RDMA Read Responses.

So basically, it has completed an RDMA Read Request when its
transmit requests complete. Just as with RDMA Write Requests
Submitted by the main ULP, completion is implementation dependent.
It indicates to the ULP that the source buffers are no longer
required. That may be because it has been LLP acked, or it may
be because the LLP has the buffers fully cached on its own.

Of course ultimately, its when the "RDMA Read Engine" has freed
up enough resources to repost its receive request. That depends
on how it tracks pending requests. If the other side does not 
post excess RDMA Read requests it will never have to know the
details of how the peer RDMA Read Engine is implemented.

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

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: "Michael C. Cambria" <[email-masked]>
Date: Fri, 10 Dec 2004 18:26:12 -0500

Caitlin Bestler wrote:

> until it receives the RDMA Read Response. 

Agreed.  This is in the draft Sec 7.5 #19.  A compliant sender isn't 
what I was concerned about.

I'm interpreting this to imply that the Data Source is justified in 
knocking down the session if it feels that the IRRQ is "still full". 
This addresses my concern about DoS.

 >                                           When the Data Source

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.

Thanks,
MikeC