Project

General

Profile

Feature #1667

Direct API for nocopy operations on sender-side and receiver-side

Added by Nitin Bhat 6 months ago. Updated 3 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
Machine Layers
Target version:
Start date:
02/20/2018
Due date:
% Done:

0%


Description

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.


Subtasks

Feature #1802: Direct API for the generic layer (non-rdma based default implementation) ImplementedNitin Bhat

Feature #1803: Direct API for the LRTS layer ImplementedNitin Bhat

Feature #1804: Direct API - Add CMA support for netlrts, multicore and pami buildsImplementedNitin Bhat

Feature #1805: Direct API for the GNI layerIn ProgressNitin Bhat

Feature #1806: Direct API for the PAMILRTS layerIn ProgressNitin Bhat

Feature #1807: Direct API for the Verbs layerIn ProgressNitin Bhat

Feature #1808: Direct API for the MPI layerIn ProgressNitin Bhat

Feature #1809: Direct API for the OFI layerIn ProgressNitin Bhat

Feature #1810: Direct API - Support multiple user operation modesIn ProgressNitin Bhat


Related issues

Related to Charm++ - Feature #1655: Enable use of shm transport for regular messages in LRTS Merged 10/25/2017

History

#1 Updated by Nitin Bhat 6 months ago

  • Tracker changed from Bug to Feature

#2 Updated by Nitin Bhat 6 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 50

#3 Updated by Sam White 6 months ago

  • 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).

#4 Updated by Phil Miller 6 months ago

  • Tags changed from #rdma to #rdma, ampi, #api, #machine-layers

#5 Updated by Phil Miller 6 months ago

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.

#6 Updated by Phil Miller 6 months ago

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.

#7 Updated by Nitin Bhat 4 months ago

  • Related to Feature #1655: Enable use of shm transport for regular messages in LRTS added

#8 Updated by Nitin Bhat 3 days ago

  • 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

Also available in: Atom PDF