On Tue, Jul 16, 2024 at 06:02:50PM -0400, Peter Xu wrote: > On Tue, Jul 16, 2024 at 03:44:54PM +0530, Prasad Pandit wrote: > > Hello Peter, > > > > On Mon, 15 Jul 2024 at 19:10, Peter Xu <pet...@redhat.com> wrote: > > > IMHO it's better we debug and fix all the issues before merging this one, > > > otherwise we may overlook something. > > > > * Well we don't know where the issue is, not sure where the fix may go > > in, ex. if the issue turns out to be how virsh(1) invokes > > migrate-postcopy, fix may go in virsh(1). Patches in this series > > anyway don't help to fix the migration convergence issue, so they > > could be reviewed independently I guess. > > I still think we should find a complete solution before merging anything, > because I'm not 100% confident the issue to be further investigated is > irrelevant to this patch. > > No strong opinions, I'll leave that to Michael to decide. > > > > > > You could pass over the patch to whoever going to debug this, so it will > > > be included in the whole set to be > > > posted when the bug is completely fixed. > > > > * Yes, this patch series is linked there. > > > > > The protocol should have no restriction on the thread model of a > > > front-end. > > > It only describes the wire protocol. > > > > > > IIUC the protocol was designed to be serialized by nature (where there's > > > no > > > request ID, so we can't match reply to any of the previous response), then > > > the front-end can manage the threads well to serialize all the requests, > > > like using this rwlock. > > > > * I see, okay. The simple protocol definition seems to indicate that > > it is meant for one front-end/back-end pair. If we are dividing the > > front-end across multiple threads, maybe we need a document to > > describe those threads and how they work, at least for the QEMU > > (front-end) side. Because the back-end could be a non-QEMU process, we > > can not do much there. (just thinking) > > IMHO that's not part of the protocol but impl details, so the current doc > looks all fine to me. > > Thanks, > > -- > Peter Xu
I just want to understand how we managed to have two threads talking in parallel. BQL is normally enough, which path manages to invoke vhost-user with BQL not taken? Just check BQL taken on each vhost user invocation and you will figure it out. -- MST
