[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.
- Re: [Qemu-devel] [RFC PATCH RDMA support v4: 09/10] check for QMP string and bypass nonblock() calls, (continued)
[Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport, mrhines, 2013/03/17
- Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport, Michael S. Tsirkin, 2013/03/18
- Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport, Michael R. Hines, 2013/03/18
- Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport, Michael S. Tsirkin, 2013/03/18
- Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport, Michael R. Hines, 2013/03/18
- Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport, Michael S. Tsirkin, 2013/03/19
- Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport,
Michael R. Hines <=
- Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport, Michael R. Hines, 2013/03/19
- Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport, Michael S. Tsirkin, 2013/03/19
- Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport, Michael R. Hines, 2013/03/19
- Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport, Michael S. Tsirkin, 2013/03/19
- Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport, Michael R. Hines, 2013/03/19
- Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport, Paolo Bonzini, 2013/03/19
- Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport, Michael S. Tsirkin, 2013/03/19
- Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport, Michael R. Hines, 2013/03/19
- Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport, Paolo Bonzini, 2013/03/19
- Re: [Qemu-devel] [RFC PATCH RDMA support v4: 03/10] more verbose documentation of the RDMA transport, Michael R. Hines, 2013/03/19