Re: [Libguestfs] [libnbd] How close are we to declaring a stable API?
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.
* Should ‘nbd_shutdown’ take an extra parameter to indicate that it
should be delayed until all commands in the queue are retired?
That may still be worthwhile to pursue.
Is there anything else?
Do we like the signature of all the callbacks? Right now, there is a
slight inconsistency in that the 'int *error' parameter is last for
block_status and notify callbacks, but comes before 'int status' for
pread_structured. It would be a simple API switch to pread_structured to
put it last there as well, but something we can't do after declaring
stability.
We could also consider doing a "soft stable API" release where we bump
the version up to 0.9.x, announce that we're going to make the API
stable soon, have a much higher bar for breaking the API, but don't
actually prevent API breaks in cases where it's necessary.
The notify APIs are in now, and I'm trying to squash a valgrind failure
where tests/errors sometimes fails under load (if the server can read
data fast enough that a large NBD_CMD_WRITE doesn't block after all).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 488 bytes)