qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] coroutine question, for NBD debugging


From: Eric Blake
Subject: Re: [Qemu-devel] coroutine question, for NBD debugging
Date: Fri, 3 Nov 2017 16:49:21 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 11/03/2017 03:03 PM, Eric Blake wrote:
> In include/qemu/coroutine.h, we have:
> 
> /**
>  * Yield the coroutine for a given duration
>  *
>  * Behaves similarly to co_sleep_ns(), but the sleeping coroutine will be
>  * resumed when using aio_poll().
>  */
> void coroutine_fn co_aio_sleep_ns(AioContext *ctx, QEMUClockType type,
> 
> but there is no co_sleep_ns() anywhere.  What should the documentation
> actually state?

This part still needs fixing; but partially answering myself:

> 
> Meanwhile, I'm trying to figure out if there is an easy way to hack
> qemu-nbd to send two structured replies interleaved (as in A.1, B.1,
> A.2, B.2) to ensure the NBD client coroutines properly handle
> interleaved responses, but adding a plain sleep() between A.1 and A.2
> does not work, and I'm not sure whether co_aio_sleep_ns() would work for
> the hack instead.
> 
> The hack I'm currently playing with splits reads and structured errors
> into two parts, attempting to use sleeps to force the server to send
> replies out of order:
> 

> +    sleep(2);

Using this instead of sleep():

+    co_aio_sleep_ns(client->exp->ctx, QEMU_CLOCK_REALTIME, 2000000000);

> coupled with a client that does:
> 
> $ ./qemu-io -f raw nbd://localhost:10809/foo --trace='nbd_*' -c
> 'aio_write -P 3 1 1' -c 'aio_read -P 1 1 1'
> 

produced the trace I was looking for:

address@hidden:nbd_send_request Sending request to server: {
.from = 1, .len = 1, .handle = 93924431318768, .flags = 0x1, .type = 1
(write) }
address@hidden:nbd_send_request Sending request to server: {
.from = 1, .len = 1, .handle = 93924431318769, .flags = 0x0, .type = 0
(read) }
address@hidden:nbd_receive_structured_reply_chunk Got structured
reply chunk: { flags = 0x0, type = 32769, handle = 93924431318768,
length = 25 }
address@hidden:nbd_receive_structured_reply_chunk Got structured
reply chunk: { flags = 0x0, type = 1, handle = 93924431318769, length = 9 }
address@hidden:nbd_receive_structured_reply_chunk Got structured
reply chunk: { flags = 0x1, type = 0, handle = 93924431318768, length = 0 }
aio_write failed: Operation not permitted
address@hidden:nbd_receive_structured_reply_chunk Got structured
reply chunk: { flags = 0x1, type = 0, handle = 93924431318769, length = 0 }
read 1/1 bytes at offset 1
1 bytes, 1 ops; 0:00:02.00 (0.499560 bytes/sec and 0.4996 ops/sec)

which means I'm fairly confident that our client implementation is doing
the right thing with regards to complex out-of-order/interleaved
structured replies!  Always a nice thing to demonstrate.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]