package tensorflow.eager

Get desktop application:
View/edit binary Protocol Buffers messages

////////////////////////////////////////////////////////////////////////////// Eager Service defines a TensorFlow service that executes operations eagerly on a set of local devices, on behalf of a remote Eager executor. The service impl will keep track of the various clients and devices it has access to and allows the client to enqueue ops on any devices that it is able to access and schedule data transfers from/to any of the peers. A client can generate multiple contexts to be able to independently execute operations, but cannot share data between the two contexts. NOTE: Even though contexts generated by clients should be independent, the lower level tensorflow execution engine is not, so they might share some data (e.g. a Device's ResourceMgr). //////////////////////////////////////////////////////////////////////////////

• rpc CreateContext (CreateContextRequest, CreateContextResponse)

  eager_service.proto:195

  This initializes the worker, informing it about the other workers in the cluster and exchanging authentication tokens which will be used in all other RPCs to detect whether the worker has restarted.

  message CreateContextRequest

  eager_service.proto:64

  • optional ServerDef server_def = 1

    Identifies the full cluster, and this particular worker's position within.

  • bool async = 2

    Whether the ops on the worker should be executed synchronously or asynchronously. By default, ops are executed synchronously.

  • int64 keep_alive_secs = 3

    Number of seconds to keep the context alive. If more than keep_alive_secs has passed since a particular context has been communicated with, it will be garbage collected.

  • optional VersionDef version_def = 4

    This is the version for all the ops that will be enqueued by the client.

  • repeated DeviceAttributes cluster_device_attributes = 6

    Device attributes in the cluster

  • fixed64 context_id = 7

    The ID of the created context. This is usually a randomly generated number, that will be used to identify the context in future requests to the service. Contexts are not persisted through server restarts. This ID will be used for all future communications as well. It is essential that both ends use this ID for selecting a rendezvous to get everything to match.

  message CreateContextResponse

  eager_service.proto:94

  • repeated DeviceAttributes device_attributes = 2

    List of devices that are locally accessible to the worker.

• rpc Enqueue (EnqueueRequest, EnqueueResponse)

  eager_service.proto:202

  This takes a list of Execute and DeleteTensorHandle operations and enqueues (in async mode) or executes (in sync mode) them on the remote server. All outputs of ops which were not explicitly deleted with DeleteTensorHandle entries will be assumed to be alive and are usable by future calls to Enqueue.

• rpc StreamingEnqueue (stream EnqueueRequest, stream EnqueueResponse)

  eager_service.proto:210

  A streaming version of Enqueue. Current server implementation sends one response per received request. The benefit for using a streaming version is that subsequent requests can be sent without waiting for a response to the previous request. This synchronization is required in the regular Enqueue call because gRPC does not guarantee to preserve request order.

• rpc WaitQueueDone (WaitQueueDoneRequest, WaitQueueDoneResponse)

  eager_service.proto:214

  Takes a set of op IDs and waits until those ops are done. Returns any error in the stream so far.

  message WaitQueueDoneRequest

  eager_service.proto:112

  • fixed64 context_id = 1

  • repeated int64 op_id = 2

    Ids to wait on. If empty, wait on everything currently pending.

  message WaitQueueDoneResponse

  eager_service.proto:119

  TODO(nareshmodi): Consider adding NodeExecStats here to be able to propagate some stats.

  (message has no fields)

• rpc KeepAlive (KeepAliveRequest, KeepAliveResponse)

  eager_service.proto:219

  Contexts are always created with a deadline and no RPCs within a deadline will trigger a context garbage collection. KeepAlive calls can be used to delay this.

  message KeepAliveRequest

  eager_service.proto:124

  • fixed64 context_id = 1

  message KeepAliveResponse

  eager_service.proto:128

  (message has no fields)

• rpc CloseContext (CloseContextRequest, CloseContextResponse)

  eager_service.proto:223

  Closes the context. No calls to other methods using the existing context ID are valid after this.

  message CloseContextRequest

  eager_service.proto:130

  • fixed64 context_id = 1

  message CloseContextResponse

  eager_service.proto:134

  (message has no fields)

• rpc RegisterFunction (RegisterFunctionRequest, RegisterFunctionResponse)

  eager_service.proto:226

  Takes a FunctionDef and makes it enqueable on the remote worker.

  message RegisterFunctionRequest

  eager_service.proto:136

  • fixed64 context_id = 1

  • optional FunctionDef function_def = 2

  message RegisterFunctionResponse

  eager_service.proto:142

  (message has no fields)

• rpc SendTensor (SendTensorRequest, SendTensorResponse)

  eager_service.proto:232

  TODO(fishx): Remove this method. An RPC to push tensors to the server. At times, certain environments don't allow the server to connect back to the client.

  message SendTensorRequest

  eager_service.proto:157

  • fixed64 context_id = 1

  • int64 op_id = 2

    All remote tensors are identified by <Op ID, Output num>. To mimic this situation when directly sending tensors, we include an "artificial" op ID (which would have corresponded to the _Recv op when not using SendTensor).

  • repeated TensorProto tensors = 3

    The index within the repeated field is the output number that will help uniquely identify (along with the above op_id) the particular tensor.

  • string device_name = 4

    The device on which the tensors should be resident.

  message SendTensorResponse

  eager_service.proto:172

  (message has no fields)

Used as request type in: EagerService.Enqueue, EagerService.StreamingEnqueue

• fixed64 context_id = 1

• repeated QueueItem queue = 3

Used as response type in: EagerService.Enqueue, EagerService.StreamingEnqueue

• repeated QueueResponse queue_response = 1

  A single operation response for every item in the request.

A proto representation of an eager operation.

Used in: QueueItem

• int64 id = 1

  A unique identifier for the operation. Set by the client so that the client can uniquely identify the outputs of the scheduled operation. In the initial implementation, sending duplicate IDs has undefined behaviour, but additional constraints may be placed upon this in the future.

• string name = 2

• repeated RemoteTensorHandle inputs = 3

• repeated int64 control_op_ids = 4

  Control Operation IDs that will be respected when ops are re-ordered by async execution. If async execution (+ op re-ordering) is not enabled, this should have no effect.

• map<string, AttrValue> attrs = 5

• string device = 6

Used in: EnqueueRequest

• oneof item

  The remote executor should be able to handle either executing ops directly, or releasing any unused tensor handles, since the tensor lifetime is maintained by the client.

  • RemoteTensorHandle handle_to_decref = 1

  • Operation operation = 2

  • SendTensorOp send_tensor = 3

Used in: EnqueueResponse

• repeated TensorShapeProto shape = 1

Used in: Operation, QueueItem

• int64 op_id = 1

  The ID of the operation that produced this tensor.

• int32 output_num = 2

  The index into the outputs of the operation that produced this tensor.

• string device = 3

  Device of the operation that produced this tensor. Cannot be empty. For multi-device functions, it's the default device passed to placer.

• string op_device = 4

  Device where the tensor is located. Can be empty if the operation producing this tensor is a multi-device function.

• DataType dtype = 5

  Tensor type.

Used in: QueueItem

• int64 op_id = 1

  All remote tensors are identified by <Op ID, Output num>. To mimic this situation when directly sending tensors, we include an "artificial" op ID (which would have corresponded to the _Recv op when not using SendTensor).

• repeated TensorProto tensors = 2

  The index within the repeated field is the output number that will help uniquely identify (along with the above op_id) the particular tensor.

• string device_name = 3

  The device on which the tensors should be resident.