Project

General

Profile

Feature #1667

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

Added by Nitin Bhat over 1 year ago. Updated 3 months ago.

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

100%


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) MergedNitin Bhat

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

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

Feature #1805: Direct API for the GNI layerMergedNitin Bhat

Feature #1806: Direct API for pamilrts-bluegeneqMergedNitin Bhat

Feature #1807: Direct API for the Verbs layerMergedNitin Bhat

Feature #1808: Direct API for the MPI layerMergedNitin Bhat

Feature #1809: Direct API for the OFI layerMergedNitin Bhat

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

Documentation #1845: Documentation for the Zerocopy Direct API MergedNitin 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 over 1 year ago

  • Tracker changed from Bug to Feature

#2 Updated by Nitin Bhat over 1 year ago

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

#3 Updated by Sam White over 1 year 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 over 1 year ago

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

#5 Updated by Phil Miller over 1 year 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 over 1 year 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 about 1 year ago

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

#8 Updated by Nitin Bhat 10 months 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

#9 Updated by Nitin Bhat 8 months ago

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

#10 Updated by Nitin Bhat 3 months ago

  • Status changed from In Progress to Merged
  • Target version changed from 7 (Next Generation Charm++) to 6.9.0

Netlrts will not have a true "zero copy" implementation, it'll use the generic copy based implementation.

#11 Updated by Sam White 3 months ago

We could potentially use sendmsg and WSASend on netlrts-tcp as Juan did here, though I don't think it should be a priority right now:

https://charm.cs.illinois.edu/gerrit/#/c/charm/+/4357/
https://charm.cs.illinois.edu/gerrit/#/c/charm/+/4535/

Also available in: Atom PDF