[dat-discussions] [openib-general] [RFC] DAT 2.0 immediatedataproposal

[Kanevsky, Arkady]

Roy,
Can you explain, please?

For IB the operation will be layered properly on Transport primitive.
And on Recv side it will indicate in completion event DTO
that it matches RDMA Write with Immediate and that Immediate Data
is in event.

For iWARP I expect initially, it will be layered on RDMA Write
followed by Send. The Provider can do post more efficiently
than Consumer and guarantee atomicity. 
On Recv side Consumer will get Recv DTO completion in event
and Immediate Data inline as specified by Provider Attribute.

>From the performance point of view Consumers who program to IB
only will have no performance degradation at all. But this API also
allows Consumers to write ULP to be transport independent
with minimal penalty: one binary comparison and extra 4 bytes in recv
buffer.

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: Monday, February 06, 2006 2:10 PM
> To: Caitlin Bestler; dat-discussions at yahoogroups.com; 
> Kanevsky, Arkady; Sean Hefty
> Cc: openib-general at openib.org
> Subject: RE: [dat-discussions] [openib-general] [RFC] DAT 2.0 
> immediatedataproposal
> 
> If it is up to the ULP to separate out "normal" receive data 
> from that associated with a write immediate, how is this 
> different from the ULP doing a write followed by a send?  If 
> there is no difference, then what we're really talking about 
> is a convenience to the initiating ULP.
> 
> Perhaps what would be best is to construct an API that allows 
> the ULP to perform standard write/send operations into one 
> call which the underlying provider could optimize into one 
> transaction with the associated interconnect interface. 
> Better yet, a general request combining interface would have 
> even more value, but calling this write/send "immediate" data 
> is a stretch, if not downright silly.  Some transports have 
> true immediate data that provides unique value.  There is 
> nothing unique in a write/send sequence - ULPs do it all the time...
> 
> Roy
> 
> -----Original Message-----
> From: openib-general-bounces at openib.org
> [mailto:openib-general-bounces at openib.org] On Behalf Of 
> Caitlin Bestler
> Sent: Monday, February 06, 2006 10:48 AM
> To: dat-discussions at yahoogroups.com; Kanevsky, Arkady; Sean Hefty
> Cc: openib-general at openib.org
> Subject: RE: [dat-discussions] [openib-general] [RFC] DAT 2.0 
> immediatedataproposal
> 
> dat-discussions at yahoogroups.com wrote:
> > Arkady,
> > 
> > Your requirements are slightly different then the proposed set of 
> > requirements.
> > 
> > "iii) DAPL Provider does not provide any identification 
> that that the 
> > Receive operation matches remote RDMA Write with Immediate 
> data if it 
> > completes as Receive DTO.
> > 
> > 	- It is up to an ULP to separate Receive completion of remote
> > Send from remote RDMA Write with 	  Immediate Data."
> > 
> > Tell me how this is possible? How can the application distinguish 
> > between a 4 byte message and a 4 byte immediate data 
> message? We would 
> > have to add a new requirement... "If the provider supports 
> immediate 
> > data in the payload the ULP cannot send a message equal to the 
> > immediate data size".
> > 
> 
> The data sink knows whether the 4 bytes was sent as a message 
> or as an immediate because it is clear in the ULP context.
> Possible methods:
> 	The expected completion is an immediate.
> 	All 4 byte messages are immediates.
> 	All 4 byte messages where the ms-byte is X are immediate.
> 	If its Tuesday its an immediate.
> 	If it's a prime number its an immediate
> 	...
> 
> But there is no clue from the transport layer.
> 
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
> 
> To unsubscribe, please visit
> http://openib.org/mailman/listinfo/openib-general
>