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

[Stefan Hajnoczi]

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

signature.asc
Description: PGP signature