qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 2/7] multifd: modifying 'migrate' qmp command to add multi


From: Juan Quintela
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
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux)

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]