Subject: [rddp] Increasing MO/TO Order

From: Caitlin Bestler <[email-masked]>
Date: Mon, 9 Dec 2002 13:40:48 -0600

The minutes reminded me that we never officially closed the
"increasing TO order" modification.

First, as a "SHOULD" this is of absolutely no use.  "SHOULD"
level it does not allow receiver optimization, it will only
discourage sender side optimizations.

Freedom to send data in any order is vital when the source
material is not physically aggregated in advance. For
storage protocols deliverying payload via tagged messages
this is an extremely likely scenario. It is not an
exception, rather it is one of the primary *benefits* of
RDMA. If I said anything about the order of tagged
deliveries it would be:

    The Data Source SHOULD NOT delay the sending of any
    portion of a Tagged Message merely to presever TO order.
    
There is *some* justification for MO ordering within
untagged messages. The Data Source for an untagged message
is far more likely to have been physically assembled anyway,
and there are some (albeit minor) optimizations related to
scatter-gather-lists on receive operations.

But there are no scatter-gather-lists for tagged messages,
because there are no receives posted for tagged messages.

I still favor eliminating this clause totally. But in the
absence of that:

-- it needs to be eliminated for Tagged Messages.
-- it should be elevated to a MUST for Untagged Messages.
    As a 'SHOULD' it only discourages send optimizations
    and does not enable receive side optimizations.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: "Williams, Jim" <[email-masked]>
Date: Mon, 9 Dec 2002 15:16:39 -0500

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]]
> Sent: Monday, December 09, 2002 2:41 PM
> To: [email-masked]
> Subject: [rddp] Increasing MO/TO Order
> 
> 

I agree with this assessment of "SHOULD".

However, I am particularly sensitive to anything that may
cause the state that must be maintained by the receiver
to be of non-fixed size.

I won't try to analyze the implications of the above here.
But a careful look should be taken at how this is implemented
at the receiver, and if it can be done without scoreboarding,
or at least with fixed size scoreboards.  If not, I think it
creates a real and unnecessary problem for the receiver.
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp