From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEgeX-0006ph-3h for qemu-devel@nongnu.org; Fri, 23 Jan 2015 11:00:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YEgeS-0005VG-Ja for qemu-devel@nongnu.org; Fri, 23 Jan 2015 11:00:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41049) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEgeS-0005Sz-BU for qemu-devel@nongnu.org; Fri, 23 Jan 2015 11:00:04 -0500 Date: Fri, 23 Jan 2015 15:59:57 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20150123155957.GP2370@work-vm> References: <1418347746-15829-1-git-send-email-liang.z.li@intel.com> <1418347746-15829-13-git-send-email-liang.z.li@intel.com> <20150123134821.GL2370@work-vm> <54C26BE5.1060902@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54C26BE5.1060902@redhat.com> Subject: Re: [Qemu-devel] [v3 12/13] migration: Add command to set migration parameter List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: quintela@redhat.com, qemu-devel@nongnu.org, Liang Li , armbru@redhat.com, lcapitulino@redhat.com, yang.z.zhang@intel.com * Eric Blake (eblake@redhat.com) wrote: > On 01/23/2015 06:48 AM, Dr. David Alan Gilbert wrote: > > * Liang Li (liang.z.li@intel.com) wrote: > >> Add the qmp and hmp commands to tune the parameters used in live > >> migration. > > > > If I understand correctly on the destination side we need to set the number of > > decompression threads very early on an incoming migration - I'm not > > clear how early that needs to be - especially if you're using fd: so it's > > not waiting for a connect ? > > > > Eric: How would libvirt do that? > > Libvirt does some handshaking before starting migration. The source > would advertise that "I'm capable of threaded migration; and plan to use > X send and Y receive threads"; the destination would either reply that > threads are unsupported or set the receive thread count at that point, > then the source would know if it can enable threads and set the send > thread count, before letting migration start. I don't see any problems > with the current design of starting things up. Patch 3 calls migrate_decompress_threads_create from process_incoming_migration_co, if you're using fd based incoming migration then I think that gets called before libvirt would have a chance to connect to the monitor and call the parameter setting to say how many threads it wants. (A tcp incoming migration wouldn't have that problem because it waits until the TCP accept before calling process_incoming_migration_co) Dave > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK