3:13 a.m.
On Mon, Jan 16, 2023 at 02:31:35PM -0600, Eric Blake wrote:
On Wed, Jan 04, 2023 at 06:14:35PM +0000, Richard W.M. Jones wrote:
> Using libblkio (https://libblkio.gitlab.io/) this implements a plugin
> for reading and writing various disk sources mainly used in
> virtualization and other high performance cases. These include: NVMe,
> vhost-user, vhost-vdpa and VFIO PCI.
>
> Note the current implementation uses the simplest libblkio API mode
> (blocking) and so it is not suitable for high performance access.
> ---
> +++ b/plugins/blkio/Makefile.am
> @@ -0,0 +1,80 @@
> +man_MANS = nbdkit-blkio-plugin.1
> +CLEANFILES += $(man_MANS)
> +
> +nbdkit-blkio-plugin.1: nbdkit-blkio-plugin.pod \
> + $(top_builddir)/podwrapper.pl
> + $(PODWRAPPER) --section=1 --man $@ \
> + --html $(top_builddir)/html/$@.html \
> + $<
Indentation looks odd here. Wonder if it's copy-pasted from somewhere else with an
odd mix.
I checked the final file and it looks OK there. It was initially
copied from another file though :-)
> +++ b/plugins/blkio/blkio.c
> @@ -0,0 +1,270 @@
> +/* nbdkit
> +/* libblkio could do parallel, but we would need to reimplement this
> + * plugin to use the libblkio event model.
> + */
> +#define THREAD_MODEL NBDKIT_THREAD_MODEL_SERIALIZE_ALL_REQUESTS
Fair enough for a proof of concept!
> +
> +struct property {
> + const char *name;
> + const char *value;
> +};
> +DEFINE_VECTOR_TYPE(properties, struct property)
> +
> +static const char *driver = NULL; /* driver name - required */
> +static properties props = empty_vector; /* other command line params */
> +static const_string_vector gets = empty_vector; /* get= parameters */
Is -Wshadow going to complain about a potential conflict with the
obsolete gets(3) name?
Hmm, I didn't even think about that. It in fact doesn't complain but
it's probably better to rename it so I'll think of something there.
> +++ b/TODO
> @@ -155,6 +155,13 @@ nbdkit-cdi-plugin:
> * Look at using skopeo instead of podman pull
> (https://github.com/containers/skopeo)
>
> +nbdkit-blkio-plugin:
> +
> +* Use event-driven mode instead of blocking mode. This involves
> + restructuring the plugin so that there is one or more background
> + threads to handle the events, and nbdkit threads issue requests to
> + these threads. (See how it is done in the VDDK plugin.)
I'm also trying to figure out if a v3 plugin protocol would make this
easier. Right now, with v2, we basically block an entire nbdkit
thread from the time we parse a request from the client until the
plugin has a result (which in turn means the result is all-or-none, so
we can't support sparse reads yet). But for v3, I'm hoping to get to
the point where we can have a a way for plugins to opt in to a 2-stage
action: we inform the plugin of a user request and give it a cookie,
then it uses a callback with that cookie when it is ready with part or
all of the response. (Plugins that are okay with simpler blocking
semantics will still work as they do in the v2 plugin protocol).
Hmm. I still think it's better for nbdkit to stick with the simpler
protocol to make plugins as easy to write as possible.
There is basically no use case for an incredibly fast local-only
nbdkit-blkio-plugin, since qemu can talk blkio directly. And once the
network is involved, something like how I architected the VDDK plugin
can go as fast as the server can send data.
(The use case for this plugin is ad-hoc scripting.)
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html