qemu-devel
[Top][All Lists]
Advanced

[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: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support
Date: Fri, 30 Sep 2016 09:36:06 +0100
User-agent: Mutt/1.7.0 (2016-08-17)

On Tue, Sep 27, 2016 at 09:09:49PM -0700, Ashish Mittal wrote:
> This patch adds support for a new block device type called "vxhs".
> Source code for the library that this code loads can be downloaded from:
> https://github.com/MittalAshish/libqnio.git

The QEMU block driver should deal with BlockDriver<->libqnio integration
and libqnio should deal with vxhs logic (network protocol, failover,
etc).  Right now the vxhs logic is spread between both components.  If
responsibilities aren't cleanly separated between QEMU and libqnio then
I see no point in having libqnio.

Failover code should move into libqnio so that programs using libqnio
avoid duplicating the failover code.

Similarly IIO_IO_BUF_SIZE/segments should be handled internally by
libqnio so programs using libqnio do not duplicate this code.

libqnio itself can be simplified significantly:

The multi-threading is not necessary and adds complexity.  Right now
there seem to be two reasons for multi-threading: shared contexts and
the epoll thread.  Both can be eliminated as follows.

Shared contexts do not make sense in a multi-disk, multi-core
environment.  Why is it advantages to tie disks to a single context?
It's simpler and more multi-core friendly to let every disk have its own
connection.

The epoll thread forces library users to use thread synchronization when
processing callbacks.  Look at libiscsi for an example of how to
eliminate it.  Two APIs are defined: int iscsi_get_fd(iscsi) and int
iscsi_which_events(iscsi) (e.g. POLLIN, POLLOUT).  The program using the
library can integrate the fd into its own event loop.  The advantage of
doing this is that no library threads are necessary and all callbacks
are invoked from the program's event loop.  Therefore no thread
synchronization is needed.

If you make these changes then all multi-threading in libqnio and the
QEMU block driver can be dropped.  There will be less code and it will
be simpler.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]