[Qemu-devel] NBD handshake may block qemu main thread when socket delays or has packet loss

[Qemu-devel] NBD handshake may block qemu main thread when socket delays or has packet loss

[Fangyi (C)]

     As we all know, socket is in blocking mode when nbd is negotiating 
with the other end. If the network is poor because of delay or packet 
loss, socket read or write will return very slowly. The mainloop events 
won't be handled in time util nbd handshake ends.

     Any advices to solve the problem?
     Thanks,


Regards,
     FANG Yi.

Re: [Qemu-devel] NBD handshake may block qemu main thread when socket delays or has packet loss

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

On 01/04/2017 02:45 AM, Fangyi (C) wrote:
>     As we all know, socket is in blocking mode when nbd is negotiating
> with the other end. If the network is poor because of delay or packet
> loss, socket read or write will return very slowly. The mainloop events
> won't be handled in time util nbd handshake ends.

I wonder if Paolo's work to improve NBD coroutine usage after handshakes
can be leveraged here?

https://lists.gnu.org/archive/html/qemu-devel/2016-12/msg03224.html

> 
>     Any advices to solve the problem?

At any rate, it sounds like someone will have to patch NBD code to use
coroutines instead of blocking for the handshake portion (and that's
true in general - ANY operation that can block should probably be
refactored into aio or coroutines so that the main loop can remain
responsive).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] [Qemu-block] NBD handshake may block qemu main thread when socket delays or has packet loss

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1892 bytes --]

On Wed, Jan 04, 2017 at 02:44:53PM -0600, Eric Blake wrote:
> On 01/04/2017 02:45 AM, Fangyi (C) wrote:
> >     As we all know, socket is in blocking mode when nbd is negotiating
> > with the other end. If the network is poor because of delay or packet
> > loss, socket read or write will return very slowly. The mainloop events
> > won't be handled in time util nbd handshake ends.
> 
> I wonder if Paolo's work to improve NBD coroutine usage after handshakes
> can be leveraged here?
> 
> https://lists.gnu.org/archive/html/qemu-devel/2016-12/msg03224.html
> 
> > 
> >     Any advices to solve the problem?
> 
> At any rate, it sounds like someone will have to patch NBD code to use
> coroutines instead of blocking for the handshake portion (and that's
> true in general - ANY operation that can block should probably be
> refactored into aio or coroutines so that the main loop can remain
> responsive).

This is a general issue with network block drivers.  They tend to do
blocking DNS resolution, blocking connection, and blocking protocol
handshake/negotiation in .bdrv_open().

We cannot expose a block device to the guest before it has been opened
because the disk's capacity is unknown plus the guest would experience
I/O timeouts or errors.

I think we need to agree on how to handle this for all different types
of network protocols, not just nbd, before code can be written.

One starting point is:

Should we make .drv_open() a coroutine and introduce a async concept to
blockdev_add, reopen, etc?

The BlockDriverState would be in a special OPENING or OFFLINE state
where its name is reserved but it cannot be used for I/O or emulated
devices yet.

QMP clients would have watch out for an event that tells them that it's
now okay to device-add the emulated storage device using the drive.

Any ideas for a nicer solution?

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]