[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 4/4] block/export: add BlockExportOptions->iothread member
From: |
Kevin Wolf |
Subject: |
Re: [PATCH 4/4] block/export: add BlockExportOptions->iothread member |
Date: |
Fri, 25 Sep 2020 17:01:42 +0200 |
Am 25.09.2020 um 15:42 hat Stefan Hajnoczi geschrieben:
> Make it possible to specify the iothread where the export will run.
>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
> Note the x-blockdev-set-iothread QMP command can be used to do the same,
> but not from the command-line. And it requires sending an additional
> command.
>
> In the long run vhost-user-blk will support per-virtqueue iothread
> mappings. But for now a single iothread makes sense and most other
> transports will just use one iothread anyway.
> ---
> qapi/block-export.json | 4 ++++
> block/export/export.c | 26 +++++++++++++++++++++++++-
> 2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/qapi/block-export.json b/qapi/block-export.json
> index 87ac5117cd..eba6f6eae9 100644
> --- a/qapi/block-export.json
> +++ b/qapi/block-export.json
> @@ -219,11 +219,15 @@
> # export before completion is signalled. (since: 5.2;
> # default: false)
> #
> +# @iothread: The name of the iothread object where the export will run. The
> +# default is the main loop thread. (since: 5.2)
NBD exports currently switch automatically to a different AioContext if
another user (usually a guest device using the same node) tries to
change the AioContext. I believe this is also the most useful mode in
the context of the system emulator.
I can see the need for an iothread option in qemu-storage-daemon where
usually nobody else will move the node into a different AioContext.
But we need to define the semantics more precisely and specify what
happens if another user wants to change the AioContext later. Currently,
the NBD export will allow this and just switch the AioContext - after
this patch, ignoring what the user set explicitly with this new option.
I see two options to handle this more consistently:
1. If @iothread is set, move the block node into the requested
AioContext, and if that fails, block-export-add fails. Other users of
the node will be denied to change the AioContext while the export is
active.
If @iothread is not given, it behaves like today: Use whatever
AioContext the node is currently in and switch whenever another user
requests it.
2. Add a bool option @fixed-iothread that determines whether other users
can change the AioContext while the export is active.
Giving an @iothread and fixed-iothread == true means that we'll
enforce the given AioContext during the whole lifetime of the export.
With fixed-iothread == false it means that we try to move the block
node to the requested iothread if possible (but we won't fail if it
isn't possible) and will follow any other user switching the
AioContext of the node.
Not giving @iothread means that we start with the current AioContext
of the node, and @fixed-iothread then means the same as before.
Does this make sense to you?
Kevin