Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support

From: Ketan Nilangekar <Ketan.Nilangekar@veritas.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
	Ashish Mittal <ashmit602@gmail.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"kwolf@redhat.com" <kwolf@redhat.com>,
	"armbru@redhat.com" <armbru@redhat.com>,
	"berrange@redhat.com" <berrange@redhat.com>,
	"jcody@redhat.com" <jcody@redhat.com>,
	"famz@redhat.com" <famz@redhat.com>,
	Ashish Mittal <Ashish.Mittal@veritas.com>,
	Abhijit Dey <Abhijit.Dey@veritas.com>,
	"Venkatesha M.G." <Venkatesha.Mg@veritas.com>
Subject: Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support
Date: Tue, 25 Oct 2016 21:53:23 +0000	[thread overview]
Message-ID: <B4FC218A-A7B5-4B72-BB65-207CA3038946@veritas.com> (raw)
In-Reply-To: <d17f58f3-508d-5c15-39cb-d6c45a0e4e91@redhat.com>

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)

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.

But again this is something that will come in the near future. For now the existing qnio implementation can give us adequate performance even if we need to modify it to handle vip based failover.

Ketan

> On Oct 25, 2016, at 1:01 PM, Paolo Bonzini <pbonzini@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 <pbonzini@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