HomeSort by relevance Sort by last modified time
    Searched refs:RDMA_MESSAGE_TENSOR_RE_REQUEST (Results 1 - 3 of 3) sorted by null

  /external/tensorflow/tensorflow/contrib/verbs/
rdma.cc 54 case RDMA_MESSAGE_TENSOR_RE_REQUEST:
55 return "RDMA_MESSAGE_TENSOR_RE_REQUEST";
498 } else if (rm.type_ == RDMA_MESSAGE_TENSOR_RE_REQUEST) {
    [all...]
rdma.h 81 RDMA_MESSAGE_TENSOR_RE_REQUEST,
README.md 51 * RDMA_MESSAGE_TENSOR_RE_REQUEST
80 3. Re-send the tensor request. For traceability, the new message has a different name: **RDMA_MESSAGE_TENSOR_RE_REQUEST**.
82 When the sender receives a **RDMA_MESSAGE_TENSOR_RE_REQUEST**, it will locate the relevant **RdmaTensorResponse** using the request index specified in the message, and invoke its **Resume()** method, which will RDMA write the contents of the tensor that was cloned earlier, to the new remote address specified in the re-request.
99 3. The sending of protocol messages (**RDMA_MESSAGE_TENSOR_REQUEST**, **RDMA_MESSAGE_META_DATA_RESPONSE** and **RDMA_MESSAGE_TENSOR_RE_REQUEST**) is done by the class **RdmaMessageBuffer**. All messages are sent using RDMA writes from/to fixed messages buffers. This implies that we cannot send on a specific channel more than one message at a time. In order to synchronize the messages, the **RdmaMessageBuffer** holds the a local and remote buffer statuses which can be either busy or idle. When a write is issued, both statuses will be changed to busy. When the write-complete event is received, the local status is changed to idle. When the write is received on the remote side, the remote side will parse the message, and return an ACK back to the sending side on which the sending side will update the remote status to idle. When both the local and remote statuses are idle, the next message can be sent.
156 * **RDMA_MESSAGE_TENSOR_RE_REQUEST** - (receiver ==> sender) Tensor re-request after meta-data update and reallocation of result/proxy tensors.

Completed in 1083 milliseconds