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

[Kanevsky, Arkady]

IB does optionally support send_with_invalidate as defined in IBTA 1.2
spec.
OpenIB does not support this yet but this is a different matter.
So this is bad analogy.

The better analogy is socket based CM. 

But I am still not clear what you are advocating:
extensions, IB specific API or something else.

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: Larsen, Roy K [mailto:roy.k.larsen at intel.com] 
> Sent: Tuesday, February 07, 2006 2:46 PM
> To: dat-discussions at yahoogroups.com; Arlin Davis; Hefty, Sean
> Cc: Kanevsky, Arkady; Sean Hefty; openib-general at openib.org
> Subject: RE: [dat-discussions] [openib-general] [RFC] 
> DAT2.0immediatedataproposal
> 
> Caitlin Bestler wrote:
> >
> >Arlin Davis wrote:
> >> Sean Hefty wrote:
> >>
> >>>> The requirement is to provide an API that supports RDMA 
> writes with 
> >>>> immediate data.  A send that follows an RDMA write is 
> not immediate 
> >>>> data, and the API should not be constructed around 
> trying to make 
> >>>> it so.
> >>>>
> >>>>
> >>>
> >>> To be clear, I believe that write with immediate should 
> be part of 
> >>> the normal APIs, rather than an extension, but should be designed 
> >>> around those devices that provide it natively.
> >>>
> >>>
> >> I totally agree. A standard RDMA write with immediate API 
> can be very 
> >> useful to RDMA applications based on the requirements (native 
> >> support) set forth in my earlier email. It is analogous to the new 
> >> dat_ep_post_send_with_invalidate() call; a call that supports a 
> >> native iWARP transport operation but provides no 
> provisions to help 
> >> other transports emulate. So, other transports simply return 
> >> NOT_SUPPORTED and add it natively in the future if it makes sense.
> >>
> >> -arlin
> >
> >What is proposed in a definition of
> >'dat_ep_post_rdma_write_with_immediate'
> >that can be implemented over iWARP using the sequence of 
> messages that 
> >were intended to support the same purpose (i.e., letting the 
> other side 
> >know that an RDMA Write transfer has been fully received).
> 
> No, iWARP *CAN NOT* implement write immediate data any better 
> than IB can implement send with invalidate.  Immediate data 
> *MUST* be indicated to the ULP unambiguously.  Imposing an 
> algorithm on the application to infer immediate data arrival 
> is hack, pure and simple. An application is free to perform a 
> write/send if that is the semantic they want.  Why does iWARP 
> get transport unique APIs but not IB?  I find this attempt to 
> bastardize the IB semantic of immediate data a little curious.
> 
> Roy
>