ipc_extension.mdwn

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