qemu/docs/rdma.txt

162 on the receiver side is registered and pinned, we're
185 At this point, we define a control channel on top of SEND messages
226 After ram block exchange is completed, we have two protocol-level
234 1. We transmit a READY command to let the sender know that
235    we are *ready* to receive some data bytes on the control channel.
236 2. Before attempting to receive the expected command, we post another
237    RQ work request to replace the one we just used up.
240 5. Verify that the command-type and version received matches the one we expected.
247 2. Optionally: if we are expecting a response from the command
248    (that we have not yet transmitted), let's post an RQ
251    unblock us and we immediately post a RQ work request
252    to replace the one we just used up.
253 4. Now, we can actually post the work request to SEND
254    the requested command type of the header we were asked for.
255 5. Optionally, if we are expecting a response (as before),
256    we block again and wait for that response using the additional
257    work request we previously posted. (This is used to carry
283    then we check the entire chunk for zero. Only if the entire chunk is
284    zero, then we send a compress command to zap the page on the other side.
315 If the version is invalid, we throw an error.
317 If the version is new, we only negotiate the capabilities that the
340 Finally, how do we handoff the actual bytes to get_buffer()?
342 Again, because we're trying to "fake" a bytestream abstraction
343 using an analogy not unlike individual UDP frames, we have
347 Each time we receive a complete "QEMU File" control-channel
350 Then, we return the number of bytes requested by get_buffer()
354 If the buffer is empty, then we follow the same steps
384 Chunks are also transmitted in batches: This means that we
397 we use for RDMA migration.