[dat-discussions] [openib-general] [RFC] DAT 2.0 immediate data proposal

[Davis, Arlin R]

All,

 

During the DAT con-call today it was suggested that I draft the
application requirements for immediate data. Here is my first cut; fire
away!

 

"Applications need an optimized mechanism to notify the receiving end
that RDMA write data has completed beyond the two operation method
currently used (RDMA write followed by message send). This new RDMA
write feature will support 4-bytes of inline data that will be sent
immediately after the RDMA write operation is complete. It should avoid
any latency penalties normally associated with a two operation method.
The initiating side must expose a 4-byte immediate data parameter for
the application to set the inline data. The receiving side must provide
a mechanism to accept the 4-byte immediate data. On the receiving side,
the write with immediate completion notification is indicated through a
receive completion. It is the responsibility of the provider to identify
to the application 4-byte immediate data from a normal 4-byte send
message. The inline byte ordering is application specific."

 

Hopefully, this will help us come to a consensus on the proper interface
and delivery mechanism for immediate data. 

 

Thanks,

 

-arlin

 

________________________________

From: Hefty, Sean 
Sent: Thursday, February 02, 2006 3:54 PM
To: Davis, Arlin R; dat-discussions at yahoogroups.com
Cc: Lentini, James; openib-general at openib.org
Subject: RE: [dat-discussions] RE: [openib-general] RE: [RFC] DAT
2.0immediate data proposal

 

Here is an updated immediate data proposal based on the latest
discussions. I am working on a patch.

 

I don't see any app using this unless immediate data is supported, and
the data shows up in a completion.

 

You have variables to indicate support, the number of work requests
immediate consumes, and how the data is reported.  What app is going to
use this?  If writes are not supported, then the app will already have
to deal with doing a write followed by their own send.  As a further
complication, reserving the first 4 bytes of any receive buffer for
immediate data is only going to cause alignment issues for the user.

 

This defines an API with different behavior based on the underlying
transport in ways that are visible to the application.  Add a flag that
specifies if immediate data is supported.  Define one way of doing that,
and move on.  I fail to see any benefit complicating the API for a
transport that has to emulate transferring immediate data in an
application visible way.

 

- Sean

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20060203/35d53782/attachment.html>