ipc_extension.mdwn

   1 # IPC Extension
   2
   3 see Tony Brewer's (Micron) slides.
   4
   5 see barrelfish paper
   6
   7 idea: copy POSIX send/recv/select semantics
   8
   9 dependency(?): scratch/CAM memory extension
  10
  11 * MSTORE: message send; send message to a target hart) and store it in
  12   its message-buffer. Traps when target buffer is full.
  13 * MLOAD: message load; load message from local message buffer. Traps
  14   when buffer is empty.
  15 * MFLUSH(?): flush local buffer
  16 * MSELECT: check if send (or receive) can succeed (or block)
  17
  18 ------
  19
  20 I don't want to propose or advocate a full solution at this point, but
  21 a simple one might use a small CAM-based message system for fast
  22 storage (write) and retrieval (read) using an agreed key. If this was
  23 to fit into a two-operand instruction, both the key and destination
  24 must be encoded into one source register, with the data-to-send
  25 encoded into the other source register, and a result (sent or dropped)
  26 returned into rd.
  27
  28 rs1 = key-id = prepare-to-send(dest-processID) // a system call to
  29 allocate a communications channel + src + dest encoded into key-id
  30 rs2 = data
  31 rd = return code
  32
  33 MSEND  rd, rs1, rs2 // to send
  34 MRECVB rd, rs1, x0  // nonblocking receive, returns 0 if no data present
  35 MRECVB rd, rs1, x0  // blocking receive
  36
  37 behaviour:
  38 MSEND is nonblocking, [rd]=1 on successful acceptance network (network
  39 delivery guaranteed)
  40 MRECV is nonblocking, [rd]=0 on no data to receive, [rd]=message
  41 otherwise (cannot send 0 as message)
  42 MRECVB is blocking, waits until data arrives (can send 0 as a message)I don't want to propose or advocate a full solution at this point, but
  43 a simple one might use a small CAM-based message system for fast
  44 storage (write) and retrieval (read) using an agreed key. If this was
  45 to fit into a two-operand instruction, both the key and destination
  46 must be encoded into one source register, with the data-to-send
  47 encoded into the other source register, and a result (sent or dropped)
  48 returned into rd.
  49
  50 rs1 = key-id = prepare-to-send(dest-processID) // a system call to
  51 allocate a communications channel + src + dest encoded into key-id
  52 rs2 = data
  53 rd = return code
  54
  55 MSEND  rd, rs1, rs2 // to send
  56 MRECVB rd, rs1, x0  // nonblocking receive, returns 0 if no data present
  57 MRECVB rd, rs1, x0  // blocking receive
  58
  59 behaviour:
  60 MSEND is nonblocking, [rd]=1 on successful acceptance network (network
  61 delivery guaranteed)
  62 MRECV is nonblocking, [rd]=0 on no data to receive, [rd]=message
  63 otherwise (cannot send 0 as message)
  64 MRECVB is blocking, waits until data arrives (can send 0 as a message)
  65
  66 -----
  67
  68 MSEND can be like ST, but I chose to have a return value to indicate
  69 whether the send was accepted (i.e., copied into xmit buffer). this
  70 enables sharing of resources at the sender (future senders will be
  71 denied until the xmit buffer has space).
  72
  73 MRECV has two versions, blocking and non-blocking. the non-blocking
  74 version allows the hart to do a bit more work before checking whether
  75 data has arrived. the blocking version waits until data is received.
  76
  77 to improve upon the messaging system I described, there would need to
  78 be backing storage in main memory for the CAM data. perhaps the CAM
  79 needs to operate with an eviction policy based upon oldest-first. main
  80 memory would then store anything that is evicted. that way any values
  81 in the CAM that aren't used right away will migrate into main memory;
  82 it is acceptable to move them there because this is already a high
  83
  84 ----
  85
  86 Maybe the *newest* message should spill to memory instead?  This keeps
  87 messages in FIFO order and could be easier to implement -- MSEND traps,
  88 supervisor transfers the message to memory and sets a bit in the target's
  89 task state indicating "RX queue overflow".  When the target task finally
  90 does drain its RX queue, and that bit is set, MRECV traps to permit the
  91 supervisor to reload the hardware queue from the memory overflow area.
  92
  93 This avoids needing background DMA for the message buffers in hardware
  94 and allows supervisors to fully implement the overflow queues, rather
  95 than forcing a hardware-imposed structure.
  96
  97