[Pre-RFC] More meaningful names in rpc module in Python

Development pre-RFC
#1

Hello,

I’m reading code of RPC module in Python, and many elements are hard to understand for me. I’m not a big expert, but I think some of them should be more meaningfull, so I suggest to change their names. We can discus about my suggestions.

Minor changes:

  • python/tvm/rpc/client.py

    • function connect_tracker isn’t connecting to tracker explicitly. It creates TrackerSession, so its name should be get_tracker_session or get_active_tracker_session. And it is only one line, so if we do not plan to modify this function, then we cat remove it. All variables, to whose we assign output should be named tracker_session, not tracker.
    • TrackerSession.request should be renamed. Name suggest it will return request, but instead we are getting RPCSession. I think good name would be request_connection or get_rpc_session. All variables, to whose we assign output should be named rpc_session. We can introduce one level of inheritance, e.g. class RemoteDevice(RPCSession)

  • python/tvm/rpc/server.py

    • rename Server to RPCServer

  • python/tvm/autotvm/measure/measure_methods.py

    • class LocalRunner(RPCRunner) - this is hard to understand. I think that some functionality of RPCRunner should be moved to Runner class

Big changes:

  • RPC Tracker is also server, because it has infinite loop.
  • RPC Server is server by name. But in some ways it is a kind of client, because it connects to the tracker.
  • In my opinion better names would be RPC Manager and RPC Worker. Session to Manager we can name ManagerSession, Session to Worker we can name WorkerSession. Functions to connect we can name connect_worker, connect_manager respectively. WorkerServer, ManagerServer also are good names.
  • I’m not sure how to treat proxy :confused:
1 Like
#2

Another connected issue: extract device-related stuff from tvm/runtime/ndarray.py to e.g. tvm/runtime/device.py:

  • def device
  • def cpu
  • def cuda
  • def gpu
  • def rocm
  • def opencl
  • def metal
  • def vpi
  • def vulkan
  • def ext_dev
  • def hexagon
  • def webgpu
  • cl
  • mtl
#3

Thanks for the discussion. The terminology of server/client/proxy have things to do with the main RPC traffice. The server was serving RPC request(data plane).

The tracker was an orchestration layer built on top, which tracks the servers available. Tracker do not serve RPC request but simply dispatches the requrest to other places. The terminology matches tracker in p2p setting. Note that tracker is not strictly needed in many settings, as there might be different ways to setup the server/client connections.

We can certainly see reasons for using a different kind of naming scheme(e.g. worker and manager) as well. The current naming scheme also had its own reasoning background, and some of the choices can be preference-based (e.g. rpc.Server vs rpc.RPCServer).

Given a lot of the code depends on some of API names so we might want to reduce the amount of changes when possible, we could definitely improve documentation on the other hand to clarify these functions.

1 Like
#4

@tqchen I have skipped renaming RPC classes as you said, maybe after larger discussion with others we can go back to this RFC. Despite of that, I have created PR with my answer, about moving device functions to proper place. Can you review it: https://github.com/apache/tvm/pull/11126