On 25/10/2016 23:53, Ketan Nilangekar wrote: > We need to confirm the perf numbers but it really depends on the way we do > failover outside qemu. > > We are looking at a vip based failover implementation which may need > some handling code in qnio but that overhead should be minimal (atleast > no more than the current impl in qemu driver)
Then it's not outside QEMU's address space, it's only outside block/vxhs.c... I don't understand. Paolo > IMO, the real benefit of qemu + qnio perf comes from: > 1. the epoll based io multiplexer > 2. 8 epoll threads > 3. Zero buffer copies in userland code > 4. Minimal locking > > We are also looking at replacing the existing qnio socket code with > memory readv/writev calls available with the latest kernel for even > better performance. > > Ketan > >> On Oct 25, 2016, at 1:01 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: >> >> >> >>> On 25/10/2016 07:07, Ketan Nilangekar wrote: >>> We are able to derive significant performance from the qemu block >>> driver as compared to nbd/iscsi/nfs. We have prototyped nfs and nbd >>> based io tap in the past and the performance of qemu block driver is >>> significantly better. Hence we would like to go with the vxhs driver >>> for now. >> >> Is this still true with failover implemented outside QEMU (which >> requires I/O to be proxied, if I'm not mistaken)? What does the benefit >> come from if so, is it the threaded backend and performing multiple >> connections to the same server? >> >> Paolo >> >>> Ketan >>> >>> >>>> On Oct 24, 2016, at 4:24 PM, Paolo Bonzini <pbonz...@redhat.com> >>>> wrote: >>>> >>>> >>>> >>>>> On 20/10/2016 03:31, Ketan Nilangekar wrote: This way the >>>>> failover logic will be completely out of qemu address space. We >>>>> are considering use of some of our proprietary >>>>> clustering/monitoring services to implement service failover. >>>> >>>> Are you implementing a different protocol just for the sake of >>>> QEMU, in other words, and forwarding from that protocol to your >>>> proprietary code? >>>> >>>> If that is what you are doing, you don't need at all a vxhs driver >>>> in QEMU. Just implement NBD or iSCSI on your side, QEMU already >>>> has drivers for that. >>>> >>>> Paolo > >
