Re: [Qemu-block] [PATCH] block/iscsi: handle zero events from iscsi_which_events

[ronnie sahlberg]

On Wed, Apr 8, 2015 at 1:38 AM, Stefan Hajnoczi <address@hidden> wrote:
> On Tue, Apr 7, 2015 at 9:08 PM, Peter Lieven <address@hidden> wrote:
>
> Please CC address@hidden in the future.  All patches must be on
> the qemu-devel mailing list so they can be merged (for transparency).
> I have added qemu-devel to CC.
>
>> +    /* newer versions of libiscsi may return zero events. In this
>> +     * case start a timer to ensure we are able to return to service
>> +     * once this situation changes. */
>> +    if (!ev) {
>> +        timer_mod(iscsilun->event_timer,
>> +                  qemu_clock_get_ms(QEMU_CLOCK_REALTIME) + EVENT_INTERVAL);
>>      }
>
> This suggests that libiscsi is waiting on its own internal timer.  It
> would be cleaner for libiscsi to provide a timeout value so the
> application doesn't need to poll the library.  Is there still scope to
> modify libiscsi to do this?

I think that returning a timeout value would be a bigger change in the
API that Peter wanted to avoid.
We discussed that as an option by my take from it was that this would
require that qemu and libiscsi
again would have to be updated in lockstep,

In this particular case with creating a delay between failed reconnect
attempts, i.e. the target is restarting and
returning a RST to the SYN request until it has fully restarted, the
correct amount of time to wait until re-trying is at best a guess
anyway.
I don't have any particular feelings on whether the decision on how
long to wait is done inside libiscsi and communicated to qemu,
or if it is done in qemu itself.

The nice part with the current patch of Peter is that qemu and
libiscsi can be upgraded/downgraded independently.