[dat-discussions] [openib-general] [RFC] DAT2.0immediatedataproposal

[Kanevsky, Arkady]

We have problem no matter which option we choose.
The current Transport Level Requirement state:

There is a one-to-one correspondence between send operation on one
Endpoint of the Connection and recv operations on the other Endpoint of
the Connection.
There is no correspondence between RDMA operations on one Endpoint of
the Connection and recv or send data transfer operation on the other
Endpoint of the Connection.
Receive operations on a Connection must be completed in the order of
posting of their corresponding sends.

The Immediate data and Atomic ops violate these requirements including
ordering
rules.

I had started updating these rules when I generated the first draft of
the
requirements. They are included in the enclosed pdf file.
But they do not cover Atomic ops that also impact transport
requirements.
This chapter of the spec have not been changed since DAPL 1.0
and I am very concern with any changes to it.

Arkady

Arkady Kanevsky                       email: arkady at netapp.com
Network Appliance Inc.               phone: 781-768-5395
1601 Trapelo Rd. - Suite 16.        Fax: 781-895-1195
Waltham, MA 02451                   central phone: 781-768-5300
 

> -----Original Message-----
> From: Caitlin Bestler [mailto:caitlinb at broadcom.com] 
> Sent: Tuesday, February 07, 2006 6:57 PM
> To: Larsen, Roy K; dat-discussions at yahoogroups.com; Arlin 
> Davis; Hefty, Sean
> Cc: openib-general at openib.org
> Subject: RE: [dat-discussions] [openib-general] [RFC] 
> DAT2.0immediatedataproposal
> 
> openib-general-bounces at openib.org wrote:
> 
> > 
> > I was under the assumption that the DAT community defined 
> the APIs and 
> > semantics through an open process.  Given that the IB write 
> immediate 
> > data facility does not break the implementation or semantics of the 
> > currently defined RDMA write facility, I see no reason the 
> DAPL spec 
> > couldn't be updated, through consensus, with the realities 
> of existing 
> > transport services.  Nevertheless, I presume you'll have no 
> objection 
> > to implementing this useful service as a DAPL extension since the 
> > semantic rules for extensions haven't been define yet.
> > 
> > Roy
> 
> That is correct, because as an extension the user would not 
> expect normal semantics to still be guaranteed.
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> <*> To visit your group on the web, go to:
>     http://groups.yahoo.com/group/dat-discussions/
> 
> <*> To unsubscribe from this group, send an email to:
>     dat-discussions-unsubscribe at yahoogroups.com
> 
> <*> Your use of Yahoo! Groups is subject to:
>     http://docs.yahoo.com/info/terms/
>  
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: transport_req_020706.pdf
Type: application/octet-stream
Size: 26434 bytes
Desc: transport_req_020706.pdf
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20060207/2f5044b5/attachment.obj>