Re: [PATCH v4 3/3] multifd: Implement zerocopy write in multifd migration (multifd-zerocopy)

[Juan Quintela <quintela@redhat.com>]

Leonardo Bras Soares Passos <leobras@redhat.com> wrote:
> Hello Juan,

hi

> Current multifd's sendmsg() will block until all data is sent, is that correct?
>
> If that's the case, and supposing the network driver supports
> multiqueue, maybe there is a small chance for this to happen.
> I will add the flush at the end of each iteration, just to be sure.
>
>>
>> After each iteration, one needs to be sure that no ram is inflight.
>>
>> This means that I think you don't need the last_sync parameter at all,
>> as you have to do the flush() in every iteration.

It means guest memory corruption, it _needs_ to be there.
That is the whole reason why multifd code has to wait after each
iteration for all channels to finish.  Probability of failure is low,
but it exist, so it needs to be handled correctly.
>> >              '*multifd-zlib-level': 'uint8',
>> >              '*multifd-zstd-level': 'uint8',
>> > +         '*multifd-zerocopy': 'bool',
>> >              '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ] } }
>>
>> Something weird here.
>>
>> >              '*multifd-compression': 'MultiFDCompression',
>> >              '*multifd-zlib-level': 'uint8',
>> >              '*multifd-zstd-level': 'uint8',
>> > +         '*multifd-zerocopy': 'bool',
>> >              '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ] } }
>> >
>>
>> Same here.
>
> Could you please elaborate?

Indentation, 

+         '*multifd-zerocopy': 'bool',
             '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ] } }

This is how it is seen here.  space/tab?

Later, Juan.