From: Eric Blake <eblake@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: berrange@redhat.com, mreitz@redhat.com, kwolf@redhat.com, den@openvz.org
Subject: Re: [Qemu-devel] [PATCH 2/4] nbd/client: do negotiation in coroutine
Date: Mon, 11 Feb 2019 15:38:11 -0600 [thread overview]
Message-ID: <9cf487db-acce-723e-3cf4-22485e4bb118@redhat.com> (raw)
In-Reply-To: <20190211125601.86533-3-vsementsov@virtuozzo.com>
[-- Attachment #1: Type: text/plain, Size: 4550 bytes --]
On 2/11/19 6:55 AM, Vladimir Sementsov-Ogievskiy wrote:
> As a first step to non-blocking negotiation, move it to coroutine.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
> nbd/client.c | 123 +++++++++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 109 insertions(+), 14 deletions(-)
>
> diff --git a/nbd/client.c b/nbd/client.c
> index 10a52ad7d0..2ba2220a4a 100644
> --- a/nbd/client.c
> +++ b/nbd/client.c
> @@ -859,13 +859,14 @@ static int nbd_list_meta_contexts(QIOChannel *ioc,
> * 2: server is newstyle, but lacks structured replies
> * 3: server is newstyle and set up for structured replies
> */
> -static int nbd_start_negotiate(QIOChannel *ioc, QCryptoTLSCreds *tlscreds,
> - const char *hostname, QIOChannel **outioc,
> - bool structured_reply, bool *zeroes,
> - Error **errp)
> +static int coroutine_fn nbd_co_start_negotiate(
> + QIOChannel *ioc, QCryptoTLSCreds *tlscreds, const char *hostname,
> + QIOChannel **outioc, bool structured_reply, bool *zeroes, Error **errp)
> {
> uint64_t magic;
>
> + assert(qemu_in_coroutine());
> +
Do we need this assert, since this function is static, and only called by:
> trace_nbd_start_negotiate(tlscreds, hostname ? hostname : "<null>");
>
> if (zeroes) {
> @@ -990,19 +991,20 @@ static int nbd_negotiate_finish_oldstyle(QIOChannel *ioc, NBDExportInfo *info,
> * Returns: negative errno: failure talking to server
> * 0: server is connected
> */
> -int nbd_receive_negotiate(QIOChannel *ioc, QCryptoTLSCreds *tlscreds,
> - const char *hostname, QIOChannel **outioc,
> - NBDExportInfo *info, Error **errp)
> +static int coroutine_fn nbd_co_receive_negotiate(
> + QIOChannel *ioc, QCryptoTLSCreds *tlscreds, const char *hostname,
> + QIOChannel **outioc, NBDExportInfo *info, Error **errp)
> {
> int result;
> bool zeroes;
> bool base_allocation = info->base_allocation;
>
> + assert(qemu_in_coroutine());
> assert(info->name);
> trace_nbd_receive_negotiate_name(info->name);
>
> - result = nbd_start_negotiate(ioc, tlscreds, hostname, outioc,
> - info->structured_reply, &zeroes, errp);
> + result = nbd_co_start_negotiate(ioc, tlscreds, hostname, outioc,
> + info->structured_reply, &zeroes, errp);
other functions in the same file that have also made the same assertion?
For that matter, does the assert() add any value over the fact that we
already annotated things as coroutine_fn?
I know that at some point, there was a proposal on the list for having
the compiler enforce coroutine_fn annotations (ensuring that a
coroutine_fn only calls other coroutine_fns, and that coroutines can
only be started on an entry point properly marked), but that's a
different task for another day.
> +static int nbd_receive_common(CoroutineEntry *entry,
> + NbdReceiveNegotiateCo *data)
> +{
> + data->ret = -EINPROGRESS;
> +
> + if (qemu_in_coroutine()) {
> + entry(data);
> + } else {
> + AioContext *ctx = qio_channel_get_attached_aio_context(data->ioc);
> + bool attach = !ctx;
There's where you used the function added in 1/4.
> +
> + if (attach) {
> + ctx = qemu_get_current_aio_context();
> + qio_channel_attach_aio_context(data->ioc, ctx);
> + }
> +
> + qemu_aio_coroutine_enter(ctx, qemu_coroutine_create(entry, data));
> + AIO_WAIT_WHILE(ctx, data->ret == -EINPROGRESS);
> +
> + if (attach) {
> + qio_channel_detach_aio_context(data->ioc);
> + }
> + }
> +
> + return data->ret;
> +}
Looks reasonable.
> +
> +int nbd_receive_negotiate(
> + QIOChannel *ioc, QCryptoTLSCreds *tlscreds, const char *hostname,
> + QIOChannel **outioc, NBDExportInfo *info, Error **errp)
> +{
Why the reflowed parameter list, compared to its existing listing (as
shown by the - lines where you added nbd_receive_co_negotiate)? That's
only cosmetic, so I can live with it, but it seems like it makes the
diff slightly larger.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-02-11 21:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-11 12:55 [Qemu-devel] [PATCH 0/4] nbd: non-blocking negotiation Vladimir Sementsov-Ogievskiy
2019-02-11 12:55 ` [Qemu-devel] [PATCH 1/4] io/channel: add qio_channel_get_attached_aio_context() Vladimir Sementsov-Ogievskiy
2019-02-11 21:22 ` Eric Blake
2019-02-12 10:33 ` Daniel P. Berrangé
2019-02-19 12:46 ` Vladimir Sementsov-Ogievskiy
2019-02-11 12:55 ` [Qemu-devel] [PATCH 2/4] nbd/client: do negotiation in coroutine Vladimir Sementsov-Ogievskiy
2019-02-11 21:38 ` Eric Blake [this message]
2019-02-19 10:37 ` Vladimir Sementsov-Ogievskiy
2019-02-11 12:56 ` [Qemu-devel] [PATCH 3/4] nbd: do qemu_coroutine_yield during tls handshake Vladimir Sementsov-Ogievskiy
2019-02-11 21:55 ` Eric Blake
2019-02-19 10:40 ` Vladimir Sementsov-Ogievskiy
2019-02-11 12:56 ` [Qemu-devel] [PATCH 4/4] block/nbd-client: use non-blocking io channel for nbd negotiation Vladimir Sementsov-Ogievskiy
2019-02-11 22:02 ` Eric Blake
2019-02-19 13:18 ` Vladimir Sementsov-Ogievskiy
2019-02-25 6:08 ` Vladimir Sementsov-Ogievskiy
2019-03-06 16:11 ` [Qemu-devel] [PATCH 0/4] nbd: non-blocking negotiation Eric Blake
2019-03-06 16:31 ` Vladimir Sementsov-Ogievskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9cf487db-acce-723e-3cf4-22485e4bb118@redhat.com \
--to=eblake@redhat.com \
--cc=berrange@redhat.com \
--cc=den@openvz.org \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).