qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Het Gala" <het.gala@nutanix.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	qemu-devel@nongnu.org, dgilbert@redhat.com, pbonzini@redhat.com,
	eblake@redhat.com, prerna.saxena@nutanix.com,
	"Manish Mishra" <manish.mishra@nutanix.com>
Subject: Re: [PATCH v2 2/7] multifd: modifying 'migrate' qmp command to add multifd socket on particular src and dest pair
Date: Mon, 21 Nov 2022 13:26:55 +0100	[thread overview]
Message-ID: <87r0xwtrw0.fsf@secure.mitica> (raw)
In-Reply-To: <87sfmf84iy.fsf@pond.sub.org> (Markus Armbruster's message of "Tue, 02 Aug 2022 09:53:57 +0200")

Markus Armbruster <armbru@redhat.com> wrote:
> Het Gala <het.gala@nutanix.com> writes:



Hi

>>>>   # Example:
>>>>   #
>>>> -# -> { "execute": "migrate", "arguments": { "uri": "tcp:0:4446" } }
>>>> +# -> { "execute": "migrate",
>>>> +#      "arguments": {
>>>> +#          "uri": "tcp:0:4446",
>>>> +#          "multi-fd-uri-list": [ { "source-uri": "tcp::6900",
>>>> +#                                   "destination-uri": "tcp:0:4480",
>>>> +#                                   "multifd-channels": 4},
>>>> +#                                 { "source-uri": "tcp:10.0.0.0: ",
>>>> +#                                   "destination-uri": "tcp:11.0.0.0:7789",
>>>> +#                                   "multifd-channels": 5} ] } }

Why would one put the source uri and destination uri on the command?
It looks more complicated to me, but I guess there is a good reason.

>>>
>>> This whole scheme brings in redundancy wrt to the 'migrate-set-parameters'
>>> API wrt multifd - essentally the same data is now being set in two
>>> different places. IMHO, we should declare the 'multifd' capability
>>> and the 'multifd-chanels' parameter deprecated, since the information
>>> they provide is totally redundant, if you're giving an explicit list
>>> of channels to 'migrate'.
>>
>> Hi Daniel. Initially while brainstorming this idea for the first
>> time, we also came up with the same thought of depricating the
>> migrate
>> API. But how will we achieve this now and how is it going to
>> work. Is it like we will be making migate V2 APIs initially,
>> integrate it and then
>> depricate the old one? would be happy to get some pointers from your end.
>
> Migration maintainers, please advise.

I would put the old one in top of the new one, and call it a day.
I really hate the old one, but I haven't had the time to think about a
better one (nor I have had the time to look into this one).

The problem that I am seing here is that we are adding the number of
multifd channels here, and we were trying to not add migration
parameters into the migrate command.

BTW, once that we are at it, I guess we can just drop the inc/blk
parameters, we have had them deprecated ... forever?

Later, Juan.



  parent reply	other threads:[~2022-11-21 12:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-21 19:56 [PATCH v2 0/7] multifd: Multiple interface support on top of Multifd Het Gala
2022-07-21 19:56 ` [PATCH v2 1/7] multifd: adding more helper functions in util files for live migration Het Gala
2022-07-21 19:56 ` [PATCH v2 2/7] multifd: modifying 'migrate' qmp command to add multifd socket on particular src and dest pair Het Gala
2022-07-26 11:13   ` Daniel P. Berrangé
2022-07-28 15:02     ` Het Gala
2022-08-02  7:53       ` Markus Armbruster
2022-08-08  6:11         ` Het Gala
2022-08-08  9:29           ` Daniel P. Berrangé
2022-08-29  4:34           ` Het Gala
2022-09-21 10:08             ` Het Gala
2022-11-21 12:26         ` Juan Quintela [this message]
2022-11-22  9:26           ` Daniel P. Berrangé
2022-08-08  9:29       ` Daniel P. Berrangé
2022-07-21 19:56 ` [PATCH v2 3/7] multifd: adding multi-interface support for multifd on destination side Het Gala
2022-07-26 11:20   ` Daniel P. Berrangé
2022-07-28 15:05     ` Het Gala
2022-07-21 19:56 ` [PATCH v2 4/7] multifd: HMP changes for multifd source and " Het Gala
2022-07-21 19:56 ` [PATCH v2 5/7] multifd: establishing connection between any non-default src and dest pair Het Gala
2022-07-26 10:44   ` Daniel P. Berrangé
2022-07-28 15:15     ` Het Gala
2022-07-21 19:56 ` [PATCH v2 6/7] muitlfd: Correcting nit : whitespace error changes in qemu-sockets.c file Het Gala
2022-07-21 19:56 ` [PATCH v2 7/7] multifd: adding support for multifd connections dynamically Het Gala

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=87r0xwtrw0.fsf@secure.mitica \
    --to=quintela@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=het.gala@nutanix.com \
    --cc=manish.mishra@nutanix.com \
    --cc=pbonzini@redhat.com \
    --cc=prerna.saxena@nutanix.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).