Direct API for nocopy operations on sender-side and receiver-side
Since the receiver side API (https://charm.cs.illinois.edu/redmine/issues/1236) has restrictions which demand the user to name a generated entry method in a specific manner in order to overload the generated method, it will be a worthwhile effort to have an alternative API which is more direct as compared to entry method overloading and gives user the control to perform GET/PUT calls directly.
- Tracker changed from Bug to Feature
- Status changed from New to In Progress
- % Done changed from 0 to 50
- Target version set to 6.9.0
We may want to avoid calling this "direct" since there is already something else called CmiDirect. I think in general the recv-side stuff is the completion of the Zero Copy API, but the fact that we will eventually have 2 APIs for the recv-side stuff will make it a bit confusing (I think of this API as the lower-level one, and the RdmaPost one as the higher-level abstraction).
- Tags changed from #rdma to #rdma, ampi, #api, #machine-layers
If the generic layer gets done, possibly even with a hacky implementation that only really provides one of GET or PUT and uses that for the other, then we can implement the other layers piecemeal after the basic thing is integrated.
And similarly, that one-of-GET-or-PUT design can get us up and running on the other layers quickly, though, with an extra round trip, and then be optimized later.
- Related to Feature #1655: Enable use of shm transport for regular messages in LRTS added
- Subject changed from Direct User level API for nocopy operations on sender-side and receiver-side to Direct API for nocopy operations on sender-side and receiver-side
- Target version changed from 6.9.0 to 7 (Next Generation Charm++)
Except for documentation for the Direct API, which is targeted for 6.9, all the other tasks are for later releases.
Also available in: Atom