[Libguestfs] [libnbd] How close are we to declaring a stable API?

[Daniel P. Berrangé]

On Tue, Jul 02, 2019 at 08:48:15PM -0500, Eric Blake wrote:
> On 6/29/19 5:25 AM, Richard W.M. Jones wrote:
> > As the subject says, how close are we to being able to declare a
> > stable API for libnbd?
> > 
> > I believe these are the main topics:
> > 
> > * Do we need to have an extra thread for writing?  I'm unclear about
> >   whether b92392b717 (which allows the state machine to break during
> >   reply processing) means we definitely don't need threads.  I imagine
> >   that two threads doing simultaneous send(2) and recv(2) calls could
> >   still improve performance (eg. having two cores copying skbs from
> >   userspace to and from kernel).
> 
> It's hard to see how simultaneous send() and recv() with nonblocking
> sockets will do any better across two threads than one. If it was
> blocking, then it makes total sense, but since we have non-blocking I/O,
> I'm not seeing that it will make any noticeable difference.  That said,
> I do know that you were experimenting at one point about adding a way to
> offload writing to a user-controlled thread, and maybe it's still worth
> playing with that a bit more.

Consider also what other work the threads are doing. With GNUTLS' API
design, the thread doing the recv()/send() is almost certainly going
to be doing the encrypt/decrypt of data, and that is likely to dominate
the utilization of the thread, even with harware accelerated crypto.
So if there's likely to be non-trivially size data packets both recvd
and sent oncurrently, separate threads will be a win with TLS.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|