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

[Larsen, Roy K]

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