From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Eric Blake <eblake@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"qemu-block@nongnu.org" <qemu-block@nongnu.org>
Cc: "berrange@redhat.com" <berrange@redhat.com>,
"mreitz@redhat.com" <mreitz@redhat.com>,
"kwolf@redhat.com" <kwolf@redhat.com>,
Denis Lunev <den@virtuozzo.com>
Subject: Re: [Qemu-devel] [PATCH 2/4] nbd/client: do negotiation in coroutine
Date: Tue, 19 Feb 2019 10:37:16 +0000 [thread overview]
Message-ID: <bde06028-8c83-19f6-abfb-a0244ec91890@virtuozzo.com> (raw)
In-Reply-To: <9cf487db-acce-723e-3cf4-22485e4bb118@redhat.com>
12.02.2019 0:38, Eric Blake wrote:
> 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:
OK, I think this can be dropped
>
>> 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.
>
I thought, that converting function to be "coroutine_fn" (not creating a new one)
is a good reason to add an assertion.
>
>> +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.
>
Hmm, maybe, will change it back.
--
Best regards,
Vladimir
next prev parent reply other threads:[~2019-02-19 10:37 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
2019-02-19 10:37 ` Vladimir Sementsov-Ogievskiy [this message]
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=bde06028-8c83-19f6-abfb-a0244ec91890@virtuozzo.com \
--to=vsementsov@virtuozzo.com \
--cc=berrange@redhat.com \
--cc=den@virtuozzo.com \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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).