[Libguestfs] [nbdkit PATCH 3/4] nbd: Use libnbd 0.1

[Eric Blake]

On 5/31/19 3:43 AM, Richard W.M. Jones wrote:
> On Thu, May 30, 2019 at 02:00:48PM -0500, Eric Blake wrote:
>> [...] which is more eassily explained by the
>> serialization nature that libnbd is never read()ing from one thread at
>> the same time another thread is write()ing.
>>
>> [...] libnbd
>> works around that by using non-blocking sockets and prioritizing reads
>> over writes rather than insisting on complete transactions).
> 
> Indeed, this is something that even a more complex state machine in
> libnbd could not solve.  It fundamentally assumes that there is one
> thread running the handle at any one time, but to both write to and
> read from the socket simultaneously would require two threads.  That's
> a large architectural change (I'm not even sure how to do it).

There's always POSIX aio_* (which, in glibc, creates a worker thread on
your behalf rather than being truly single-thread async). And
https://blog.cloudflare.com/io_submit-the-epoll-alternative-youve-never-heard-about/
states that Linux-only io_submit() (probably via libaio) can do a truly
async single-thread network polling loop that can therefore manage both
simultaneous reads and writes; but that requires an entirely different
control loop (io_getevents instead of poll), so it may be a lot of work
to wire up, before we'd even know if it actually adds any gain.

> 
> The question is whether this use case can be covered up by using
> multi-conn, or if there's a requirement for parallel writes and reads
> on the same socket.

A client truly wanting to saturate performance will probably implement
their own multi-conn on top of libnbd.  But if we want libnbd to be used
in qemu, which is currently using coroutines, then yes, qemu is
currently exploiting the fact that coroutines can track simultaneous
read and write on the same socket. So I don't think we have to redesign
everything now, but it is food for thought for future performance
improvements.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190531/318d725c/attachment.sig>