You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In issue #99, we already are proposing to allow the sender to preallocate a memory buffer from Derecho's pinned, mapped memory area and use that as the basis for a p2p_send or ordered_send, with no copying required.
This proposal is similar, but for the receiver side: a receiver that always receives, say, video objects, might want to preallocate a place for the incoming video transfer, and have Derecho put the incoming data directly into that location. This is a separate issue because, due to the way that RDMC chunks large objects, it will be harder to implement the solution (the first chunk always comes into Derecho memory, so the proposed mechanism would still require a memcpy to put that first chunk into its final location). Not enormously harder, but non-trivial.
The text was updated successfully, but these errors were encountered:
In issue #99, we already are proposing to allow the sender to preallocate a memory buffer from Derecho's pinned, mapped memory area and use that as the basis for a p2p_send or ordered_send, with no copying required.
This proposal is similar, but for the receiver side: a receiver that always receives, say, video objects, might want to preallocate a place for the incoming video transfer, and have Derecho put the incoming data directly into that location. This is a separate issue because, due to the way that RDMC chunks large objects, it will be harder to implement the solution (the first chunk always comes into Derecho memory, so the proposed mechanism would still require a memcpy to put that first chunk into its final location). Not enormously harder, but non-trivial.
The text was updated successfully, but these errors were encountered: