Re: [PATCH 1/2] migration: Add some documentation for multifd

[Peter Xu <peterx@redhat.com>]

On Thu, Mar 20, 2025 at 11:45:29AM -0300, Fabiano Rosas wrote:
> There's a bunch of other issues as well:
> 
> - no clear distinction between what should go in the header and what
>   should go in the packet.
> 
> - the header taking up one slot in the iov, which should in theory be
>   responsibility of the client
> 
> - the whole multifd_ops situation which doesn't allow a clear interface
>   between multifd and client
> 
> - the lack of uniformity between send/recv in regards to doing I/O from
>   multifd code or from client code
> 
> - the recv having two different modes of operation, socket and file

I can't say I know the answer of all of them, but to me the last one is
kind of by design - obviously the old multifd was designed to be more or
less event driven on dest side, but that doesn't play well on files.

To be fair, I didn't invent multifd, but IMHO Juan did a great job
designing it from scratch, at least it has a bunch of benefits comparing to
the old protocol especially on perf side (even though when initially
proposed I was not a fan of how the locking was designed.. but it should be
much easier to understand after previous refactors).

And just to say, we can change the code or protocol in whatever way we want
if that could make it better.  So instead of the rant (which is still
welcomed whenever you feel like :), we can go for whatever you see fit with
compat properties (and if with a handshake, that's even less of a concern).

-- 
Peter Xu