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.
signature.asc
Description: PGP signature
