Re: [PATCH v2 3/7] multifd: adding multi-interface support for multifd on destination side

[Het Gala <het.gala@nutanix.com>]

On 26/07/22 4:50 pm, Daniel P. Berrangé wrote:
> On Thu, Jul 21, 2022 at 07:56:16PM +0000, Het Gala wrote:
>> i) Modified the format of qemu monitor command: 'migrate-incoming' by adding
>>     a list, each element in the list to open socket listeners with a given
>>     number of multifd channels.
>>
>> ii) Qemu starts with -incoming flag defer and -multi-fd-incoming defer to
>>      allow the modified 'migrate-incoming' command to be used.
>>
>> iii) Format for -multi-fd-incoming flag as a comma separated string has been
>>       added with each substring containing listener socket address and number
>>       of sockets to open.
>>
>> Suggested-by: Manish Mishra <manish.mishra@nutanix.com>
>> Signed-off-by: Het Gala <het.gala@nutanix.com>
>
>> diff --git a/qemu-options.hx b/qemu-options.hx
>> index 79e00916a1..5555f0d2fd 100644
>> --- a/qemu-options.hx
>> +++ b/qemu-options.hx
>> @@ -4479,6 +4479,24 @@ SRST
>>       to issuing the migrate\_incoming to allow the migration to begin.
>>   ERST
>>   
>> +DEF("multi-fd-incoming", HAS_ARG, QEMU_OPTION_multi_fd_incoming, \
>> +    "-multi-fd-incoming tcp:[host]:port[:channel][,to=maxport][,ipv4=on|off][,ipv6=on|off]\n" \
>> +    "-multi-fd-incoming defer\n" \
>> +    "                wait for the URI to be specified via\n" \
>> +    "                multi_fd_migrate_incoming\n",
>> +    QEMU_ARCH_ALL)
>> +SRST
>> +``-multi-fd-incoming tcp:[host]:port[:channel][,to=maxport][,ipv4=on|off][,ipv6=on|off]``
>> +    Prepare for multi-fd incoming migration, with multi-fd listening sockets
>> +    on that connection. Default number of multi-fd channels is 2.
>> +
>> +``-multi-fd-incoming defer``
>> +    Wait for the URI to be specified via multi_fd_migrate\_incoming. The
>> +    monitor can be used to change settings (such as migration parameters)
>> +    prior to issuing the multi_fd_migrate\_incoming to allow the migration
>> +    to begin.
>> +ERST
> We should not be adding any new -multi-fd-incoming CLI parameter at all.
> The CLI is so unsuitable for any complex configuration param and this
> is a prime example.
>
> If anything we should fully deprecate anything that is not '-incoming defer'
> such that we become 100% QMP/QAPI based for incoming migration config.
 > Sure Daniel. We will depricate this -multi-fd-incoming defer flag and 
only keep QMP/QAPI based migration config in the coming patchset series.
> With regards,
> Daniel
With Regards,
Het Gala