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
