Subject: RE: [rddp] IFT-01 - SP (Speculative Placement) Flag

From: "Williams, Jim" <[email-masked]>
Date: Sun, 23 Feb 2003 11:37:47 -0500

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]]
> Sent: Thursday, February 20, 2003 11:16 PM
> To: [email-masked]
> Subject: [rddp] IFT-01 - SP (Speculative Placement) Flag
> 
> 
> The proposed flags include:
> 
> > SP          Indicates the sender is giving the receiver
> > permission to do speculative placement.  If this bit is
> > set, the receiver MAY do speculative placement.  If not
> > set, the receiver MUST NOT do speculative placement. See
> > the chapter below for full description of speculative
> > placement.
> 
> Why would the *sender* have an interest in mandating that
> the receiver not take risks with the *receiver's* memory?

I am sure the draft could have been better at explaining this.
The important point is that the receiver is taking *no risk*
with its memory as long as the ULP follows the rules for 
speculative placement.  These rules are basically:

  1.  De-register (remove remote write access) to all buffers
      before allowing the ULP to look at them.

  2.  Do not write a memory location more that once during the
      period that a buffer is remote write enabled.  This may
      be necessary anyway if out of order placement is to
      have deterministic results.

  3.  Do not assume anything about the contents of unwritten 
      memory locations within buffers that have been 
      registered for remote write access.

So the ULP knows that as long as these rules are followed,
speculative placement works and is risk free.  The flag bit
is arguably redundant since the ULP already knows if it 
supports speculative placement, however like much of the
proposed adaption indication, it is a redundant confirmation
designed to reduce risk of a mix up between the two ends.

> Can the sender specify that the receiver not take risks with
> the data by running certain operating systems?

Huh?  Which operating systems do you think are too riksy? :)

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

---

From: Michael Krause <[email-masked]>
Date: Sun, 23 Feb 2003 14:45:19 -0800

>       before allowing the ULP to look at them.

Why?  The ULP owns the buffers and once delivered, it knows the contents 
correct from the LLP / DDP / RDMA perspective.  If someone wants to 
invalidate access rights, then it is a ULP issue and not a DDP/RDMA issue 
to resolve.  DDP/RDMA provides an invalidate option to close this update 
capability if desired.

>       have deterministic results.

Once a buffer is advertised, it is up to the LLP to insure that duplicates 
are not placed thus there is no value in providing such a capability as 
this is truly redundant to the LLP responsibilities.  If one is concerned 
about a partial overwrite by a subsequent operation, then a sender-based 
FENCE should be used to insure that the operation is completed (can be done 
as a RDMA Read or a delay in processing the next operation until the window 
progresses to indicate the previous operation has been placed).  In 
general, buffer state in non-deterministic until the window has progressed 
to indicate everything has been delivered.

>       registered for remote write access.

If the memory has not been written to and the contents were not the target 
of any update (i.e. the consumer has not advertised the memory for update 
by any operation), then the memory is clearly known even if it is 
registered.  Registration just states the virtual-to-physical or the 
physical addresses are capable of being accessed - it does not change the 
state of the buffers or their ability to be coherently accessed by an 
application or a ULP.

>designed to reduce risk of a mix up between the two ends.

It does not add value from what you have described here.

Mike