RE: (no subject)

The case you describe must result in reading "Cs" from location 300.  It
would not matter what order FPDU B and C arrived in, they always place
in different locations.  And the RDMA Read always takes place after both
placements have occurred (when delivered).

If your test case was meant to place FPDU C in the same location as FPDU
B (location 200) then you can get unexpected results.

This is an interesting case, one that was explicitly described in the
RDMA spec.  I quote from section 7.5 "ordering and completions":

     3.  RDMA Messages that use Tagged and Untagged Buffers MAY be 
          Placed in any order.  If an application uses overlapping 
          buffers (points different Messages or portions of a single 
          Message at the same buffer), then it is possible that the last

          incoming write to the Data Sink buffer will not be the last 
          outgoing data sent from the Data Source. 

So if both FPDU B and C placed at location 200, and FPDU B arrived later
than FPDU C, then you would read back "Bs" from 200, even though you (as
a sender) thought you sent the "Cs" later, and they should have been
read back.

Paul R. Culley
HP Fellow
281-514-5543
 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Barry Reinhold
> Sent: Tuesday, November 30, 2004 7:36 AM
> To: RDDP
> Cc: [email protected]
> Subject: [rddp] (no subject)
> 
> 
> I would like to know if there is agreement on the following:
> 
> Given a Marker supporting Data Source that sends:
> 
> ++++++++++++++++++++++++++++
> | TCP SEG #1               |
> ++++++++++++++++++++++++++++
> Contains FPDU A (write STag 1, loc 100 with 100 A's)
> 
> ++++++++++++++++++++++++++++
> | TCP SEG #2               |
> ++++++++++++++++++++++++++++
> Contains FPDU B (write STag 1, loc 200 with 100 B's)
> 
> ++++++++++++++++++++++++++++
> | TCP SEG #3               |
> ++++++++++++++++++++++++++++
> Contains FPDU C (write STag 1, loc 300 with 100 C's), and 
> FPDU D (Read STag 1, 100 bytes from loc 300)
> 
> A marker falls in FPDU D.
> 
> During transmission TCP SEG #2 is lost, such that TCP SEG #3 
> arrives out of order at the Data Sink. The iWARP receiver 
> recovers FPDU sync by using the marker in FPDU D. TCP SEG #2 
> then arrives.
> 
> Is it the case that for a "conformant" Data Sink the contents 
> in the RDMA READ RESPONSE SHALL be "C"s?
> 
> This is interesting in that there is no gap in the TCP 
> sequence space as delivered by TCP to MPA, but there is a gap 
> in terms of what MPA has "processed".
> 
> Since clause 5.4 states that:
> 
> At the Data Sink, DDP MUST Deliver a DDP Message if and only if all 
>    of the following are true: 
> 
>      * the last DDP Segment of the DDP Message had its Last 
> flag set,  
> 
>      * all of the DDP Segments of the DDP Message have been Placed, 
> 
>      * all preceding DDP Messages have been Placed, and 
> 
>      * each preceding DDP Message has been Delivered to the ULP.
> 
> I assume that we can expect "C"s in the READ RESPONSE.
> 
> This is scheduled to become a conformance test, so I would 
> like to ensure there is agreement.
>  
> 
> 
> 
> Barry Reinhold
> Lamprey Networks
> [email protected]
> (603) 868-8411
>  
> 
> 
> 
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp
>