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 :|