From: Juan Quintela <quintela@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org, amit.shah@redhat.com, dgilbert@redhat.com
Subject: Re: [Qemu-devel] [PATCH 09/16] migration: Start of multiple fd work
Date: Tue, 14 Mar 2017 13:32:10 +0100 [thread overview]
Message-ID: <87k27st4xh.fsf@secure.mitica> (raw)
In-Reply-To: <20170314103428.GD2652@redhat.com> (Daniel P. Berrange's message of "Tue, 14 Mar 2017 10:34:28 +0000")
"Daniel P. Berrange" <berrange@redhat.com> wrote:
> On Mon, Mar 13, 2017 at 05:58:06PM +0100, Juan Quintela wrote:
>> "Daniel P. Berrange" <berrange@redhat.com> wrote:
>> > On Mon, Mar 13, 2017 at 01:44:27PM +0100, Juan Quintela wrote:
>> >
>> > I still don't really like any of the changes in this file. We've now got
>> > two sets of methods which connect to a remote host and two sets of methods
>> > which accept incoming clients. I've got to think there's a better way to
>> > refactor the existing code, such that we don't need two sets of methods
>> > for the same actions
>>
>> I am open to suggestions, basically we want to be able to:
>> - open one + n channels
>> - be sure that we got the same id on both sides of the connection.
>>
>> You suggested on the previous iteration that I changed the FALSE in
>> *HERE* for TRUE, but I was not able to:
>> - make sure that we have opened n sockets before we continue with
>> migration
>> - making sure that we got same id numbers in both sides, that is doable,
>> just add a new id field
>> - right now I open a channel, and wait for the other side to open it
>> before open the following one. I can do things in parallel, but
>> locking is going to be "interesting".
>>
>> So, as said, I don't really care how we open the channels, I am totally
>> open to suggestions. Looking at the current code, this is the best way
>> that I have been able to think of.
>
> I think the key problem in the current design is that you delay the opening
> of the extra socket channels. To be able to remove most of this duplication,
> I think you need to open all the channels at once right at the start.
>
>
> IOW, in qmp_migrate() instead of calling tcp_start_outgoing_migration()
> just once, use a loop to call it N times (where N == number of threads).
>
> Now this method is asynchronous, and eventually triggers a call to
> migration_channel_connect() when the connection actually succeeds.
> You will need to change migration_channel_connect() so that it can be
> called multiple times. migration_channel_connect() should count how
> many channels have been opened, and only start the migration once all
> of them are open.
>
> The incoming side is a little different - in qemu_start_incoming_migration()
> you only need call tcp_start_incoming_migration() once. In the
> socket_accept_incoming_migration() method though, you need to change the
> 'return FALSE' to 'return TRUE', so that it continues to accept multiple
> incoming clients. The socket_start_outgoing_migration()method needs to again
> count the number of channels that have been opened so far, and only start
> the actual migration once the right number are open.
>
>
> By doing all this opening of channels upfront, you'll also make it much
> easier to support the other migration protocols - in particular 'fd'
> protocol needs to be extended so that libvirt can pass in multiple FDs
> in the monitor command at once. The 'exec' protocol should also be
> able to trivially support this by simply launching the command multiple
> times.
Ok. Thanks. Will look into this.
Later, Juan.
next prev parent reply other threads:[~2017-03-14 12:32 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-13 12:44 [Qemu-devel] [PATCH 00/16] Multifd v4 Juan Quintela
2017-03-13 12:44 ` [Qemu-devel] [PATCH 01/16] qio: create new qio_channel_write_all Juan Quintela
2017-03-13 16:29 ` Daniel P. Berrange
2017-04-27 8:19 ` Juan Quintela
2017-03-13 12:44 ` [Qemu-devel] [PATCH 02/16] qio: create new qio_channel_read_all Juan Quintela
2017-03-13 16:30 ` Daniel P. Berrange
2017-03-13 12:44 ` [Qemu-devel] [PATCH 03/16] migration: Test for disabled features on reception Juan Quintela
2017-03-13 16:21 ` Dr. David Alan Gilbert
2017-03-13 12:44 ` [Qemu-devel] [PATCH 04/16] migration: Don't create decompression threads if not enabled Juan Quintela
2017-03-13 16:25 ` Dr. David Alan Gilbert
2017-03-13 12:44 ` [Qemu-devel] [PATCH 05/16] migration: Add multifd capability Juan Quintela
2017-03-13 12:44 ` [Qemu-devel] [PATCH 06/16] migration: Create x-multifd-threads parameter Juan Quintela
2017-03-13 16:37 ` Daniel P. Berrange
2017-03-13 16:50 ` Juan Quintela
2017-03-13 12:44 ` [Qemu-devel] [PATCH 07/16] migration: Create x-multifd-group parameter Juan Quintela
2017-03-13 16:34 ` Daniel P. Berrange
2017-03-13 16:49 ` Juan Quintela
2017-03-13 17:12 ` Daniel P. Berrange
2017-03-13 18:35 ` Juan Quintela
2017-03-13 12:44 ` [Qemu-devel] [PATCH 08/16] migration: Create multifd migration threads Juan Quintela
2017-03-13 12:44 ` [Qemu-devel] [PATCH 09/16] migration: Start of multiple fd work Juan Quintela
2017-03-13 16:41 ` Daniel P. Berrange
2017-03-13 16:58 ` Juan Quintela
2017-03-14 10:34 ` Daniel P. Berrange
2017-03-14 12:32 ` Juan Quintela [this message]
2017-03-13 12:44 ` [Qemu-devel] [PATCH 10/16] migration: Create ram_multifd_page Juan Quintela
2017-03-13 12:44 ` [Qemu-devel] [PATCH 11/16] migration: Really use multiple pages at a time Juan Quintela
2017-03-13 12:44 ` [Qemu-devel] [PATCH 12/16] migration: Send the fd number which we are going to use for this page Juan Quintela
2017-03-13 12:44 ` [Qemu-devel] [PATCH 13/16] migration: Create thread infrastructure for multifd recv side Juan Quintela
2017-03-14 9:23 ` Paolo Bonzini
2017-03-17 13:02 ` Dr. David Alan Gilbert
2017-03-17 16:05 ` Paolo Bonzini
2017-03-17 19:36 ` Dr. David Alan Gilbert
2017-03-20 11:15 ` Paolo Bonzini
2017-03-30 11:56 ` Juan Quintela
2017-03-13 12:44 ` [Qemu-devel] [PATCH 14/16] migration: Test new fd infrastructure Juan Quintela
2017-03-13 12:44 ` [Qemu-devel] [PATCH 15/16] migration: Transfer pages over new channels Juan Quintela
2017-03-13 12:44 ` [Qemu-devel] [PATCH 16/16] migration: Flush receive queue Juan Quintela
2017-03-14 10:21 ` [Qemu-devel] [PATCH 00/16] Multifd v4 Dr. David Alan Gilbert
2017-03-14 10:26 ` Daniel P. Berrange
2017-03-14 11:40 ` Dr. David Alan Gilbert
2017-03-14 11:45 ` Daniel P. Berrange
2017-03-14 11:47 ` Daniel P. Berrange
2017-03-14 12:22 ` Dr. David Alan Gilbert
2017-03-14 12:34 ` Daniel P. Berrange
2017-03-14 16:23 ` Dr. David Alan Gilbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k27st4xh.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=amit.shah@redhat.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.