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 :| _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
