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

[Sean Hefty]

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/20060202/8b70a148/attachment.html>