Implementation and Design Questions

Design Issues

• How often do we expect a Homa::Transport instance to switch drivers?
  • Fixed at compile time?
  • Fixed at run-time (initialization) [Current design leans in this direction]
  • Dynamic but infrequent; ok to fail RPCs or migrate slowly when it happens?
  • Dynamic and frequent; would like to driver switch to be seamless.
• How do we expect applications to specify the driver they want?
• Should network addresses be driver specific or portable?
  • e.g. Should we use MAC for DPDK but IP for UPD? or
  • just use IP for everything?

Old Questions

• What's the right abstraction of this Homa library?
  • Message oriented vs RPC oriented? [Start with RPC - i.e. what RAMCloud has now]
  • Integrated poller or exported poller? [Allow use of application provided polling thread]
  • Sessions and sockets? [Revisit - Unclear that sessions are necessary]
  • How to handle memory lifetimes of message buffers? Copy contents? [Revisit - Use existing?]
• How do we provide configuration information?
  • File?
  • Constructor args?
• If the interface is not what we want how should we proceed? [Use mostly existing interface]
  • Start by shimming around the existing code?
  • Try to modify the interface as we go?
• Build tools? Make vs CMake vs Other [Used CMake]
• Are the drivers included in the library? [Drivers should be external]
• Split protocol processing from message assembly
  • Scheduling packets is a relatively centralized activity, but
  • Assembling packets into messages can be done in a data parallel manner.

Use Cases & Issues

• Async interface
  • Known request type
  • Known response type
  • Response larger than a single packet
• Sync interface
  • Non-copied response