Peter Xu <pet...@redhat.com> writes: > 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. >
Yes, it's entirely by design. But it does create an extra hurdle in the end. The event driven model requires metadata to inform the IO thread what to do with the data collected (write to RAM at address X). The other model doesn't require that as it has a payload already included, so it just populates the fields. The problem is that we tied file migration with !packets, but if we want to use iovs all around, we'd still want packets (due to magic and version) although it'd be way easier to collect the actual data in MultiFDRecvData instead of passing information through the header and then doing the work at ->recv(). > 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). > Good point. My rant means no demerit at all to the current design, I'm just objectively pointing out the parts I think are getting in the way. > 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). Point taken (on the HS as well).
