Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport

["Michael R. Hines" <mrhines@linux.vnet.ibm.com>]

On 03/19/2013 04:19 AM, Michael S. Tsirkin wrote:
> We have ways (e.g. cgroups) to limit what a VM can do. If it tries to 
> use more RAM than we let it, it will swap, still making progress, just 
> slower. OTOH it looks like pinning more memory than allowed by the 
> cgroups limit will just get stuck forever (probably a bug, should fail 
> instead? but does not help your protocol which needs it all pinned at 
> all times). There are also per-task resource limits. If you exceed 
> this registration will fail, so not good either. I just don't see why 
> do registration by chunks on source but not on destination. 

Would this a hard requirement for an initial version?

I do understand how and why this makes things more flexible during
the long run, but it does have the potential to slow down the RDMA
protocol significantly.

The way its implemented now, the sender can dump bytes
onto the wire at full speed (up to 30gbps last time I measured it),
but if we insert a round-trip message + registration on the
destination side before we're allowed to push more bytes out,
we'll have to introduce more complex flow control only for
the benefit of making the destination side have the flexibility
that you described.