"Dr. David Alan Gilbert" <dgilb...@redhat.com> wrote: > * Juan Quintela (quint...@redhat.com) wrote: >> Indicates the number of threads that we would create. By default we >> create 2 threads. >> >> Signed-off-by: Juan Quintela <quint...@redhat.com> >> Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com> > > Also needs updating DEFINE_PROP stuff - and if Markus' qapi patch lands.
Done. >> # >> # @return-path: If enabled, migration will use the return path even >> # for precopy. (since 2.10) >> +# >> # @x-multifd: Use more than one fd for migration (since 2.10) >> # >> # Since: 1.2 >> @@ -910,6 +911,7 @@ >> 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks', >> 'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram', >> 'block', 'return-path', 'x-multifd'] } >> + > > Escapee from previous patch. Done. > >> ## >> # @MigrationCapabilityStatus: >> # >> @@ -1026,13 +1028,19 @@ >> # migrated and the destination must already have access to the >> # same backing chain as was used on the source. (since 2.10) >> # >> +# @x-multifd-threads: Number of threads used to migrate data in >> +# parallel. This is the same number that the >> +# number of sockets used for migration. >> +# The default value is 2 (since 2.10) >> +# > > That did make me think for a moment; I guess '2' makes sense once you've > set the x-multifd capability on. The other possibility would be to > remove the capability and just rely on the threads > 1 I think this is the same that xbzrle cache size. It has a default value. But we only used it when we set the capability. I think that it makes the code more ortogonal with the others, no? Later, Juan.
