* Peter Xu (pet...@redhat.com) wrote: > On Wed, Sep 08, 2021 at 09:30:58AM +0100, Dr. David Alan Gilbert wrote: > > * Peter Xu (pet...@redhat.com) wrote: > > > On Tue, Sep 07, 2021 at 12:06:15PM +0100, Dr. David Alan Gilbert wrote: > > > > > > What if we do the 'flush()' before we start post-copy, instead of > > > > > > after each > > > > > > iteration? would that be enough? > > > > > > > > > > Possibly, yes. This really need David G's input since he understands > > > > > the code in way more detail than me. > > > > > > > > Hmm I'm not entirely sure why we have the sync after each iteration; > > > > > > We don't have that yet, do we? > > > > I think multifd does; I think it calls multifd_send_sync_main sometimes, > > which I *think* corresponds to iterations. > > Oh.. Then we may need to: > > (1) Make that sync work for zero-copy too; say, semaphores may not be enough > with it - we need to make sure all async buffers are consumed by > checking > the error queue of the sockets, > > (2) When we make zero-copy work without multi-fd, we may want some similar > sync on the main stream too
It might not be worth bothering with (2) - zerocopy fits a lot better with multifd's data organisation. Dave > Thanks, > > > > > Dave > > > > > > the case I can think of is if we're doing async sending, we could have > > > > two versions of the same page in flight (one from each iteration) - > > > > you'd want those to get there in the right order. > > > > > > From MSG_ZEROCOPY document: > > > > > > For protocols that acknowledge data in-order, like TCP, each > > > notification can be squashed into the previous one, so that no > > > more > > > than one notification is outstanding at any one point. > > > > > > Ordered delivery is the common case, but not guaranteed. > > > Notifications > > > may arrive out of order on retransmission and socket teardown. > > > > > > So no matter whether we have a flush() per iteration before, it seems we > > > may > > > want one when zero copy enabled? > > > > > > Thanks, > > > > > > -- > > > Peter Xu > > > > > -- > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > > > > -- > Peter Xu > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK