|
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 |
_______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
