[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Verita
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support |
Date: |
Tue, 25 Oct 2016 23:59:57 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
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 <address@hidden> 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 <address@hidden>
>>>> 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
>
>
- Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support, (continued)
- Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support, Ketan Nilangekar, 2016/10/19
- Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support, Paolo Bonzini, 2016/10/24
- Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support, Ketan Nilangekar, 2016/10/25
- Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support, Abhijit Dey, 2016/10/25
- Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support, Paolo Bonzini, 2016/10/25
- Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support, Ketan Nilangekar, 2016/10/25
- Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support,
Paolo Bonzini <=
- Message not available
- Message not available
- Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support, Ketan Nilangekar, 2016/10/26
- Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support, Abhijit Dey, 2016/10/25