qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-block] [PATCH] block/iscsi: handle zero events fr


From: Peter Lieven
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] block/iscsi: handle zero events from iscsi_which_events
Date: Wed, 08 Apr 2015 21:36:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

Am 08.04.2015 um 21:22 schrieb Stefan Hajnoczi:
> On Wed, Apr 8, 2015 at 6:08 PM, ronnie sahlberg
> <address@hidden> wrote:
>> The nice part with the current patch of Peter is that qemu and
>> libiscsi can be upgraded/downgraded independently.
> That's fine for avoiding hassles for existing apps, like QEMU, and I'm
> happy to merge the patch.
>
> For the library's API design it would be return the timeout so that
> new applications can avoid polling, but that's just a suggestion.

You are right. Paolo also brought up this idea, but as Ronnie said the
idea was not to bump the API version. The whole async reconnect stuff
works without a change in the client.

But polling every 250ms is magnitutes better than having a hung Qemu :-)
If you feel 250ms is too often we could also go to 1000ms. The timeout
we are talking about is in the order of 1-30 seconds. It only happens when
a reconnect is initiated either bei Qemu (due to NOP timeout) or libiscsi 
(protocol,
socket error etc.) and the first reconnect try is not successful.

Another idea I had was to encode the timeout in the return value of 
iscsi_which_events.
This would work with all Qemu versions, but I do not know how poll reacts if it 
gets
unknown events passed. So all users other than Qemu that pass the result of 
iscsi_which_events
directly to poll would need to mask the result. Thats not a problem for the 
tools provided with libiscsi,
but I do not know how much other real users except Qemu are out there?

Peter




reply via email to

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