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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).