qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documen


From: Michael R. Hines
Subject: Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport
Date: Tue, 19 Mar 2013 09:21:18 -0400
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]