[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v2 11/12] mc: introduce new capabilities to
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [RFC PATCH v2 11/12] mc: introduce new capabilities to control micro-checkpointing |
Date: |
Tue, 11 Mar 2014 15:57:42 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 |
On 02/18/2014 01:50 AM, address@hidden wrote:
> From: "Michael R. Hines" <address@hidden>
>
> New capabilities include the use of RDMA acceleration,
> use of network buffering, and keepalive support, as documented
> in patch #1.
>
> Signed-off-by: Michael R. Hines <address@hidden>
> ---
> qapi-schema.json | 36 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 35 insertions(+), 1 deletion(-)
>
> +# Only for performance testing. (Since 2.x)
> +#
> +# @mc-rdma-copy: MC requires creating a local-memory checkpoint before
> +# transmission to the destination. This requires heavy use of
> +# memcpy() which dominates the processor pipeline. This option
> +# makes use of *local* RDMA to perform the copy instead of the CPU.
> +# Enabled by default only if the migration transport is RDMA.
> +# Disabled by default otherwise. (Since 2.x)
How does that work? If I query migration capabilities before requesting
a migration, what state am I going to read? Is there coupling where I
would observe the state of this flag change merely because I did some
other action? And if so, then how do I know that explicitly setting
this flag won't be undone by similar coupling?
It sounds like you are describing a tri-state option (unspecified so
default to migration transport, explicitly disabled, explicitly
enabled); but that doesn't work for something that only lists boolean
capabilities. The only way around that is to have 2 separate
capabilities (one on whether to base decision on transport or to honor
override, and the other to provide the override value which is ignored
when defaulting by transport).
> +#
> +# @rdma-keepalive: RDMA connections do not timeout by themselves if a peer
> +# has disconnected prematurely or failed. User-level keepalives
> +# allow the migration to abort cleanly if there is a problem with the
> +# destination host. For debugging, this can be problematic as
> +# the keepalive may cause the peer to abort prematurely if we are
> +# at a GDB breakpoint, for example.
> +# Enabled by default. (Since 2.x)
Enabled-by-default is an interesting choice, but I suppose it is okay.
> +#
> # Since: 1.2
> ##
> { 'enum': 'MigrationCapability',
> - 'data': ['xbzrle', 'x-rdma-pin-all', 'auto-converge', 'zero-blocks'] }
> + 'data': ['xbzrle',
> + 'rdma-pin-all',
> + 'auto-converge',
> + 'zero-blocks',
> + 'mc',
> + 'mc-net-disable',
> + 'mc-rdma-copy',
> + 'rdma-keepalive'
> + ] }
>
> ##
> # @MigrationCapabilityStatus
>
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Qemu-devel] [RFC PATCH v2 11/12] mc: introduce new capabilities to control micro-checkpointing,
Eric Blake <=